Collation implementation

[Martin v. Loewis]

> |Right. The standard does not mandate that programs can be combined by
> |sticking translation units of ISO 14882:1998 and ISO 9899 together.
> 
> Binary compatibility with translation units of C and C++ doesn't necess-
> arily mean that even locales are going to be absolutely compatible.

No. That was in response to Nathan's proposal that libstdc++ could
provide replacement functions for the C locale functions. When doing
so, one would have to be very careful to not violate the C library's
calling conventions. That's easy for setlocale, but harder for
localeconv.

Also, one needs to be careful that all C semantics is not violated
when providing such a replacement. Then the question is whether
std::setlocale is the same symbol as setlocale(3C); if it is, you'd
also have to replace all functions that are effected by the outcome of
setlocale. The problem here is that not only standard C functions are
effected, but potentially other functions provided by the C
library. Eg. in glibc, it would also affect nl_langinfo.

> Ok let me clarify a bit. I do not want any kind of integration with
> ICU. All I want is that I should be able to also use ICU for the locale
> data other than whatever is the default. I don't care what C wants to
> use but I atleast want to be able to use ICU in C++. It may be painfull
> hard or nonstandard but there should be a way. There is a very good
> reason why I want things that way but more about that later.

Well, there is a way: Just use ICU in your application, instead of the
standard C++ classes. Namespaces and other mechanism in C++ make it
easy for programmers to combine different libraries.

> Hello glibc has loads and loads more than just the strict C library.

Of course.

> Just because most *NIXes include most of their system calls and
> POSIX stuff in the C library binary doesn't mean that they are all
> in the C library or that other systems would also provide it.

I thought the proposal was that libstdc++ could come with its own copy
of a C library. That would be only useful to compiler users if this C
library also provided all the other functions provided by the system C
library, as most likely it would not be possible to combine the two in
a single operating system process, for structure layouts and function
names would conflict.

> I don't know whether the count of libstdc++ included the STL part of
> the Std C++ lib- rary since libstdc++ simply uses a modified version
> of the SGI STL instead of writing one. So maybe its count is not
> included.

Just look and count for yourself. It was included.


> In any case what Nathan is saying is very true. The strict C library
> is nowhere near what the C++ library is in terms of functionality
> and size, notwithstan- ding people whose only view of computing is
> *NIXish and POSIXish.

I thought the conclusion was that it is feasible to integrate a C
library with the C++ library. It is not.

> Exactly! How true. Take a poll around as to how many people really
> use the C library locales. At least around me I can find no project
> that does.

How about GCC? cppmain.c has setlocale (LC_MESSAGES, ""), and c-lex.c
has setlocale (LC_CTYPE, ""). I believe most GNU programs have a call
to setlocale these days. But perhaps you have no GNU programs around
you...

> In fact I got a private mail form Chip Salzenberg of VA Linux that
> he was going to use ICU for Perl 6.

As I said: There is freedom of choice for application programmers to
use whatever library they want.

> Why can't I use the C++ locale stuff for real world work if
> possible? It would be criminal if such a well designed extensible
> C++ locale facility cannot be plugged in with the best I18N
> framework library.

Ok, I have repeatedly listed a number of problems I see. Let me put it
differently: Just try to integrate ICU, and see what kinds of problems
users report afterwards.

Regards,
Martin