Re: [gtkmm] gtkmm questions

[Daniel Elstner <daniel elstner gmx net>]

On Fre, 2003-03-28 at 18:32, Todd Fisher wrote:
> I've been working on building a C++ based web crawler. Needless to say 
> it processes a tremendous
> amount of text from all different locals.  I have a few questions 
> regarding gtkmm or i guess glibmm.
> 1. do i need to link to all gtkmm or can i just link to glibmm?

You can link to glibmm only (although glibmm-2.2 is not available as a
separate package).

> 2. I was reading in the online documentation about ustring and wondered 
> why a method like
>     ustring Glib::ustring::uppercase()const
> is necessary if its resulting  string may not have the same number of 
> characters?  I'm sure there is
> a technical reason for this, but on the surface it seems rather destructive.

Hmm, I'm not sure if I understand your question.  A method like
Glib::ustring::uppercase() is in fact _mandatory_ if the resulting
string may have not the same number of characters, since simply
iterating over the string may give a different result.  That's more of
an i18n issue than a technical one, and the documentation even comes
with an example.

> 3. The documents also suggest that there is a particular high 
> performance cost in using the compare methods of ustring and yet
> alludes that strings can safely be stored in std::string's.  What about 
> the cost of conversion from std::string to Glib::ustring?

The documentation also says conversion to/from std::string doesn't imply
charset conversion, i.e. it's a pure type conversion.  It can even be
optimized away by the compiler (depends on the context).

However, comparing ustrings is expensive for a reason.  If you just
convert to std::string you lose locale-dependent Unicode collation.
What the documentation tries to explain is that caching the result of
collate_key() and using that for collation is most likely faster than
sorting ustrings directly.

You can think of a collate key as kind of pre-compiled Unicode string
for the solely purpose of sorting.

Cheers,
--Daniel