Here we are, 2011, and Glib::ustring::operator<< is haunting us still.
I'm a little bit tired and my advice may seem counterproductive, but just so
you know, this is a very old issue, and in actuality is not related to the
fact that you "have to store UTF-8 strings only in Glib::ustring"; it's a
problem.
So, as a short foreword: There is no magic pixie dust inside Glib::ustring.
It's just a shell for std::string and encapsulates UTF-8 only methods to be
performed on a string object.
An std::string doesn't suddenly "become" UTF-8 just by putting it into a
Glib::ustring, nor does a Glib::ustring suddenly become non-UTF-8 by
accessing the string... no, wait. Actually it does, and herein lies the
problem.
It's a bit late in the night hence let me just conclude this by giving a
simple advice instead of supporting my statement with code (for now):
- *Never* use Glib::ustring. Always use std::string. Functions that accept a
Glib::ustring as a parameter will accept an std::string just fine. Again,
nothing happens, no conversion, anything. If your string is valid UTF-8, you
can just store it in an std::string just fine, and you can pass that
std::string to a function that takes Glib::ustring
- The only exception to above rule is when you need to operate on a
character basis with UTF-8 data. Just let a Glib::ustring instance swallow
the std::string, do the manipulation you want with it, and then pass it back
to an std::string
I don't really get why it was neccessary to have a Glib::ustring _object
type_, but in my opinion, the design is a bit broken; I certainly hope that
the people who struggle with ustring's conversion stuff were not played a
crude joke of the must-define-object mantra.
In the C API, an UTF-8 string is stored simply inside a char*, and
operations on it are part of the Glib (not mm) library as free functions.
I know this probably sounds very confusing, but we've been at this place
before and no one wants to listen. Try applying the 2 hints from above, and
see if it works. If not, just get back to us.
M.
On Sat, Sep 10, 2011 at 11:34 PM, Zettai Muri <zettaim...@gmail.com> wrote:
> >> This is basic C++:
>
> I apologise for wasting your time on something so basic.
>
> >>
> >> try {
> >> std::cout << "DB - Password: " << password << std::endl;
> >> }
> >> catch (Glib::Exception& e) {
> >> std::cerr << e.what().raw() << std::endl;
> >> }
> >> catch (std::exception& e) {
> >> std::cerr << e.what() << std::endl;
> >> }
> >>
>
> Mmm I added this to my code and it continues to print out the same
> error without appearing to catch the exception. I changed in the
> above code std::cerr to std::cout because on WinXP std::cerr doesn't
> go to the terminal. However I continue to only get:
>
> (Japanese01.exe:2428): glibmm-CRITICAL **:
> unhandled exception (type Glib::Error) in signal handler:
> domain: g_convert_error
> code : 1
> what : Invalid byte sequence in conversion input
>
> It doesn't look like it is being caught here. So I suppose this means
> the error is being thrown somewhere else? Perhaps in the 'signal
> handler'? Where would I find this?
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
>
--
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
