C/C++ C++ header files with and without h extension

[PainterGuy]

c++ header files with and without "h" extension

hi fine people,

i have seen some people use header files with ".h" extension and some without it. what is reason? i think there are some header files where you are required to use ".h" such as "#include <windows.h>. you can not use "#include <windows>". perhaps it has something to do with compiler. mine is dev-c++. tell me what you think about this. i know you can tell me.

cheers

 

[jtbell]

Once upon a time, before the first official C++ standard was promulgated in 1998, all C++ headers had .h: <iostream.h>, etc.

With the 1998 standard, it was decreed that all C++ standard library headers would be without the .h: <iostream>, <string>, <vector>, etc. Compiler-specific headers and headers that programmers write for libraries they create, have .h.

Most compilers still accept the old pre-standard .h headers for backwards compatibility, but the functions defined in them may not behave quite the same way as the corresponding functions in the "new" standard headers.

Your <windows.h> is obviously intended for programming Microsoft Windows - specific functions, and therefore is not a standard C++ header.

 

[I like Serena]

Additionally the 1990 C standard defined a number of header files with .h.
These header files have been incorporated into the 1998 C++ standard and they still work.
However, with the new thought that standard C++ header files should not have .h, the same files can also be included without .h, but they do need a "c" prefix then.
Moreover, all standard C++ functions and symbols reside in the namespace "std" now, although the old-style header files still reside in the global namespace.

For instance in C++ the following 2 code fragments are equivalent:

#include <stdio.h>
scanf("%d", &number);

#include <cstdio>
std::scanf("%d", &number);

Note that non-standard C++ header files are conventionally still written with .h, such as <windows.h> and any header file that you introduce yourself.

 

[D H]

The file suffix, if any, used in #include preprocessor statements is purely conventional. The C preprocessor just doesn't care. The preprocessor is a different language than C/C++ and is at best weakly coupled with C/C++. This weak coupling has enabled people to employ the preprocessor in a wide variety of non-C/C++ applications, everything from java to html to imake.

 

[PainterGuy]

many thanks all of you for sharing this with. i think i get it now.

cheers

 

[AlephZero]

The file suffix, if any, used in #include preprocessor statements is purely conventional. The C preprocessor just doesn't care.

That is true in general, but the standard headers need not be provided as files on disk at all (though they usually are, if only so humans can read them when they can't understand what the documentation means!). The standard headers may be stored in a special format to speed up the compilation process, or even built into the compiler itself.

If you #include <cstdio> with no extension, you should be guaranteed to get the standard header. If you #include <cstdio.h> or even worse #include "cstdio.h". you might pick up a file with the same name but different contents, from a different directory in the search path for headers files.

At best, intentionally hijacking a standard file name is very dubious programming practice. At worst, you might pick up a header file that turns your program into malware without your knowledge.

 

[D H]

If you #include <cstdio> with no extension, you should be guaranteed to get the standard header.

There is a guarantee, but it is not the one that you expect. The guarantee is that #include <cstdio> will result in undefined behavior if the compiler finds a file named cstdio that is not the cstdio provided with the implementation while searching in the "standard places".

So what are those "standard places"? The standards for both C and C++ punt on this: It's implementation-defined. How or whether those "standard places" are defined/modified: Implementation-defined. The difference between #include "file_spec" and #include <file_spec>: Implementation-defined, for the most part. There is one guarantee in the standards: If #include "file_spec" doesn't work, the compiler is to treat that directive as if it had been #include <file_spec>.

In every implementation I have come across, the key difference between #include "file_spec" and #include <file_spec> is that the former searches the directory containing the current file being processed while the latter does not. The Gnu compilers provide the -iquote option to define a quote search path that is distinct from the bracket search path, but I've never seen anyone use that option. Gnu also provides the now deprecated -I- option to split the search path into quoted and bracketed parts. I've never seen anyone use that, either. (I have however seen programming standards that forbid the use of this option.)

 

[D H]

Moderation:

Off-topic discussion of programming standards for C++ moved to a [thread=488806]separate thread[/thread][/color].