This is the mail archive of the libstdc++@sourceware.cygnus.com mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Development status


> Indeed, most of this work has already been done, in the shadow/ directory.
> (See also http://www.cantrip.org/cheaders.html .)

I don't mean to belittle your work, but I think that this approach is
essentially a work around "broken" C libraries. This work-around has
to be used on systems where we don't supply the C library.

On a GNU system, we have full control over every single source line in
the system. So we can make it work how we would like it to work,
without having to put one kludge on top of another.

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

Well, I may disagree, but I still provided a patch to implement the
feature that you requested. I'm not that much pushing for inclusion of
that patch, that is true.

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

Where exactly does the standard allow the names to be visible
globally? 17.4.1.1/2

# All library entities except macros, operator new and operator delete
# are defined within the namespace std or namespaces nested within
# namespace std.

Seems pretty clear to me.

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

Use of -fnew-abi is strongly discouraged, it is an experimental
feature and subject to change without notice. I don't see why that is
required for gcc 2.95.2; if -fsquangling is what you really want, then
use that.

Regards,
Martin

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]