Re: C++ standard header inclusion artifact?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux