Help! Where is size_t ???

[Steve]

Hi,

I have some code which compiles with Metrowerks CodeWarrior 9.6, Visual
Studio 2005 (both targeted to Windows).

Or, at least, it did until I started using size_t.

CodeWarrior has size_t declared in the std namespace (and complains
otherwise).

Visual Studio expects size_t global, and complains about std::size_t

??? Who is right? (And does the standard say anything?)

Thanks for any help.

--
Regards,
Steve

"...which means he created the heaven and the earth... in the DARK! How good
is that?"

 

[int2str]

CodeWarrior has size_t declared in the std namespace (and complains
otherwise).

Visual Studio expects size_t global, and complains about std::size_t

??? Who is right? (And does the standard say anything?)

std::string::size_t

 

[Victor Bazarov]

I have some code which compiles with Metrowerks CodeWarrior 9.6, Visual
Studio 2005 (both targeted to Windows).

Or, at least, it did until I started using size_t.

CodeWarrior has size_t declared in the std namespace (and complains
otherwise).

Visual Studio expects size_t global, and complains about std::size_t

??? Who is right? (And does the standard say anything?)

Thanks for any help.

'size_t' is defined (typedef'ed, most likely) in <cstddef> (then it's in
the 'std' namespace) and in <stddef.h> (then it's in global namespace as
well). Standard defines that in 18.1.

V

 

[int2str]

std::string::size_t

Opps, I meant:
std::string::size_type

Probably not what you were looking for...

 

[Steve]

'size_t' is defined (typedef'ed, most likely) in <cstddef> (then it's in
the 'std' namespace) and in <stddef.h> (then it's in global namespace as
well). Standard defines that in 18.1.

V

Thanks Victor. That makes sense (I think!

So I guess CodeWarrior's #include tree doesn't include stddef.h, but does
have cstddef. Whereas VS includes stddef.h, but not cstddef. (And all
implementation defined as to which one they should include...?)

If I'm sure to include stddef.h in my CodeWarrior target, then both will
accept size_t.

Hmmm... it probably doesn't matter which one I use, but is any one more
'correct' than the other?


--
Regards,
Steve

"...which means he created the heaven and the earth... in the DARK! How good
is that?"

 

[Victor Bazarov]

[..]
So I guess CodeWarrior's #include tree doesn't include stddef.h, but does
have cstddef. Whereas VS includes stddef.h, but not cstddef. (And all
implementation defined as to which one they should include...?)

If I'm sure to include stddef.h in my CodeWarrior target, then both will
accept size_t.

Hmmm... it probably doesn't matter which one I use, but is any one more
'correct' than the other?

First of all, yes, you shouldn't rely on compiler including headers you
need from other headers, and instead should include them explicitly. You
got that absolutely correctly.

Now, there can be side effects of including one or the other, so you need
to see every time. However, if you do need 'size_t', include <stddef.h>.
As to the "correctness", I prefer the "h-less" headers, but as it has been
shown, the namespace requirements are not always followed, so you can get,
for example, both 'size_t' and 'std::size_t' if you include <cstddef> in
some implementations.

V

 

[Dietmar Kuehl]

'size_t' is defined (typedef'ed, most likely) in <cstddef> (then it's in
the 'std' namespace) and in <stddef.h> (then it's in global namespace as
well). Standard defines that in 18.1.

Well, the standard definition is impractical if not impossible to
achieve because the C library is generally not under the control
of the person implementing the standard C++ library. As a consequence,
the C++ versions of the C headers (i.e. <c...>) typically look like
this:

#if !defined _CSTDDEF
#define _CSTDDEF
#include <stddef.h>

namespace std {
using ::size_t;
// ...
}

#endif

The C versions of the headers are typically left untouched. Thus,
include <stddef.h> will not declare 'std::size_t' although the
current standard actually mandates that it does (this requirement
was lifted for the TC if I remember correctly). In practice this
means that you are best off including the [in C++ deprecated]
C versions of the headers and refer to the names therein unqualified
because this is the only approach which works on all platforms.