Re: Unordered container of Glib::ustring

On ד', 2013-04-03 at 12:30 -0400, Paul Davis wrote:

On Wed, Apr 3, 2013 at 12:23 PM, אנטולי קרסנר <tombackton gmail com>
        Why? Isn't it natural to wish to have a map containing
        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

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

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() )

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]