Collation implementation

Nathan Myers ncm@cantrip.org
Tue Jun 20 02:23:00 GMT 2000


On Tue, Jun 20, 2000 at 09:05:55AM +0200, Martin v. Loewis wrote:
> > You see unlike the other I18N libs that are floating around this is
> > the only one that has a complete back end locale support without
> > depending an iota on the system facilities and has support for more
> > locales/countries/languages than most of the commercial OS'es with
> > the exception of maybe win2k.
> 
> You see this is not true. The glibc locale implementation has all the
> same properties.

If I am not mistaken, the IBM files support quite a lot more semantics
than the glibc files.

What matters most here is not the code that reads the files, but the
formats and contents of the files themselves.  I see no reason they
could not become a standard part of many GNU/Linux distributions,
accessible by any program that chooses to read them.
 
> > Which of those in turn support complex text and layout like Arabic?
> > Which of them support bi-directtional text?
> 
> How is this relevant to libstdc++?

The Standard C++ Library locale facilities were specifically 
designed to be extensible, and extended.  It would be wonderful
to see support for the additional semantics supported by the 
IBM data files accessible directly from C++ locale objects.
 
> > I18N is much more complex than people think and IBM did a very
> > admirable thing in releasing ICU.
> 
> I don't question that statement; it may be a perfect solution in
> another universe. For the universe I live in, it seems to have a
> number of problems.

What problems, please?
 
> > And if ppl still want to ignore it then may I ask what other option
> > do we really have that does all that?
> 
> To me, the reasonable options are:
> - use the glibc's __newlocale stuff
> - use Matt Austern's system integration library
> 
> Shipping a locale database with libstdc++ is not very attractive, IMO.

Providing users the ability to plug in different locale databases
underneath is extremely attractive.  There's no reason the C Library
subset of the Standard C++ Library shouldn't use the same facilities
as the rest of the library.

Nathan Myers
ncm at cantrip dot org



More information about the Libstdc++ mailing list