C++ library for egcs

[Ulrich Drepper <drepper at cygnus dot com>]

Hi,

I've sent a similar mail quite some time ago to the main developers
and contributors of egcs but got one single reply only.  Either this
means there is no interest or no disagreement.  Anyhow, I'll present
it now and here a wider audience since this is a rather fundamental
change.


Some of you might already have heard that Nathan Myers and I currently
rewrite the libstdc++ to be compliant with the FDIS.  This is a
non-trivial task given the history of the current implementation but
we hope to come out with first results very soon.

We would like to use the new code in egcs, replacing the old libstdc++
implementation but since the egcs development is controlled
collectively I'm writing here to get comments.  If there are concerns
they will be addressed.


Some details about the rewrite:

- we will follow as close as possible the standard.  This has some
  consequences for code which does not use the library correctly.
  Especially since martin is making great progress with the namespace
  code some code which compiled in the past will have to be changed.

  + code which uses internal headers not defined in the standard will
    have to be changed.  The headers will be removed or at least renamed
    or moved.

  + for namespace reasons, internal classes will be renamed and/or put
    into separate namespaces

  + accidently available internals of classes will not be available anymore
    (I don't know about any case but if there is one, we most probably
     eliminated it)

- headers will be cleaner.  I don't think this is a point to disagree :-)
  It means that we will have no tons of #ifdef for all the different
  architectures.  All remaining #ifdefs will handle fundamental options
  like using exceptions or not, using namespaces or not etc.  Everything
  will be controlled using feature select macros.  Those of you familiar
  with the GNU libc can imagine who this works.

- also controlled using feature select macros will be the addition of
  non-standard extensions.  There are some critical cases which make
  this difficult but we (the SGI group and we) hopefully found solutions
  for this.

  When namespaces are activated this means code using extension will have
  to make efforts to use the correct namespace.



In discussions with the group working on the library at SGI (Matt,
you're listening?) we've discussed the possibility to continue
developing the together and even get to a single source distribution.
Details about the organization of the sources must be discussed but the
SGI group had at the time I presented my design no problems with it.

I think this is a big point since we have to collect a large user base
for the library to have a non-neglectable voice when it comes to
interpretations of the standard and for the future extension (in five
years).

To make a close collaboration with SGI possible we will have to think
about the license used for our libstdc++ code but work is underway and
some of you were already contacted.  I cannot give more details on
this now.


One of the demands of the SGI group was to add compatibility code.  We
will most probably end up in adding such code (or mainly, add
appropriate headers) but I am strongly against making this the default
or even encourage people to use this option.  IMO broken code should
be fixed _now_ and once.  This ensures the usability of the code in
future and it will improve the portability (somthing new in C++
programming).


OK, that's what I can say in the moment.  Comments on this are
appreciated.  If there are no complains we will start distributing the
rewrite with egcs ASAP and replace the existing library completely as
soon as we achieve a certain level of correctness.

Speak up now or never :-)

Thanks,

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------