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


On Wed, Jun 21, 2000 at 12:26:30AM +0200, Martin v. Loewis wrote:
> > 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.)
> 
> Right. The standard does not mandate that programs can be combined by
> sticking translation units of ISO 14882:1998 and ISO 9899 together.
> 
> However, any self-respecting implementation of C++ should provide that
> kind of interworking, and I definitely would want g++ to be such one.

Agreed.  But that doesn't mean we should not define our own 
implementations of C Library functions where the ones that come 
in libc are insufficiently flexible. 
 
> > You are assuming that somebody has suggested these things not be
> > done.  But those things are precisely what Dietmar suggested to do.
> 
> 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.

If ICU is (as I believe) the product of the Taligent work, it implements 
the most advanced internationalization support on the planet.  It would
be incredibly valuable to integrate support for those libraries and 
databases.  It don't doubt that it would be painful, too, for a while.
 
> > 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.
> 
> 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?

The Standard C Library is only a tiny fraction of what is in glibc.

My estimation of relative size comes mainly from Plauger's reports 
comparing his implementations of both.
 
> > 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.
> 
> 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.

I want to achieve access to incredibly powerful internationalization
semantics and databases, via a standard interface where possible, and
via extensions where necessary.

The committees that define POSIX and related internationalization
features have failed to deliver what it takes to "get the job done", 
probably because they generally don't write code themselves.  The 
Taligent people succeeded, and have now released their work.  It 
would be a pity to implement only much less powerful semantics 
because we choked on the real thing.

Nathan Myers
ncm at cantrip dot org


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