Is size_t implementation defined ?
jerome
I looked up in the standard but section 18.1 only mentions that it is
defined in <cstddef>.
Thanks.
Sent via Deja.com http://www.deja.com/
Before you buy.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Gabriel Dos_Reis
| ... or is it always defined as unsigned int (as my compiler does) ?
An implementation defined typedef to a standard unsigned integral
type.
--
Gabriel Dos Reis, dos...@cmla.ens-cachan.fr
James Dennett
>
> ... or is it always defined as unsigned int (as my compiler does) ?
It's implementation defined, so that it can be really big even if
unsigned int or unsigned long aren't.
For example, on an odd 64-bit machine with 32 bit ints and longs,
size_t might be a 64-bit type '__ulonglong'.
-- James Dennett <jden...@acm.org>
Peter Roozemaal
>
> I looked up in the standard but section 18.1 only mentions that it is
> defined in <cstddef>.
>
usually is a typedef for unsigned long or unsigned int, but it could be
implemented as a type of its own. (In this case the C knowledge carries
over to C++ without change.)
Peter.
Francis Glassborow
deja.com> writes
>... or is it always defined as unsigned int (as my compiler does) ?
If it were always unsigned int there would be no point to calling
it size_t :) The answer is that it is implementation defined and
required to be some unsigned integer type.
>
>I looked up in the standard but section 18.1 only mentions that it is
>defined in <cstddef>.
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
James Kanze
> jerome wrote:
> > I looked up in the standard but section 18.1 only mentions that it is
> > defined in <cstddef>.
> In C size_t is an implementation defined unsigned integral type. It
> usually is a typedef for unsigned long or unsigned int, but it could
> be implemented as a type of its own. (In this case the C knowledge
> carries over to C++ without change.)
If it's a typedef, it can't be a type of its own. If it's an integral
type, in the sense of the standard, it must be one of: char, short,
int or long, or the unsigned equivalent, at least in C90.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
James Kanze
> jerome wrote:
> >
> > ... or is it always defined as unsigned int (as my compiler does) ?
> It's implementation defined, so that it can be really big even if
> unsigned int or unsigned long aren't.
> For example, on an odd 64-bit machine with 32 bit ints and longs,
> size_t might be a 64-bit type '__ulonglong'.
Not in C90 or C++ (which includes C90 by reference). It must be an
unsigned integral type, and the standard enumerates all possible
integral types.
In C99, it can certainly be long long. C90 introduces a number of
additional integral types as well, but I'm not sure whether size_t can
be one of these or not.
James Kanze
> ... or is it always defined as unsigned int (as my compiler does) ?
> I looked up in the standard but section 18.1 only mentions that it
> is defined in <cstddef>.
It is always defined as an unsigned integral type. In practice, it
can be unsigned int or unsigned long. I can't imagine an
implementation with unsigned short or unsigned char, but the standard
allows it.
Michael H. Cox
"James Kanze" <James...@dresdner-bank.com> wrote in message
news:3A2F652F...@dresdner-bank.com...
> jerome wrote:
>
> > ... or is it always defined as unsigned int (as my compiler does) ?
>
> > I looked up in the standard but section 18.1 only mentions that it
> > is defined in <cstddef>.
18.1.3 The contents are the same as the Standard C library header
<stddef.h>...
An additional constraint would be that size_t would have to be an unsigned
integral type that can hold the largest number returned by the sizeof
operator, i.e. the number of bytes of the largest object that can be
defined in the given language implementation's data space.
Luis Pedro Coelho
>
> An additional constraint would be that size_t would have to be an unsigned
> integral type that can hold the largest number returned by the sizeof
> operator, i.e. the number of bytes of the largest object that can be
> defined in the given language implementation's data space.
>
One can also view this as a restriction on the maximum size of an object.
--
Luis Coelho.
Check out my game of Hearts, a card game, for KDE at:
http://www.geocities.com/deepblack9/index.html
James Dennett
>
> James Dennett wrote:
>
> > jerome wrote:
> > >
> > > ... or is it always defined as unsigned int (as my compiler does) ?
>
> > unsigned int or unsigned long aren't.
>
> > For example, on an odd 64-bit machine with 32 bit ints and longs,
> > size_t might be a 64-bit type '__ulonglong'.
>
> Not in C90 or C++ (which includes C90 by reference). It must be an
> unsigned integral type, and the standard enumerates all possible
> integral types.
I recall some debate recently (probably on comp.std.c++) about whether
additional types were allowed. The C++ Standard mentions found signed
integer types (char, short, int, long) explicitly, and mentions that
each has an unsigned version. It does not state explicitly that these
are the only four integer types.
If the Standard intended to enumerate the integer types, it would
probably be clearer to say "The integer types are exactly: char,
short, int, long."
Checking my copy of the C++ Standard, it does indeed define size_t
only by reference to the C90 Standard, which I don't have to hand.
> In C99, it can certainly be long long. C90 introduces a number of
> additional integral types as well, but I'm not sure whether size_t can
> be one of these or not.
Would C99 then avoid a problem which C++ would have with a proposed
IA64 model which was going to use 32-bit longs?
-- James Dennett <jden...@acm.org>
Gabriel Dos_Reis
[...]
| If the Standard intended to enumerate the integer types, it would
| probably be clearer to say "The integer types are exactly: char,
| short, int, long."
The Standard hasn't have to go through such verbosity in order to
define what it means by integer types.
Firstly it states:
1.3/2
Terms that are used obly in a small portion of this International
Standard are defined where they are used and *italicized* where they
are defined.
(Emphasis is mine).
Now, the Standard goes on saying
3.9.1/2:
There are four /siigned integer types/: "signed char", "short int",
"int", "long int". [...]
3.9.1/3:
For each of the signed integer types, there exists a corresponding
(but different) /unsigned integer types/: [...]
3.9.1/7:
Types bool, char, wchar_t, and the signed and unsigned integer types
are collectively called /integral/ types. A synonym for integral
type is /integer type/. [...]
So the Standard is pretty much explicit about what it means by
integer type -- and actually, it enumerates them :-)
--
Gabriel Dos Reis, dos...@cmla.ens-cachan.fr
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James Dennett
>
> James Dennett <ja...@evtechnology.com> writes:
>
> [...]
>
> | If the Standard intended to enumerate the integer types, it would
> | probably be clearer to say "The integer types are exactly: char,
> | short, int, long."
>
> The Standard hasn't have to go through such verbosity in order to
> define what it means by integer types.
Or, rather, it already does, scattered across a number of paragraphs
:)
(thanks for the detailed explanation)
>
> Firstly it states:
>
> 1.3/2
> Terms that are used obly in a small portion of this International
> Standard are defined where they are used and *italicized* where they
> are defined.
Okay, that convinces me. The IS defines the term "unsigned integer
type" (even if it does so less clearly than it could) and requires that
size_t be one of the given types.
Implementations are thus free to make size_t be one of
unsigned char, unsigned short, unsigned [int], unsigned long
but no other types are allowed. This is one more reason for
a compiler on a platform with a large (>32 bit) address space
*not* to make unsigned long a 32-bit type.
-- James Dennett <jden...@acm.org>