Re: Handling utf8 data from SQLite

[Milosz Derezynski <internalerror gmail com>]

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