[openbeos] Re: BString
- From: "Michael Phipps" <mphipps1@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Tue, 13 Nov 2001 20:57:06 -0500
Interesting as this may be, it really doesn't fall under the realm of R1. :-/
I know. There are *so* many places we would all like to improve things.
Trust me - screen saver and the kernel both have them. :-)
All the more reason to get the stuff done that we have to for R1 so that
we can start planning R2. :-)
>(Sorry about the blank reply - button bounce)
>
>What about doing a "BBlob" class that could provide most of the
>functionality of BString, but is designed to store arbitrary binary data? It
>would be simple to derive BString by providing Length(), etc., and it would
>be useful for other things besides.
>
>As for implementation, I would advocate a reference counted implementation
>to reduce the number of copies. If we need to rely on terminating zeros then
>there is no benefit in having substring capability, though.
>
> - John
>
>P.S. Don't forget that Blob creation needs an alignment argument (although
>it can default to one). Wide characters are supposed to be halfword aligned
>(align by 2), and other objects may have stricter alignment.
>
>-----Original Message-----
>From: Erik Jakowatz
>Sent: Monday, November 12, 2001 7:30 PM
>Subject: [openbeos] Re: BString
>
>>Where in the BeBook does it say BStrings are for text only?
>>If it is for text only, how will it handle UNICODE without zeros?
>
>To quote The Book:
>
>"Currently, BString only supports assignment and retrieval of strings
>that contain single-byte characters. If you want to use BString to store
>a string that contains multi-byte (UTF8) characters, you have to flatten
>the string yourself and adjust the character count arguments
>accordingly."
>
>Not sure what is meant by "flatten the string", but given this statement
>plus the fact that *only* UTF-8 is mentioned leads me to think that
>BString should be thought of as *not* supporting NULL characters
>anywhere in the data. Certainly, there is no place where the docs
>explicitely state that "BStrings are for text only", but I think it's
>reasonable to assume that the authors were implicitely acting as though
>they were -- I don't think I've ever heard of the terminology "string"
>used to describe anything other than text data.
>
>>and it made my code a mess compared to the BString version which worked
>>90% of the time but failed 10% because it is undocumented about how
>>zero bytes affect BStrings.
>
>I think it's undocumented because the class wasn't intended to deal with
>NULL characters randomly embedded in the text data. Seems to me that
>BString is intended to be a light-weight string class that provides the
>most common string operations, and not an end-all-be-all solution like
>basic_string attempts to be.
>
>Not looking to open a debate on basic_string, ;)
>
>e
>
>Data is not information, and information is not knowledge: knowledge is
>not understanding, and understanding is not wisdom.
> - Philip Adams
Other related posts:
