Collation implementation

[Nathan Myers]

On Tue, Jun 20, 2000 at 06:27:34PM +0200, Martin v. Loewis wrote:
> > > 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?

Right.  That is of course the responsibility of the implementator
of locale()::locale() and of setlocale().  (Note that std::setlocale(),
and even ::setlocale(), need not be the same function as found in 
libc.so.)
 
> 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.

You are assuming that somebody has suggested these things not be
done.  But those things are precisely what Dietmar suggested to do.

It would of course be better for the C library and C++ library to 
cooperate in this, to avoid duplication and conflict.
 
> > 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? 

The actual Standard C library is only a tenth as large as the Standard
C++ Library.  Re-implementing just the necessary parts (a much smaller
fraction again) would not be a very big job.

> You not only have to provide C
> implementations of setlocale and localeconv, but also printf,
> strftime, isspace (which may be a macro!!), etc. 

Re-implementing printf, strftime, and the handful of other functions 
affected by locales to enable them to use the current C++ locale would 
be much easier than what has been done already.

In C++, isspace() is not permitted to be a macro.  Of course C code
uses whatever macro is was compiled with, leading to . . .

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

We would need to plug in just the underlying data structures and 
helper functions used by the C library macros.  Of course this would 
depend on details of the C library you were patching, and wouldn't be 
portable to other C libraries, but each other C library would have a 
similar (small) set of such symbols.

This is not to say that duplicating functionality is a good.  However, 
given the attitude we are encountering it may be necessary if we are
to achieve what we want.

Nathan Myers
ncm at cantrip dot org