C++ standard header inclusion artifact?

John (Eljay) Love-Jensen eljay@adobe.com
Wed Jan 21 17:36:00 GMT 2009


Hi Rodolfo,

You've run into the problem that I call "You didn't ask for it, but you got it" problem.  Unfortunately, it is not easily fixed, because trying to fix it leads to the "Pull the thread of the sweater and the whole thing comes unraveled" problem.

ISO 148882 specifies what identifiers must be declared in a header, and what macros must be #define'd in a header.

But it does not preclude other identifiers from being declared, and other macros from being #define'd.

So often a #include of a standard C++ header will, in turn, #include other files.  Some of those files may be system header files, which are usually (except for perhaps BeOS) C based.  Those C-centric system header files may, in turn, #include some C99 headers, such as <stdint.h>.

As an exercise, I once created faux C++ headers that *ONLY* declared identifiers that they were required to declare, and #define'd macros that they were required to declare.  And each header never #include'd anything else, nor #define'd anything else (other than allowable header guards like __IOSTREAM_HEADER_GUARD__, using the double-underscore reserved identifier).

What did I find?  I found that a lot of my C++ code assumes, say, ::printf exists when doing a #include <cstdio>, rather than std::printf.  And all the other Standard C-isms that one would surmise.  Prevalent.  Everywhere.

My take-away items from the exercise was:
+ preprocessor macros are evil
+ the global namespace is heavily polluted
+ deal with it... it's not going away

Sincerely,
-Eljay



More information about the Gcc-help mailing list