Re: C++ standard header inclusion artifact?

[Rodolfo Federico Gamarra <rgamarra at gmail dot com>]

Thanks John and everyone else for the clarification of this topic.

I wrongly supposed that including a standard header will only define
things in the realm of the standard.

Cheers,

--
Rodolfo Federico Gamarra



On Wed, Jan 21, 2009 at 15:36, John (Eljay) Love-Jensen <eljay@adobe.com> wrote:
> 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
>