[openbeos] Re: BString

  • From: "Daniel Reinhold" <danielr@xxxxxxxxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Mon, 12 Nov 2001 07:05:51 CST

>>The internal representation of the characters in a BString should not 
>>make any difference. Keith should pick whatever implementation works 
>>the best. Users of the class should make no assumption about how the 
>>data is stored -- if they do, they deserve whatever trouble they get, 
>Right!  I did not do this and that is why I had problems, I assumed
>that BStrings would do what the BeBook said they will do.

What didn't they do?

>>So yes, users should only rely on calling Length() and not on finding 
>>terminating null. However, I would recommend *not allowing* zero 
>>in BStrings. It would work technically, but from a design standpoint, 
>>it would confuse people. Making it clear that BString is only meant 
>>textual strings and not binary data is in keeping with BString's API 
>>(for example, the buffer returned by String() is guaranteed to be 
>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?

I don't think it outright says BStrings are only meant for text, but 
that's pretty much common sense. BString is clearly another C++ class 
implementation designed to "save" programmers from <string.h>. C 
programmers whined for years about things they didn't like about char *
s. From practically the moment C++ arrived on the scene, everyone and 
their brother has implemented some kind of String class. It's mostly 
for syntactic sugar -- so that people can write stuff like:

s = "hello " + username;

instead of

strcpy (s, "hello ");
strcat (s, username);

Of course, they also make it easier to allocate and grow the string 
data (i.e. the malloc() calls are made for you). But they certainly 
aren't a necessity -- you can do anything with char *.

Binary data is a different matter. C programmers wouldn't use strcpy, 
etc. on those -- they'd use memcpy, etc. You have to manage the buffer 
length yourself, etc. It's more work. It's quite possible to write a 
generic binary string class, but I've never seen a basic string class 
myself that wasn't intended for textual data. BString certainly has the 
API expected for textual data, but not what you'd expect for a binary 
data container. Implementing BString as a generic binary container 
would be more confusing and misleading than helpful, IMO.

As for handling Unicode, it doesn't.  Unicode uses multi-byte chars and 
the BeBook clearly warns the BStrings can't be used for multi-byte 
chars. If we want to, we can write a BString version that does support 
Unicode. That's a lot more work, but perhaps that is something to 
consider. But even then, Unicode does not really have embedded zeros; 
rather, it has wide characters (e.g. chars that are two bytes long). If 
you examined those chars a byte at a time, you might think that you're 
seeing nulls -- but at the character level they wouldn't be. For 
example, consider setting a four-byte integer equal to 1. Three of 
those bytes are zero, but the whole integer still equals 1. You have to 
look at the data at the granularity of its basic elements.

>>If the need for a binary string class becomes necessary, we could 
>>BBinaryString (or something to that effect) to handle that -- altho I 
>>think that good ole char * would be simpler.
>??? if you use char * then you are back to square one and have to 
>all the functions available in BStrings yourself.  That is what I did
>and it made my code a mess compared to the BString version which 
>90% of the time but failed 10% because it is undocumented about how
>zero bytes affect BStrings.
>          Earl Colby Pottinger

Earl, if you are embedding zeros in your string data, it ain't gonna 
work. Your going to have to use char *s to do it. If you're trying to 
put Unicode into BStrings, you're asking for trouble. If, on the other 
hand, you assume BString variables don't contain embedded nulls, and 
you don't try to put any in, then all your troubles will disappear, I 
would wager.

Other related posts: