C++ library for egcs

C++ library for egcs

[Ulrich Drepper]

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   `------------------------

Re: C++ library for egcs

[Joe Buck]

> Some of you might already have heard that Nathan Myers and I currently
> rewrite the libstdc++ to be compliant with the FDIS...

> - 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.

While I want us to have a standard-conformant library, I'm also worried
about breaking every C++ program in the world.  Will you provide
<iostream.h> that includes <iostream> and moves the iostream names
into the global namespace?  In compatibility headers we shouldn't say

using namespace std;

rather we should say

using std::ios;
using std::streambuf;
using std::istream;
using std::ostream;
using std::iostream;

etc (choose specifically which names to "pollute" the global namespace
with).  Only the "classic" names would need to be exported (those names
that were present before iostream became a template).

>   + 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.

Which headers are you talking about?  stl_map.h and such?

> - 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.

Great.  Will there be any issues with linking when a user chooses
different options (namespaces vs no namespaces).

> 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.

This would be a good thing.

> 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.

After the recent X11R6.4 experience some may be reluctant to loosen up
the license too much.  But the current license (GPL with an exception
if you use gcc) is clearly a problem for SGI, since they have their own
compiler; the license discriminates against other compilers (even free
ones like lcc).

One possibility is to just make a small change in the "special exception"
clause.  It now reads

// As a special exception, if you link this library with files
// compiled with a GNU compiler to produce an executable, this does not cause
// the resulting executable to be covered by the GNU General Public License.
// This exception does not however invalidate any other reasons why
// the executable file might be covered by the GNU General Public License.

s/files compiled with a GNU compiler/other files/

It would seem the effect is then like the LGPL but without the LGPL
rules on reverse engineering, or shipping in relinkable form.

> 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.

I'm in favor of compatibility code -- not to provide bug-for-bug
compatibility but for people who carefully read the ARM when they
wrote their code, but are now hosed by namespaces and templated
stream classes.  The compiler is for the users, it is not just some
academic exercise where we get an A if we perfectly match the spec.

If compatibility code is present when users say <header.h> and absent
when they say <header> that seems like a reasonable approach, if it
can be made to work.  Older programs will generally use <header.h>.
But we shouldn't break the tradition that by default, we are somewhat
liberal, and users add switches like -ansi and -pedantic if they want
to be more rigorous.

The practice I'm most concerned about is that users tend to write

class ostream;

Historically this has been a wise thing to do -- compilation time on
big projects is improved greatly if you do this, and the committee
broke it.

> 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.

I would like for the new code to be distributed.

Re: C++ library for egcs

[Martin von Loewis]

> The practice I'm most concerned about is that users tend to write
> 
> class ostream;
> 
> Historically this has been a wise thing to do -- compilation time on
> big projects is improved greatly if you do this, and the committee
> broke it.

How much of a real problem is this? In a compliant C++ library, this
declaration in itself is correct, even if you include <iostream>
later. 

The problem comes when they include <iostream.h>, as it will have a
using declaration for std::iostream. With a using directive, it would
be still correct. Of course, the problem comes later when you actually
use ostream, and it isn't defined.

I think there is no better way than telling users to include iosfwd.
If you use more than one compiler, you'd have to feature-test presence
of iosfwd in your code, anyway.

Martin

Re: C++ library for egcs

[Martin von Loewis]

> No, in compliant C++ code, is is *not* correct.  ostream is now a typedef!
> ostream is really basic_ostream<char>.  This breaks the world.

No, it is correct. I assume we both talk about

class ostream;

#include <iostream>

This is correct, as it expands to

class ostream;
namespace std{
  //...
  typedef basic_ostream<char> ostream;
}

There is nothing wrong with that, you have an incomplete class
::ostream, and a typedef std::ostream. They are not the same,
but they aren't conflicting, either.

Martin

Re: C++ library for egcs

[Joe Buck]

> 
> > The practice I'm most concerned about is that users tend to write
> > 
> > class ostream;
> > 
> > Historically this has been a wise thing to do -- compilation time on
> > big projects is improved greatly if you do this, and the committee
> > broke it.
> 
> How much of a real problem is this? In a compliant C++ library, this
> declaration in itself is correct, even if you include <iostream>
> later. 

No, in compliant C++ code, is is *not* correct.  ostream is now a typedef!
ostream is really basic_ostream<char>.  This breaks the world.

> The problem comes when they include <iostream.h>, as it will have a
> using declaration for std::iostream.

No, you are missing the point.  That is not the major problem.

Re: C++ library for egcs

[Joe Buck]

> 
> > No, in compliant C++ code, is is *not* correct.  ostream is now a typedef!
> > ostream is really basic_ostream<char>.  This breaks the world.
> 
> No, it is correct.

Only for a pedantic meaning of "correct", that is that yes, it is a
conforming program, but no, it doesn't do what the user wanted it to
do when s/he wrote it, and the program won't link.

But maybe you are on to something -- it occured to me that we might be
able to use this fact to do a compatibility hack, if we munge the linker
to remap foo(ostream&) into foo(basic_ostream<char>&) or add a
compatibility library that has stub functions to do this.

Re: C++ library for egcs

[Martin von Loewis]

> Only for a pedantic meaning of "correct", that is that yes, it is a
> conforming program, but no, it doesn't do what the user wanted it to
> do when s/he wrote it, and the program won't link.

I was aiming at the pedantic aspect only. Later I found that it isn't
really the template that makes the usage you describe incompatible -
the namespace std alone would have done it. I.e.

class ostream;
namespace std{
  class ostream;
}
using std::ostream;

is already illegal.

> But maybe you are on to something -- it occured to me that we might be
> able to use this fact to do a compatibility hack, if we munge the linker
> to remap foo(ostream&) into foo(basic_ostream<char>&) or add a
> compatibility library that has stub functions to do this.

A compatibility library might actually work. <iostream.h> would then
read

class ostream: public std::ostream{};

The only question is what ::cout would be.

Martin

Re: C++ library for egcs

[Benjamin Redelings I]

> 
> 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.
Hmmm... kind of worrisome...

>  I cannot give more details on this now.
OK, but its still kind of worrisome.

-BenRI

Re: C++ library for egcs

[Daniel Egger]

On Wed, 08 Apr 1998, you wrote:

>Speak up now or never :-)

 Necessary and right.....

--

Servus,
       Daniel