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: Collation implementation


|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. C++
should have a good locale implementation irrespective of what C can
provide for. Of course C++ should try to maintain compatibility with
C as much as possible.

|I'm fine with Dietmar's proposal of accessing the system locale
|databases through a common interface. It's Shiv's proposal of
|integrating ICU that I feel uncomfortable with.

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.

|Counting the number of lines in glibc 2.1.3, I get 1,148,374. Counting
|those of libstdc++-v3 in today's CVS, I get 120,561. What makes you
|say a C library is only a tenth of a C++ library?

Hello glibc has loads and loads more than just the strict C library.
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 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. 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'm not sure what you want to achieve. Conformance to some written
|standard is not all there is. People don't use a compiler just because
|it conforms to a standard. Instead, they want to get their job done.

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. As to ICU at least three projects around me use it because it is
the only thing that can get their I18N jobs done! And these include
both open source and commercial projects. In fact I got a private mail
form Chip Salzenberg of VA Linux that he was going to use ICU for 
Perl 6. 

Now the C++ locale facility is very well designed so that user can add
new locales or new aspects of locales that the Std can't mandate
and provide for. But real world frequently needs more. ICU fits very
nicely for this purpose. 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. People who want extensive I18N will try to do
that with ICU anyway since they have to use it. Somebody will surely
do work to make libstdc++ work with ICU even if I don't.

I don't want to argue about this on and on. But there are very good
reasons for wanting all this.
Thanks,
Shiv


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