Re: include file question
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Sun, 22 Mar 2009 04:50:03 -0500
See below...
On Fri, 20 Mar 2009 10:37:50 -0400, "RB" <NoMail@NoSpam> wrote:
----Scott thanks for quick reply, here are the requested links, etc.****
"Scott McPhillips [MVP]" wrote in messageat http://docs.freebsd.org/info/cpp/cpp.info.Once-Only.html
Where did you read that #pragma once is obsolete? Not so.
Where did you read that #import is obsolete? Not so.
you will find the following about mid way down the page
---------------------------
There is also an explicit directive to tell the preprocessor that it
need not include a file more than once. This is called `#pragma once',
and was used *in addition to* the `#ifndef' conditional around the
contents of the header file. `#pragma once' is now obsolete and should
not be used at all.
What does freebsd have to do with Microsoft C compilers? Why would you care about
documentation of an uninteresting environment? The statement itself is irresponsible,
because it suggests that what you need is some kind of weird compiler hack to make your
compilation work (detecting if the entire body is under an #ifndef) in a compiler of
marginal interest to a Windows programmer (gcc). Why would expect gcc documentation has
relevance to Microsoft compilers?
****
In the Objective C language, there is a variant of `#include' called****
`#import' which includes a file, but does so at most once. If you use
`#import' *instead of* `#include', then you don't need the conditionals
inside the header file to prevent multiple execution of the contents.
`#import' is obsolete because it is not a well designed feature. It
requires the users of a header file--the applications programmers--to
know that a certain header file should only be included once. It is
much better for the header file's implementor to write the file so that
users don't need to know this. Using `#ifndef' accomplishes this goal.
There is also a $include directive in Pascal, and an import statment in Java. A piece of
documentation about Objective C, which is a language which is NOT the C++ language, has
little relevance to the C++ language. Why should you care what some other language uses
for syntax for including header files in a language unrelated to the one you are using?
You might as well be concerned about FORTRAN commenting conventions.
The key to learning a language is to use the documentation for the language and compiler
you are using, not some randomly-selected language and compiler.
****
------------------------------*****
Scott also wrote-------------------------------
#pragma once is only designed to prevent including the same header file more
than once within the same cpp file. (NOT within multiple files in the same
project.) Including the same header file more than once within the same cpp
file will usually produce compile errors. That is why #pragma once was
added as a feature. It does the same thing as the #define header guard that
you show above. But it does it with less disk reading so it is faster.
Including a header file in more than one cpp file is normal - that is
really the purpose of include files. It makes sure that all of the cpp
files see the exact same declarations of whatever is in the header file.
Oh I see, I was getting a bit over confused on the logistics of the issue.
You have made it more clear to me. It is ok to include a header in more
than one cpp file but not to include it more than once in the same file or
even to have it included again in an included header file (if it's included
in the cpp already.
Thanks for an excellent reply
Consider the following situtation:
I have a header file a.h that relies on data types defined in x.h. I have a header file
b.h that relies on data types defined in x.h. Now I *could* tell the programmer, "Before
you include a.h or b.h, you must include x.h" but that imposes a burden on the programmer
to (a) know what files are required by other files and (b) be dependent on the fact that I
do not refactor x.h into two or more files, or make a change in a.h or b.h that ALSO
requires including y.h as well.
The correct approach is this:
file a.h:
#include "x.h"
...definitions for module a.cpp
file b.h
#include "x.h"
...definitions for module b.cpp
Note that the programmer who uses a.h or b.h does not have to care what header files these
require, and in fact I am free to change those dependencies in a.h or b.h without
bothering the programmer who is using them. BUT, because of the way this works, if my
..cpp file requires both a.h and b.h, then it appears to the compiler as if the file x.h is
included twice. If x.h does not have include-guards or #pragma once, then you can get
error messages when the second instance of x.h attempts to again define symbols which
already have definitions. So the correct creation of x.h is to provide either the clumsy
include-guards, or use the much better #pragma once solution.
If you want your code to compile in compilers other that Microsoft C/C++, such as might
happen if you were supporting multiple platforms, then you would write something like
#ifndef _NAME_HERE
#define _NAME_HERE
#if _MSC_VER > 1000
#pragma once
#endif
....contents of header file
#endif
Now this file will work in any C compiler. If the compiler does not implement the bizarre
gcc hack, it still works. If you are compiling with gcc, it works, and is more efficient
than in other compilers because gcc has a metalinguistic kludge that makes it simulate
#pragma once. And if you are using the version of VC that first implemented #pragam once,
or a newer VC compiler, it uses #pragma once, so the Microsoft compilers are efficient (in
any other compiler, the symbol _MSC_VER will be 0 and the #pragma once will not be seen by
the compiler).
But don't rely on the documentation of randomly-selected compilers and languages to tell
you what does and does not work in Microsoft's compiler. I wouldn't use the Microsoft
documentation if I were using gcc. I also wouldn't use FORTRAN documentation if I were
programming in Pascal, and so there is little meaning in using (or quoting) Objective C
documentation when you are programming in C++.
joe
*****
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- References:
- include file question
- From: RB
- Re: include file question
- From: Scott McPhillips [MVP]
- Re: include file question
- From: RB
- include file question
- Prev by Date: Re: CList problems
- Next by Date: Re: include file question
- Previous by thread: Re: include file question
- Next by thread: Re: include file question
- Index(es):
Relevant Pages
|