This is the mail archive of the
mailing list for the libstdc++ project.
Re: Unicode and C++
- To: Havoc Pennington <hp at redhat dot com>
- Subject: Re: Unicode and C++
- From: Benjamin Kosnik <bkoz at redhat dot com>
- Date: Mon, 3 Jul 2000 10:10:03 -0700 (PDT)
- cc: gtk-i18n-list at gnome dot org, libstdc++ at sourceware dot cygnus dot com, otaylor at redhat dot 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: