Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#7757 closed enhancement (fixed)

BString operator<< incomplete

Reported by: fano Owned by: bonefish
Priority: normal Milestone: R1
Component: Kits/Support Kit Version: R1/Development
Keywords: BString Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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?

Change History (12)

comment:1 Changed 8 years ago by 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?

comment:2 Changed 8 years ago by 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".

comment:3 Changed 8 years ago by 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.

comment:4 Changed 8 years ago by fano

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

If only networking worked in VirtualBox :-(((

comment:5 Changed 8 years ago by 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 :-)))

comment:6 Changed 8 years ago by bonefish

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

comment:7 Changed 8 years ago by 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...

comment:8 Changed 8 years ago by 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!

comment:9 Changed 8 years ago by 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.

comment:10 in reply to:  8 Changed 8 years ago by bonefish

Owner: changed from axeld to bonefish
Status: newin-progress
Version: R1/alpha3R1/Development

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...

comment:11 Changed 8 years ago by bonefish

Resolution: fixed
Status: in-progressclosed

Added in hrev42387.

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

comment:12 Changed 8 years ago by 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?

Note: See TracTickets for help on using tickets.