[interfacekit] Re: more questions about BString

I don't know what the performance (or usability) ramifications might be, but when I read this, it immediately occured to me that in python, negative offsets have well-defined semantics that are quite useful. In IFind(), for instance, using -4 as the offset would initiate the find from whatever the fourth-from-last character/byte is. Depending on what the issues are, it might be more useful to properly implement negative offset handling than simply clamping to zero.

Thoughts?

e

Oliver Tappe wrote:
Hi everyone,

when implementing the BString-patch we spoke about earlier, I tried to follow the idea that the BString-class should clamp all input values (offsets) to sensible values (0 <= offset <= length).

As the resulting testrun shows, this causes the resulting behaviour to differ from R5-BString in some ways:

- R5 allows calls to Insert( const char* str, int32 pos) with negative positions, giving IMHO weird results...
Insert( "INSERT THIS", -1) on an empty BString yields a string that contains "NSERT THIS". This behaviour ist not at all documented by the BeBook.

My suggestion would be to clamp negative offsets to 0 (yielding "INSERT THIS" for the given example).

- Remove( int32 fromOffset, int32 length) silently accepts fromOffset<0 (using 0), but doesn't clamp length likewise:
BString s("A String");
s.Remove( 4, 30);
yields "A String" instead of "A St".

- the (I)Find...()-methods seem to always return B_ERROR if you pass a
negative fromOffset. My patched methods clamp fromOffset to 0 and then
execute the search, possibly yielding positive results.

No I wonder what to do with that, since the BeBook doesn't have any info on that...
Should I try to stick to R5 as much as possible (be as compatible as can be)?
Or is it better to try to implement consistent behaviour and clamp *all* offset parameters?

cheers,
        Oliver




Other related posts: