C++ standard header inclusion artifact?

C++ standard header inclusion artifact?

[Rodolfo Federico Gamarra]

Hi!

I'm wishing to use some exact width integer types with

g++ (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)

I believe that uint32_t and stuff like that are not part of C++'s
14882 standard, they are part of C's C99 standard (and defined in
stdint.h)

This tiny program:
class A {
  public:
    static const uint32_t k = 256;
};
int main() { }

Doesn't compile:

uint$ g++ *.cc -o main -Wall -std=c++98
main.cc:3: error: 'uint32_t' does not name a type

This seems right; however the inclusion of this line (at the beginning)

#include <iostream>

is enough to have it compiling smoothly with the same former command
(no console output).

Is this right? I'd have say (guessed) that that shouldn't happen.

Or is this an implementation detail that shouldn't be relied on?

Thanks a lot in advance for your help.

--
Rodolfo Federico Gamarra

Re: C++ standard header inclusion artifact?

[Andrew Haley]

Rodolfo Federico Gamarra wrote:
> Hi!
> 
> I'm wishing to use some exact width integer types with
> 
> g++ (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
> 
> I believe that uint32_t and stuff like that are not part of C++'s
> 14882 standard, they are part of C's C99 standard (and defined in
> stdint.h)
> 
> This tiny program:
> class A {
>   public:
>     static const uint32_t k = 256;
> };
> int main() { }
> 
> Doesn't compile:
> 
> uint$ g++ *.cc -o main -Wall -std=c++98
> main.cc:3: error: 'uint32_t' does not name a type
> 
> This seems right; however the inclusion of this line (at the beginning)
> 
> #include <iostream>
> 
> is enough to have it compiling smoothly with the same former command
> (no console output).
> 
> Is this right?

No.

#include <stdint.h>

Andrew.










 I'd have say (guessed) that that shouldn't happen.
> 
> Or is this an implementation detail that shouldn't be relied on?
> 
> Thanks a lot in advance for your help.
> 
> --
> Rodolfo Federico Gamarra

Re: C++ standard header inclusion artifact?

[Rodolfo Federico Gamarra]

Thanks Andrew.

So I understand that the fact that

#include <stdint.h>

isn't actually needed when <iostream> is included is some kind of bug;
as you point that the smooth compilation isn't right.

It seems that I should report this in Bugzilla, shouldn't I?

Thanks a lot again.

--
Rodolfo Federico Gamarra



On Wed, Jan 21, 2009 at 15:17, Andrew Haley <aph@redhat.com> wrote:
> Rodolfo Federico Gamarra wrote:
>> Hi!
>>
>> I'm wishing to use some exact width integer types with
>>
>> g++ (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
>>
>> I believe that uint32_t and stuff like that are not part of C++'s
>> 14882 standard, they are part of C's C99 standard (and defined in
>> stdint.h)
>>
>> This tiny program:
>> class A {
>>   public:
>>     static const uint32_t k = 256;
>> };
>> int main() { }
>>
>> Doesn't compile:
>>
>> uint$ g++ *.cc -o main -Wall -std=c++98
>> main.cc:3: error: 'uint32_t' does not name a type
>>
>> This seems right; however the inclusion of this line (at the beginning)
>>
>> #include <iostream>
>>
>> is enough to have it compiling smoothly with the same former command
>> (no console output).
>>
>> Is this right?
>
> No.
>
> #include <stdint.h>
>
> Andrew.
>
>
>
>
>
>
>
>
>
>
>  I'd have say (guessed) that that shouldn't happen.
>>
>> Or is this an implementation detail that shouldn't be relied on?
>>
>> Thanks a lot in advance for your help.
>>
>> --
>> Rodolfo Federico Gamarra
>
>

Re: C++ standard header inclusion artifact?

[me22]

On Wed, Jan 21, 2009 at 12:29, Rodolfo Federico Gamarra
<rgamarra@gmail.com> wrote:
>
> So I understand that the fact that
>
> #include <stdint.h>
>
> isn't actually needed when <iostream> is included is some kind of bug;
> as you point that the smooth compilation isn't right.
>
> It seems that I should report this in Bugzilla, shouldn't I?
>

ISO 14882:2003 17.4.4.1.1 `A C++ header may include other C++ headers.'

Including a standard header may include all kinds of things, so I
don't think this is something that belongs in BugZilla.

That said, there was a big header cleanup a bit ago, so try 4.3 or
newer.  I doubt it will have "fixed" this, but you could try.

Re: C++ standard header inclusion artifact?

[John (Eljay) Love-Jensen]

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

Re: C++ standard header inclusion artifact?

[Rodolfo Federico Gamarra]

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
>