>>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, >>haha! > >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 a >>terminating null. However, I would recommend *not allowing* zero bytes >>in BStrings. It would work technically, but from a design standpoint, >>it would confuse people. Making it clear that BString is only meant for >>textual strings and not binary data is in keeping with BString's API >>(for example, the buffer returned by String() is guaranteed to be null- >>terminated). > >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 write >>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 write >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 worked >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.