Re: Unordered container of Glib::ustring

[אנטולי קרס נר <tombackton gmail com>]

On ד', 2013-04-03 at 12:30 -0400, Paul Davis wrote:
> On Wed, Apr 3, 2013 at 12:23 PM, אנטולי קרסנר <tombackton gmail com>
> wrote:
>         
>         
>         
>         Why? Isn't it natural to wish to have a map containing
>         user-defined
>         strings, which may be in any language?
>
> that describes std::string too.
>
> all that Glib::ustring gives you are UTF-8-aware iterators.
>
> if you never iterate over a string that may be UTF-8 in order to get
> individual characters rather than individual bytes, you don't need
> ustring and it will complicate your life. 
>
> i made this mistake with ustring too, and used it widely. my code now
> only contains two references to a ustring in about 300,000 lines of
> code, and they are both places where i have to iterate through a
> string character by character. everywhere else uses std:;string. the
> program is fully translatable and has been translated into several
> languages.
I see, thanks for the advice.

I get the ustring objects from a library I use, so I can't avoid them.
The question is how I produce the hash. There's also an option to store
std::string, but again - I can get the std::string from raw() or from
collate_key().

I found some source code on GitHub which uses Glib::ustring with an
unordered map, and simply passes the std::string hash, which works
because Glib::ustring has a non-explicit type cast method, operator
std::string, which returns exactly what raw() returns.

I don't know it if works, and it may not be critical in my case because
I use just a few strings in most cases, but I'm still wondering.

(note: I had a thought, maybe storing std::string is faster because the
hash only needs to operate on std::string directly, but that doesn't
change the question or using collate_key() versus using raw() )