Gtkmm-forge digest, Vol 1 #973 - 1 msg

[gtkmm-forge-request lists sourceforge net]

Send Gtkmm-forge mailing list submissions to
	gtkmm-forge lists sourceforge net

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
	gtkmm-forge-request lists sourceforge net

You can reach the person managing the list at
	gtkmm-forge-admin lists sourceforge net

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)" <bugzilla-daemon bugzilla gnome org>
To: gtkmm-forge lists sourceforge net
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
Gtkmm-forge lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/gtkmm-forge


End of Gtkmm-forge Digest