This is the mail archive of the libstdc++@sourceware.cygnus.com mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Unicode and C++



Per Hedbor <per@idonex.se> writes:
> > Or in the GTK+ case, massive quantities of legacy code that has to
> > keep working. UTF8 is pretty easy to port to
> 
> Only if you live in the US or some other 8-bit challenged country.
> 
> If you do not, you have to decode from UTF8 everywhere to support
> things like file-names, names etc. anyway. Thus, the porting job is
> not really smaller, only more hidden.
> 

You only need to decode from UTF8 to interface outside your program
(for display, for filenames, output, etc.). Most uses of strings are
passing them around inside the program itself, and those uses don't
change with UTF8. For display, things continue to work unchanged in
GTK since GTK handles those details. The frequency of loading/saving a
file is substantially less than the frequency of gtk_label_set_text()
in your average GUI app.

We have some convenience functions for filenames:

 gchar*   g_filename_to_utf8 (const gchar *opsysstring);
 gchar*   g_filename_from_utf8 (const gchar *utf8string);

So it's relatively easy to fix all such cases.

The patch for a non-unicode app is certainly going to cover a lot
fewer lines of code with UTF8, though conceptually you're doing the
same thing, you just avoid a lot of busywork hassle by keeping the
char* type.

Also you can use ASCII string literals with UTF8, which means you can
usually use string literals (most apps use English for their gettext
keys). People simply won't accept not being able to use string
literals.

Havoc



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]