This is the mail archive of the
libstdc++@sourceware.cygnus.com
mailing list for the libstdc++ project.
[Fwd: Re: sgi's std, stlport...]
- To: STDC++ <libstdc++ at sourceware dot cygnus dot com>
- Subject: [Fwd: Re: sgi's std, stlport...]
- From: Levente Farkas <lfarkas at mindmaker dot hu>
- Date: Wed, 05 Jul 2000 15:13:19 +0200
- Organization: Mindmaker Ltd.
- Reply-To: lfarkas at mindmaker dot hu
and another:-)
-------- Original Message --------
Subject: Re: sgi's std, stlport...
Date: Wed, 5 Jul 2000 06:04:20 -0700 (PDT)
From: Dietmar Kuehl <dietmar_kuehl@yahoo.com>
To: lfarkas@mindmaker.hu
Hi,
after sending my answer on your request I noticed that I have not sent
it to the mailing list but only as a private answer to you. Thus, your
answer was also not sent to the mailing list...
> wouldn't it be useful to merge or somehow syncronize sgi's patch and
> stlport patch to stdc++ ? mainly in iostream and locale part.
SGI/STLport took a very different approach to implement IOStreams and
locales. ... and this is, in turn, again very different to the approach
I have taken for CXXRT. Although it is probably possible to share at
least parts of the implementations in this area, it is questionable
which part to choose and actually I think there is even and advantage
in having a variaty of different implementations.
> if they are really different and it's not possible to try to approach
> these implementations?
My personal thinking is that we should look at all three free
implementations at one point and join them. However, I don't think the
time to merge them has come already. In fact, I'm planning to diverge
even more than I have already done: I'm thinking of a new
implementation of the STL. Currently, there is basically only one
version of this library implemented: All STL implementations have the
HP STL at their root. I think it is quite reasonable to do certain
things rather different from the current implementation. ... and apart
from a possibly better approach this is actually also likely to reveal
weaknesses in the specification...
Variaty is not bad because it provides experience with different
approaches. I can definitely see advantages in my style to implement
the standard C++ library, eg. relatively short compile times. I think
it is reasonable to analyse the different implementations for their
respective advantages to create an even better implementation.
Regards,
Dietmar
=====
<mailto:dietmar_kuehl@yahoo.com>
<http://www.dietmar-kuehl.de/>
__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/