Collation implementation

[Martin v. Loewis]

> > 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?

It doesn't interwork with the system locale and database in a
reasonable way. For example, if an application creates a
unparametrized locale("") object, LANG or other system settings should
be taken into account, right?

Now, it seems quite hard to arrange that setlocale(LC_ALL,"") and
locale("") do indeed the same things - most likely, locale names
differ, so the user could set only either the C locale or the C++
locale, or would have to use two different environment variables.
Likewise, the mechanism to detect system/user settings varies among
platforms; the libstdc++ locale should take these mechanisms into
account, instead of having some hard-coded implementation.

> 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.

Are you saying you want to replace this part of the C library with
your own code? How exactly could that work, short of providing an
entire C library yourself? You not only have to provide C
implementations of setlocale and localeconv, but also printf,
strftime, isspace (which may be a macro!!), etc. Also, I can't see how
linking of C libraries using these functions could possibly work, as
they would have been compiled with the C library headers, instead of
with those provided by the C++ library.

Regards,
Martin