🚀 go-pugleaf

ray@cse.ucsc.edu (Ray Swartz) writes:

>I read in the DWP that the header files for the different libraries
>and classes no longer have a .h on the end.

>However, if string.h is used, then it simply pulls in the
>appropriate parts of the <string> header file.

The situation is a bit complicated. Hold on to your hat.

First let me emphasize that this discussion concerns ONLY the
headers described by the C and C++ standards. Implementations
commonly supply other headers as well. The spelling rules for
non-Standard headers are (obviously) not addressed by the Standard.

When the C++ committee first started to come up with names for the
standard C++ headers, we ran into conflicts in existing practice.
Some variations on the iostream header were, for example:
<iostream.h>, <iostream.hh>, <iostream.H>, <iostream.hpp>, <iostream.hxx>.

If the committee picked any one of these, some vendors and users would
rightly feel discriminated against. But we had to specify something to
allow portable code to be written. So we decided to emphasize the rule
already in the C standard that the spelling of the header need not
specify an actual text file, or if it did, that the spelling of the
file name need have no relation to the spelling of the header. We
specified the spelling of the header without a suffix. Note well
that the standard makes no statement about files or the spelling
of file names.

Thus, in portable code, you will be able to write for example
	#include <iostream>
and you get the iostream declarations as required by the standard,
no matter what the implementation provides as files or how it
spells the file names.

In addition, an implementation may allow other header spellings to
mean the same thing. If an implementation previously used
<iostream.hpp>, it could continue to allow that as a synonym for
<iostream>. Existing code continues to work unchanged, and standard-
conforming code also works correctly. I would expect all
implementations to continue to support their original header spellings
where they do not conflict with other requirements.

So much for the C++ headers. What about the C headers? For
compatibility with C code, the header spellings should not change.
The C "Hello world" program that uses "#include <stdio.h>" should
continue to work.

The only problem with that is the addition of namespaces and the
decision to put the whole standard library in the "std"
namespace. If the C library is in the std namespace, "Hello world"
doesn't work. If not, it is inconsistent with the rest of the
library. The solution was to make it work both ways.

For every standard C header <NAME.h> there is a corresponding C++
version spelled <cNAME>. The <cNAME> version has all declarations
in the "std" namespace. The <NAME.h> version adds a using-declaration
for each name to make them available without qualification.

Consider C stdio. All the declarations are in the std namespace,
placed in a header spelled <cstdio>. Those same declarations are
available in a header spelled <stdio.h>, followed by a
using-declaration for each one.

So you can write
	#include <stdio.h> // usage as in C programs
	main() { printf("Hello, world\n"); }
or you can write
	#include <cstdio> // use of members must be qualified
	main() { std::printf("Hello, world\n"); }
or you can write
	#include <cstdio>
	using namespace std; // all std declarations now available
	main() { printf("Hello, world\n"); }
or you can write
	#include <cstdio>
	using std::printf; // you would get this from <stdio.h>
	main() { printf("Hello, world\n"); }

The original question concerned "string", which I can now answer.

If you use #include <string>, you get the C++ string class header.

If you use #include <cstring>, you get the standard C header
containing the C string functions, all placed in the "std" namespace.

If you use #include <string.h>, you get the effect of <cstring>
plus a using-declaration for each declaration so they can be used
without the "std::" qualifier. Usage is the same as in a C program.
--
Steve Clamage, stephen.clamage@eng.sun.com

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]