This is the mail archive of the
mailing list for the libstdc++ project.
Re: [RFC] "C" header options
- To: "Stephen M. Webb" <stephen at bregmasoft dot com>
- Subject: Re: [RFC] "C" header options
- From: Benjamin Kosnik <bkoz at redhat dot com>
- Date: Fri, 8 Jun 2001 11:32:19 -0700 (PDT)
- cc: libstdc++ at gcc dot gnu dot org, mark at codesourcery dot com, jason at redhat dot com
> This is what we used to have that worked. It's what KCC, the STLport, and
> Dietmar Kuehl's libraries do. It's not compliant, but it's awfully hard to
> argue with "it works and everybody else does it" when you're shipping
> production code in a week or so.
Done. This is the approach taken. Thanks for the feedback.
> By the way, builtins can still be inlined, and at -O2 the forwarding
> functions seem to be optimized away so there isn't really any
> performance penalty).
Hmm. We'll have to look at this again in a week or so.
> While I could probably get it to work eventually, it
> just seems somewhat gracile. I spent a lot of time dealing with subtleties.
> Subtleties aren't good in a general library. I think the sorts of problems
> I experienced would recur elsewhere on other platforms and multifold with
> cross compilers.
Yeah I'll post details later, so as not to distract people. I did find
some tweaks with the current library code, where a true std:: compliant
strategy found some small defects. I'll post these later.
> It's my opinion, and yes, I am slightly biased here, that 3) is the best choice
> for the long run (read 3.1) since it is robust AND it's compliant AND it's
The more interesting question is what to do with the staging headers
patch of yours, Stephen. I've used it for the last couple of days in my
source tree and I think it is an improvement to what had existed. It
takes some getting used to, but there are some real advantages to
treating all the headers as things that must be built.
As soon as I can bootstrap mainline again I'll work on integrating it and
the "C" header fixes.