Re: correct "C" headers, higher priority

[Stephen M. Webb <stephen at bregmasoft dot com>]

On Thu, 31 May 2001, Nathan Myers wrote:
> 
> There's no expectation but that it's hard and messy to conform by
> building on top of existing C headers.  Dietmar has implemented his
> library the "right" way: he has his own Standard C library integrated,
> implemented on top of the C++ facilities.  Dinkumware integrates them,
> too, albeit in a far more blinkered way.
> 
> It's pretty easy to provide a Standard C Library as part of the Standard
> C++ library.  The trick is how to get all the other crap that is shoveled
> into every real C library.
> 
> The shadow headers try to provide an integrated C library that *just 
> happens* to be implemented by calling the underlying C library.  They
> cheat by aliasing the most of the underlying C names instead of actually
> forwarding to them.  
> 
> They try to keep underlying C names (particularly nonstandard ones) from 
> polluting the global declaration space, although they cannot protect the 
> global link space.  Maybe abandoning that goal is the secret to simplifying 
> them enough to make the idea practical.

Wait, I just got it.

I've been trying to figure out how to build the <c...> headers by leveraging the
C library headers.  Perhaps this is entirely the wrong approach.  Maybe what
should be done is implement the C++ library on top of the C library, but keep
the headers discrete.  For example, std::strlen() would be declared extern in
<cstring>, and the definition of that finction in some .cc file would simply
forward the ::strlen() function from the underlying C library.  Forgive me if
this is too obvious, but none of the C++ standard libraries I've examined take
this approach (I don't have access to most proprietary ones).

This approach would keep the global name space pristine, wouldn't introduce the
reams of macro hackery that all the third party libraries (and the c_std and
shadow headers) use, and would fix the fragility that other solutions
(c_legacy headers, Scott Snyder's idea) introduce.  It would lack the advantage
of inline passthrough functions the current schemes have, and it would
complicate the implementation of Appendix D headers, but it would be clean,
elegant, and portable to all platforms.  It does not touch the issue of global
link space, but the tradeoff is somewhere.

The big problem I can think of is the whole C macro thing.  The C++ standard
requires certain preprocessor macros to be defined in certain headers (a major
flaw in the standard as far as I'm concerned, since C++ provides facilities in
the language for most of those things so there's no need to resort to text
preprocessing of source code to imlement them).  Perhaps there is an elegant
workaround for this issue as well -- eg. macros that resolve to C++ symbols
exported from the library.  I'll ponder more on this when I can get home to my
copy of the Standard.

Any thoughts on this approach?

Stephen M. Webb