Send Gtkmm-forge mailing list submissions to
[EMAIL PROTECTED]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/gtkmm-forge
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gtkmm-forge digest..."
gtkmm-forge is the mailing list that receives gtkmm bug reports from bugzilla.
A daily digest is sent to gtkmm-main, to encourage people to help fixing the
bugs. Do not try to unsubscribe gtkmm-forge from gtkmm-list.
Today's Topics:
1. [Bug 93787] Outputting ustring with operator << converts implicitly
(gtkmm (bugzilla.gnome.org))
--__--__--
Message: 1
From: "gtkmm (bugzilla.gnome.org)" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Sat, 17 Sep 2005 17:10:59 -0400 (EDT)
Subject: [gtkmm bugzilla] [Bug 93787] Outputting ustring with operator <<
converts implicitly
Do not reply to this email. You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=3D93787
gtkmm | reference documentation | Ver: 2.0
------- Additional Comments From Ole Laursen 2005-09-17 21:10 -------
Although this bug is closed long time ago, I just want to add I've discov=
ered
the hard way that always using the encoding of the locale with std::strin=
gs is
not always good enough either.
When putting a floating point number into a stringstream, one may get a s=
tring
with extended characters out because the decimal point is converted to a =
special
decimal point character. This is _not_ guaranteed to be saved correctly i=
n a
std::string because the characters may not be wide enough.
In fact I have experienced a crash with libstdc++ because it clipped a mu=
ltibyte
UTF-8 decimal point character to a single byte instead of two bytes. This
happened _even though_ the encoding of the locale was UTF-8 so that one w=
ould
have thought that a valid UTF-8 std::string could have been produced (for=
the
record, the actual crash appeared when the program afterwards tried to co=
nvert
the malformed UTF-8 std::string to a ustring).
Instead I suggest converting to and from wchar* with Glib::convert and us=
ing
wstringstreams. This has worked flawlessly for me (in my string compositi=
on
library), except for occasional bugs in the implementation of specific lo=
cales
in the standard library.
------- You are receiving this mail because: -------
You are the assignee for the bug.
--__--__--
_______________________________________________
Gtkmm-forge mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/gtkmm-forge
End of Gtkmm-forge Digest
_______________________________________________
gtkmm-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtkmm-list