[RFC] "C" header options

[Stephen M. Webb]

On Thu, 07 Jun 2001, Benjamin Kosnik wrote:
> The way I see it, the following options exist:
> 
> 1) remove changed "C" signatures and builtins in string/wchar/math
>    and have c_compatibility headers that just include_next<foo.h>

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.

> 2) use changed signatures, builtins and figure out a way to make
>    c_compatibility headers work for string/wchar/math
>    seems fragile

This is what we're doing now and it's not working.

> 3) remove "C" linkage requirement a la Stephen Webb's proposal
>    which also removes inlining

This wouldn't be release-ready for 3.0 anyway unless limited to a
subset of the headers (cstring and cmath would work) but users will
expect a consistent implementation:  do 'em all or none of 'em.

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

> 4) remove compatibility requirement, and just use <cfoo> headers with
>    this strange hybrid of zack's proposal from yesterday and a
>    completely revised c_shadow. Strangely enough, this works if one
>    simulates a PCH for the "C" headers (one include that includes all
>    required "C" headers one after the other in _C_legacy and then the
>    std_c*.h bits just include the PCH)

I spent quite a while working at this approach (my so-called "c_legacy"
headers proposal).  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.

> Ack. It looks like 1) is the only option that is at all robust.

Well, 3) is also robust, but not yet ready.
 
> I have sources that do all of these options, more or less. I'm going
> to take a break for a bit, and see what others think.

I think the way to go is drop back to 1) for 3.0.  Like I say, it's hard to
argue with "it works."  Obviously application code will be portable, since
other libraries do it that way.

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

Stephen M. Webb