Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

size_t Question

2 views
Skip to first unread message

Immortal Nephi

unread,
Jan 22, 2010, 9:50:17 PM1/22/10
to
Is size_t keyword always unsigned integer ( all positive integers and
no negative integer)? It is to be 32 bit size if it is on 32 bit
machine otherwise it is to be 64 bit size on 64 bit machine.
Do I always use size_t for while loop and for loop? You cannot use
size_t if you want to store it into array, but you use char, int, or
long instead.

**Group User**

unread,
Jan 22, 2010, 11:40:39 PM1/22/10
to

Dear Sir, I have just replied to a thread of mine in
microsoft.public.ssssss
please read and offer your views as soon as you wish
, i am grateful

Whenever the lib asks you to do so. methinks its at the compiling
level
tthins are cot by compilers like that
if you think size_t is shorter then wite it. dont write too long as it
strains your muscles and sometimes your fngers get numb


--Silly ideas works as always

io_x

unread,
Jan 23, 2010, 2:10:37 AM1/23/10
to

"Immortal Nephi" <Immorta...@hotmail.com> ha scritto nel messaggio
news:8d88539d-ac35-45a4...@p24g2000yqm.googlegroups.com...

> Is size_t keyword always unsigned integer ( all positive integers and
> no negative integer)?

it is one unsigne integer,
could "unsigned int" ["short int"??] "long unsigned int"
and "long long unsigned int"
all not negative

> It is to be 32 bit size if it is on 32 bit
> machine otherwise it is to be 64 bit size on 64 bit machine.

size_t has one range that allow all possible address
if for example the cpu can read memory using max one 64 bit number
eg. in "mov rax, [rax]"
than size_t has to be 64 bit
because has to deal with the 64 bits register rax that read the memory

> Do I always use size_t for while loop and for loop?

don't know; for me could be useful to use int or unsigned,
or something you know the size example something like "uint32_t"

Immortal Nephi

unread,
Jan 23, 2010, 10:18:26 AM1/23/10
to
On Jan 23, 1:10 am, "io_x" <a...@b.c.invalid> wrote:
> "Immortal Nephi" <Immortal_Ne...@hotmail.com> ha scritto nel messaggionews:8d88539d-ac35-45a4...@p24g2000yqm.googlegroups.com...
> > long instead.- Hide quoted text -

You can take a look at vector template. You will see some member
functions with return type of size_t. I think it uses iterator for
loop such as size(), begin(), end(), etc.

Maxim Yegorushkin

unread,
Jan 23, 2010, 12:35:28 PM1/23/10
to
On 23/01/10 02:50, Immortal Nephi wrote:
> Is size_t keyword always unsigned integer ( all positive integers and
> no negative integer)?

It is a typedef defined in stddef.h standard header.

> It is to be 32 bit size if it is on 32 bit
> machine otherwise it is to be 64 bit size on 64 bit machine.

It is a type returned by sizeof operator and it is required to be a able
to represent the size of any object in C++. It is unsigned. Normally, it
is a 32-bit integer on a 32-bit platform and a 64-bit integer on a
64-bit platform.

> Do I always use size_t for while loop and for loop?

Only if you'd like to.

> You cannot use
> size_t if you want to store it into array, but you use char, int, or
> long instead.

Not sure what you meant. You can have an array of size_t elements.

--
Max

James Kanze

unread,
Jan 23, 2010, 6:46:46 PM1/23/10
to
On Jan 23, 2:50 am, Immortal Nephi <Immortal_Ne...@hotmail.com> wrote:

> Is size_t keyword always unsigned integer ( all positive integers and
> no negative integer)? It is to be 32 bit size if it is on 32 bit
> machine otherwise it is to be 64 bit size on 64 bit machine.

A little more than a nit: size_t is NOT a keyword. It's defined
in the library, and you can't use it (officially) unless you
actually include <stddef.h> (or maybe one of two or three other
C headers).

> Do I always use size_t for while loop and for loop?

No. In fact, it's fairly rare to use size_t in a while loop or
a for loop. The standard requires it to be an unsigned type, so
you tend to avoid using it in such cases, unless some external
constraint requires it.

> You cannot use size_t if you want to store it into array, but
> you use char, int, or long instead.

Where did you get that from? std::vector<size_t> is perfectly
legal; so is size_t [], for that matter

--
James Kanze

James Kanze

unread,
Jan 23, 2010, 6:50:31 PM1/23/10
to
On Jan 23, 7:10 am, "io_x" <a...@b.c.invalid> wrote:
> "Immortal Nephi" <Immortal_Ne...@hotmail.com> ha scritto nel
> messaggionews:8d88539d-ac35-45a4...@p24g2000yqm.googlegroups.com...

[...]


> size_t has one range that allow all possible address

No. All that is required is that it can hold the size of the
largest possible object. I've used systems with 32 bit
addresses but 16 bit size_t. (I suspect that most people my age
has, since this was the case on the most widespread machines
twenty-five or thirty years ago.)

> if for example the cpu can read memory using max one 64 bit
> number
> eg. in "mov rax, [rax]"
> than size_t has to be 64 bit because has to deal with the 64

> bits register rax that read the memory.

Size_t has nothing to do with the size of a register, nor the
size of a pointer.

--
James Kanze

Leigh Johnston

unread,
Jan 24, 2010, 9:49:38 AM1/24/10
to

"James Kanze" <james...@gmail.com> wrote in message
news:7dee3511-bace-4973...@a22g2000yqc.googlegroups.com...


> On Jan 23, 7:10 am, "io_x" <a...@b.c.invalid> wrote:
>> "Immortal Nephi" <Immortal_Ne...@hotmail.com> ha scritto nel
>> messaggionews:8d88539d-ac35-45a4...@p24g2000yqm.googlegroups.com...
>
> [...]
>> size_t has one range that allow all possible address
>
> No. All that is required is that it can hold the size of the
> largest possible object. I've used systems with 32 bit
> addresses but 16 bit size_t. (I suspect that most people my age
> has, since this was the case on the most widespread machines
> twenty-five or thirty years ago.)
>

size_t is also used for array indexing so on a 64bit system for example it
should be the same size as ptrdiff_t. consider
std::vector::operator[](size_type), size_type is std::size_t for default
std::allocator. If you can allocate >2^32 chars then you need to be able to
access them via [] also.

/Leigh

Leigh Johnston

unread,
Jan 24, 2010, 9:54:29 AM1/24/10
to
From C ISO standard rationale:

"Thus size_t is also a convenient type for array sizes, and is so used in
several library
30 functions."

For array of char size_t must therefore be same size as ptrdiff_t.

/Leigh

Leigh Johnston

unread,
Jan 24, 2010, 10:05:26 AM1/24/10
to
>
> For array of char size_t must therefore be same size as ptrdiff_t.
>

Unless we are talking about crappy corner case implementations that Mr Kanze
likes so much. What is the point of having a 64bit address space if you can
only allocate 32bits worth of objects/arrays?

/Leigh

Öö Tiib

unread,
Jan 24, 2010, 1:34:26 PM1/24/10
to

Because it may be is optimal/required by platform architecture that
does not let one to have continuous memory block over 4 Gigabytes. C
is meant to be as close to assembler as any platform independent
language can get and size_t is C not C++ typedef. You may think it
makes it difficult to program, but it may prove to be best and
quickest and so users will buy it. At second thought it may even sound
reasonable. How often you deal with single object that does not fit
into 4 gigabytes?

Leigh Johnston

unread,
Jan 24, 2010, 1:45:25 PM1/24/10
to

"�� Tiib" <oot...@hot.ee> wrote in message
news:d20fadd7-fdd9-48bd...@b10g2000yqa.googlegroups.com...

A single object might need to fit into 4 gigabytes however an array of such
objects might not. The difference between a single object or an array of
objects should not important as far as pointer arithmetic is concerned.

/Leigh

Öö Tiib

unread,
Jan 24, 2010, 4:14:36 PM1/24/10
to

Yes that was what i was asking. Array is single object like any other.
How often you needed 4GB array? With array it is simpler matter to
solve on such platform since you can have array of pointers to its
elements.

James Kanze

unread,
Jan 24, 2010, 8:25:08 PM1/24/10
to
On Jan 24, 2:49 pm, "Leigh Johnston" <le...@i42.co.uk> wrote:
> "James Kanze" <james.ka...@gmail.com> wrote in message

> news:7dee3511-bace-4973...@a22g2000yqc.googlegroups.com...

> > On Jan 23, 7:10 am, "io_x" <a...@b.c.invalid> wrote:
> >> "Immortal Nephi" <Immortal_Ne...@hotmail.com> ha scritto nel
> >> messaggionews:8d88539d-ac35-45a4...@p24g2000yqm.googlegroups.com...

> > [...]
> >> size_t has one range that allow all possible address

> > No. All that is required is that it can hold the size of
> > the largest possible object. I've used systems with 32 bit
> > addresses but 16 bit size_t. (I suspect that most people my
> > age has, since this was the case on the most widespread
> > machines twenty-five or thirty years ago.)

> size_t is also used for array indexing so on a 64bit system
> for example it should be the same size as ptrdiff_t.

The standard requires ptrdiff_t and size_t to have the same
size. (Logically, one would expect size_t to be smaller, since
it doesn't need the sign bit.) But that doesn't change
anything: all that is required is that size_t be large enough to
contain the size of the largest possible object. Since arrays
are objects, that means that it can index into any possible
array.

The larger the word size of the machine, the less likely that it
will be smaller than a pointer. But a lot of 16 bit
architectures, and at least one 32 bit architecture (Intel)
support pointers larger than the word size: I've worked on
systems where the largest possible single object was 2^16 bytes,
but that could address 1 MB, and on machines where the largest
possible single object was 2^32, but pointers are 48 bits.

--
James Kanze

Richard Herring

unread,
Jan 25, 2010, 5:37:54 AM1/25/10
to
In message
<8d88539d-ac35-45a4...@p24g2000yqm.googlegroups.com>,
Immortal Nephi <Immorta...@hotmail.com> writes

> You cannot use
>size_t if you want to store it into array, but you use char, int, or
>long instead.

What?

You can have arrays (and indeed vectors and lists and dequeues and sets
and ...) of size_t just as you can of any other integral type.

--
Richard Herring

0 new messages