[interfacekit] Re: BString patch suggestion and some questions, too

> Reading the not exactly detailed BeBook documentation -- `LockBuffer() 
> returns a pointer to the object's string...' -- as a user I would actually 
> expect that the pointer returned by LockBuffer() contains the C string 
> represented by the object as a prefix. So, in case of the empty string its 
> first character should indeed be a '\0', IMHO.

Yeah, I agree.

> I'm not so sure, if that's a good idea. This will cause the implementation to 
> doubly touch the new space in the cases where _GrowBy() and _OpenAtBy() are 
> used, thus decreasing performance. In case of LockBuffer() it will even be 
> worse, if the allocated size is far greater than the actually used one.

I'm also against initializing the new space to '\0'. BString isn't exactly fast 
in its allocations, 
so I don't think it's a good idea to slow it even more.
One of the things I wanted to do is allocate memory in blocks (like BMallocIO, 
BRegion, or any sane class which deals which allocations), instead of every 
time the BString is
truncated, or every time something is appended. Unfortunately, it isn't 
possible without breaking binary compatibility.

> 
> BTW, it might be a good idea to not allocate memory, when _GrowBy() is asked 
> to create an empty string, but rather free the previously allocated memory 
> (if any) and set _privateData to NULL.

Yeah, that's one of the things I was unsure about.... adding an extra check for 
(size == 0) was an idea, but then I discarded it, since I tought that 4 bytes 
"wasted" weren't a big deal...
Moreover, I tought that freeing that memory was more heavy than keeping those 
4bytes around...

I was sooo unexperienced at that time :P

Other related posts: