This is the mail archive of the
libstdc++@sourceware.cygnus.com
mailing list for the libstdc++ project.
Re: Development status
- To: libstdc++ at sourceware dot cygnus dot com
- Subject: Re: Development status
- From: Benjamin Kosnik <bkoz at cygnus dot com>
- Date: Mon, 10 Apr 2000 09:12:08 -0700 (PDT)
> Indeed, most of this work has already been done, in the shadow/ directory.
> (See also http://www.cantrip.org/cheaders.html .)
>
> We just need to set it up as the default installation, and finish up
> any loose ends. It had appeared to me that some minor compiler changes,
> such as were implemented by Sun, SGI, and DEC, would improve matters,
> but Martin has disagreed with that, so probably we should proceed
> without, and see.
Yeah. Especially now that -fhonor-std and the std:: namespace are assumed,
this work has taken on increased urgency. Both Gaby and I have requested
that the shadow work be cleaned up and be made the default, as per
mknumeric_limits and the other "mkxxxx" scripts at the top level of the
libstdc++-v3 source dir. Nathan, anyway you can do this?
> > As for std::, C++ defines the <cfoo> headers as primary sources, and
> > <foo.h> as derived sources, which essentially have using-directives
> > for all functions.
>
> That is one possible implementation. What the standard requires
> is (1) the types be actually defined in std::, and (2) the function
> names be declared in std::, although they may also be visible
> globally. (Types must not be defined in the global namespace
> because that would interfere with Koenig lookup.)
> We should design for the desired end result, in this case full standard
> compliance and future compiler versions. In particular, we should
> work on the assumption that programs linked with libstdc++-v3 will be
> built with -fhonor-std and -fnew-abi if on gcc-2.95.2. The build
> instructions should reflect that.
-fhonor-std is the only real flag affecting the C header detail: it's
enabled by default now.
-Benjamin