Shriramana, Please see inline. Thanks. On 6/15/07, Shriramana Sharma <samjnaa@xxxxxxxxx> wrote:
Hello. To prevent header files from being included more than once in the same translation unit, we use include guards like # ifndef FOO_H # define FOO_H ... # endif Recently I came to know that I can use simply: # pragma once instead of the above group of sentences and the desired effect is still accomplished. This leads me to think of two things: 1. why use the ifndef-define-endif method when the pragma once method is simpler and cleaner?
pragma(s) are, as most language extensions, not portable.
2. why should we need to use either method at all? If it is a universally undesirable behaviour that the same header file is included in a translation unit more than once, then an intelligent compiler (or preprocessor) itself can by default take of this, right?
Yes, if a header file is contained entirely in a `#ifndef' conditional, then the preprocessor records that fact. But if a subsequent `#include' specifies the same file, and the macro in the #ifndef is already defined, then the file is entirely skipped, without even reading it. How else should a preprossessor deal with this in a portable manner? Keep in mind that preprocessing is a distinct step in the compilation process.
I understand that to write portable code that compiles on not-so-intelligent compilers, we may need to do something manually, so question 2 is answered, but question 1 still stands...
Does it? Correct, pragmas are not standard, and probably never will be, due to the difficulty of specifying exactly what it is that '#pragma once' is supposed to do. (Think of two identical copies of a header file in different source directories, and a translation unit that #includes both of them. What is the effect of '#pragma once' here?) Inclusion safe guards work perfectly well, are standard-compliant and portable. \Steve -- Steve Grägert <steve@xxxxxxxxxxxx> - To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
