Re: Unicode and C++

[Benjamin Kosnik <bkoz redhat com>]

> Or in the GTK+ case, massive quantities of legacy code that has to
> keep working. UTF8 is pretty easy to port to; UCS4 requires
> duplicating the whole API, then porting all apps to it. Without the
> nice C++ trick you've outlined here, it's also quite inefficient to
> use UCS4 internally but UTF8 in the interfaces.

BTW both libstdc++ and glibc will be using UCS4 for the internal 
encoding of wchar_t types. 

I realize the benefits of UTF8 as an external encoding, so (me? nathan? 
somebody?) will work on the codecvt issues after the wchar_t stuff 
settles down and becomes solid. The goal is to be able to work with 
multiple encodings gracefully.

> My Inti C++ wrapper is new generation however, so I can use your suggestion.

Cool. That's what this is really about, anyway.

> If this string goes in libstdc++ as an extension, could it share the
> refcounted guts of std::string and std::wstring to avoid copies for
> these constructors (and for the conversion operators)?
> (I don't even know if you are using refcounting in the latest lib, but
> thought I'd ask.)

This discussion is only relevant for libstdc++-v3.

Yes. The new string class is pretty well documented, using refcounting as 
well as a well-defined locking mechanism . . . please base your work off 
of it, as we'll then be able to ship a unicode_string (and/or 
utf8_string) in the ext directory...

These are the files you should check out:

gcc/libstdc++-v3/bits/basic_string.h
gcc/libstdc++-v3/bits/string.tcc
gcc/libstdc++-v3/bits/std_string.h


Thanks,
Benjamin