Re: Development status

[Nathan Myers <ncm at cantrip dot org>]

On Mon, Apr 10, 2000 at 01:25:35AM +0200, Martin v. Loewis wrote:
> > glibc 2.2 development :  http://www.cygnus.com/~drepper/TODO.html
> 
> # Somebody should work together with the C++ people to determine what
> # can and should be done to help them implement the ISO C++
> # library. This mainly includes support for the std:: namespace.

Very little is needed in glibc to help support libstdc++.  This is 
partly because libstdc++ must work without glibc.  There is no reason,
though, not to take advantage of extra features found in glibc during
configure/make even though we can't depend on those features in general.

One example of such a feature might be full support for locales other
than "C" and "POSIX".
 
> Besides std::, there is another issue: In C++, C library functions
> must be implemented as functions, even though the C standard allows to
> implement them as macros. Likewise, names documented as macros must be
> implemented as such, even though the C standard allows to implement
> them as functions (17.4.1.2/5; C++ lists assert, errno, offsetof,
> setjmp, va_arg, va_end, and va_start as macros). 
> 
> Maybe this requirement is already implemented, if so, the better. If
> not, I'd volunteer to provide the necessary patches.

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

>    ...For gcc 2.95,
>    the added code is a no-op anyway (because std:: is ignored), so
>    there is no real compatibility problem.

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.

It is possible we could take advantage of glibc's libio if it
were to be changed to match the -fnew-abi semantics; for the old
libio(s), we must use the same interface layer we need for any other
libc.

Nathan Myers
ncm@cantrip.org