BString operator<< incomplete

[fano]

I've noted that you can't add a long long (int64), a double or a bool to a BString using operator <<, if you want to do this you should cast to a lower type risking to lose precision.

Seeing the BString code it seems easy to add this methods as in the end snprintf() is used. They are not added because it could broke BeOs compatibility?

What do you think?

[bonefish]

Actually there are int64/uint64 versions of the operator in alpha 3 (replaced by [unsigned] long long in the trunk). At least with respect to precision a double version wouldn't make all that much sense, since the format string is hard-coded to "%.2f" anyway. It wouldn't harm to add it anyway, though (it does at least save conversions). In case of bool you'd expect a "true"/"false" string, I suppose?

[fano]

So it's no problem to modify BString for legacy BeOs applications?

I see there is some incoherency in that library respect of the rest of Haiku... I tough the right types to use were int8, int16, int32... indeed I see char, int, long long... I think it is better to use the Haiku typedef they are more clear,... I've always hated the char/byte confusion of C/C++.

Yes my idea for a bool was to translate it in the string "true" & "false".

[anevilyak]

Problems would only arise if you either a) changed the signature of an existing method, or b) changed the class size/structure in terms of the size of data it contains or the number/order of virtual functions. Adding more operator overloads isn't a compat issue.

[fano]

OK, I'll try to do something this the weekend...

If only networking worked in VirtualBox :-(((

[fano]

I've try to chang String.cpp e String.h but I don't understand how to:

• compile only the "Support Kit" module
  
• install the new libbe.so in my current image

I've tried to copy in my testy program directory and done

~/Desktop/tests> g++ test.cpp -o test ./libbe.so 
/boot/home/Desktop/tests/test.cpp: In function `int main()':
/boot/home/Desktop/tests/test.cpp:22: ambiguous overload for `BString & << double &'
/boot/develop/headers/os/support/String.h:309: candidates are: class BString & BString::operator <<(char)
/boot/develop/headers/os/support/String.h:310:                 class BString & BString::operator <<(int)
/boot/develop/headers/os/support/String.h:311:                 class BString & BString::operator <<(unsigned int)
/boot/develop/headers/os/support/String.h:312:                 class BString & BString::operator <<(long unsigned int)
/boot/develop/headers/os/support/String.h:313:                 class BString & BString::operator <<(long int)
/boot/develop/headers/os/support/String.h:314:                 class BString & BString::operator <<(long long unsigned int)
/boot/develop/headers/os/support/String.h:315:                 class BString & BString::operator <<(long long int)
/boot/develop/headers/os/support/String.h:317:                 class BString & BString::operator <<(float)

Not exists << double operator? It seems to ignore my command and use the system libbe...

Sorry but I'm abituad with the legacy configyre/make/make install linux thing :-)))

[bonefish]

You haven't actually replaced /boot/develop/headers/os/support/String.h as well I suppose?

[fano]

Yes, it was an header problem.
The operator <<double now works, but I have a problem with the boolean conversion... It is pretty simple:

BString&
BString::operator<<(bool b)
{  
	char boolean[6];
	int32 length = snprintf(boolean, sizeof(boolean), "%s", ((b == true) ? "true" : "false"));

	_DoAppend(boolean, length);
	return *this;
}

and my test program compiles fine, but running it I obtain:

~/Desktop/tests> ./test 
runtime_loader: /boot/home/Desktop/tests/test: Could not resolve symbol '__ls__7BStringb'
resolve symbol "__ls__7BStringb" returned: -2147478780
runtime_loader: /boot/home/Desktop/tests/test: Troubles relocating: Symbol not found

But the symbol is present!

nm libbe.so | grep __ls__7BStringb
0021023c T __ls__7BStringb

So, why it is not found? Thanks, for your support...

[fano]

Have you any idea?
I've tried a lot of thing but the operator << and bool seems can't coexists...

I'm supposing it is a runtime_loader bug at this point... that -2147478780 as returned value seems a value of a pointer out of the program memory.

Maybe bool is optimized by the compiler in something else (an int?) and my function is optimized out (but nm say there is)... I'm confused!

[tangobravo]

I don't think the bool addition really makes a lot of sense anyway. To do it "properly" it will need localisation support but even then I can't really think of the use-case.

[bonefish]

Replying to fano:

Have you any idea?

Yes, you're apparently not using your modified libbe. It needs to be in the library search path (in the lib subdirectory of the program's directory or any other path in LIBRARY_PATH) before the system libbe.

I've tried a lot of thing but the operator << and bool seems can't coexists...

Sure they can.

I'm supposing it is a runtime_loader bug at this point... that -2147478780 as returned value seems a value of a pointer out of the program memory.

Nope, it's the error code value B_MISSING_SYMBOL.

Implementing...

[bonefish]

Added in hrev42387.

@tangobravo: For localization one wouldn't use the << operators anyway.

[fano]

Very strange indeed I've used this line to compile:

 g++ test.cpp -o test ./libbe.so 

I thought that in this way it should do the right thing use the libbe in my current directory... but thinking best maybe this is true for the compilation... runtime loader can't know that! I've tried to use your suggestion create a new dir lib in the test dir program and now ut works, obviusly :-)

So "the more I know" -:)

It's a pity I can't do a working patch... well will be for the next time... @tangobravo: as you want add to a string an integer (in reality convert an integer to string) you may want add a bool, right? And the right "stringification" IMHO is "true" & "false"... right?