Re: .h for standard headers

From: P.J. Plauger (pjp_at_dinkumware.com)
Date: 05/19/04 

Date: Wed, 19 May 2004 14:49:38 GMT

"David Fisher" <david@hsa.com.au> wrote in message
news:RNyqc.1431$2v1.2599@nasal.pacific.net.au...

> P.J. Plauger wrote:
>
> >> David Fisher wrote:
> >> According to Chuck Alison in the article "What's New in Standard C++"
> >> (http://www.freshsources.com/newcpp.html), old style library headers
are
> >> deprecated ... here is the relevant quote:
> >>
> >> Invoking Standard C Headers with a .h suffix
> >> --------------------------------------------
> > >
> >> We traditionally think of headers as files, but a compiler is free to
> make
> >> a header's declarations available in any manner it chooses. To
encourage
> >> this point of view, the C++ standards committee voted rather early to
> >> drop the .h suffix for C++ headers. This means that you should use
> >> "#include < iostream>" instead of "#include <iostream.h>", although
> >> most compilers will allow both. When namespaces were added to the
> >> language, the committee decided to wrap most C++ and all standard
> >> C library declarations in the standard namespace std, and to rename
> >> the C headers by prepending a 'c' and dropping the .h suffix. This
> >> means that the preferred method of getting at C library features is the
> >> same for using C++ library elements, for example
> >>
> >> #include <cstdio>
> >>
> >> int main()
> >> {
> >> std::printf("hello, world\n");
> >> }
> >>
> >> Thinking that this might be too much of a culture shock, the
> >> committee decided to deprecate instead of to disallow altogether
> >> the traditional ".h" method. For now, if you say "#include <stdio.h>",
> >> it's as if you had written "#include <cstdio>" followed by a using
> >> declaration for each identifier defined in the header (so you don't
> >> have to use the std:: prefix).
>
> > True in theory, not always in practice.
>
> Only with reference to the last bit, or some of the other statements too ?
>
> Do you have a feel for how widely these guidelines are actually followed ?

The fundamental arrogance in the C++ Standard was thinking that
it could usurp the central role of the C headers in a typical
implementation. To conform fully to the C++ Standard, an
implementation effectively has to make <cstdio> the fundamental
header. It declares all names within namespace std. The newly
demoted <stdio.h> then would do much as Chuck says: include
<cstdio> and then hoist each declared name individually into
the global namespace with a separate using declaration. (You
can't use an omnibus declaration to hoist all the names at once,
for a variety of reasons. But that's just a nuisance for the
implementor.) As icing on the cake, the C++ Standard then puts
the world on notice that headers like <stdio.h> will one day go
away, because they're deprecated.

This is nonsense. As several of us vendors repeatedly warned the
C++ committee, the C headers are and will long remain the true
fundamental headers describing the Standard C library component
of the Standard C++ library. A gazillion technical, political,
and administrative reasons combine to keep most C++ implementations
from fully conforming to the C++ Standard in this regard. The
common practice is to leave the C headers alone (aside from a bit
more crud wrapped in #ifdef __cplusplus/#endif envelopes.) Instead,
<cstdio> includes <stdio.h> and hoists names from the global
namespace into namespace std. The differences in effect can be
kept small, with a not-unreasonable coding style, but they're there.
And they're one more reason (besides export templates) why many
implementations can't claim 100 per cent conformance to the C++
Standard.

FWIW, a couple of libraries do meet these requirements. Metrowerks
and RogueWave as shipped with Solaris C++ are two that spring to
mind. The Dinkumware libraries can be configured to fully
conform, but interestingly enough many of our OEM compiler vendors
still choose not to. Libraries like libstdc++ (shipped with gcc)
and STLport are dependent on underlying C libraries supplied by
others, so they can't fully conform. Needless to say, those
underlying C libraries seldom supply even the simple additions
required by the C++ Standard, much less accommodate draconian
restructuring for namespaces.

I also don't like the loss of the .h suffix on C++ headers. Too
many tools exist that are inconvenienced, to say the least, if
there's no *.xx for some xx to identify groups of files. But
that's another battle I lost.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

Relevant Pages

  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... So because others here can't think of a good reason to use long instead of size_t and you can't prove there is never such a reason, we must all assume there could be a good reason to not use the mechanisms provided by the standard to deal with a problem? ... If you are claiming there is a reason to avoid the mechanisms the standard provides to allow portability then it is up to *you* to prove your point, not up to others to disprove it. ... but you can hardly blame the consequences on the Standard headers. ...
    (comp.lang.c)
  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... So because others here can't think of a good reason to use long instead of size_t and you can't prove there is never such a reason, we must all assume there could be a good reason to not use the mechanisms provided by the standard to deal with a problem? ... want to have standard headers included in their own headers which ...
    (comp.lang.c)
  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... but you can hardly blame the consequences on the Standard headers. ... to use strndup, it's personal matter between user and his C ...
    (comp.lang.c)
  • Re: Standard C library functions
    ... > be a part of Standard C library? ... K and R decided that C would be a very slim language, ... > Do I get these standard C libraries along with the C compiler? ... Do I get these standard headers along with the ...
    (comp.lang.c)
  • Re: Organization of standard and 3rd party libraries
    ... you think Ruby's standard library would be better if it was ... library developers to categorize their libraries better as well? ... interesting then is to be able to "include" a namespace. ...
    (comp.lang.ruby)