size_t vs plain int

This is a discussion on size_t vs plain int within the C++ Programming forums, part of the General Programming Boards category; Just to clarify:
we use size_t when we deal w/ size and we want to be able to express largest ...

size_t vs plain int

Just to clarify:

we use size_t when we deal w/ size and we want to be able to express largest size for a variable like in a calculation or data structure so the size is ALWAYS guaranteed to be able to represent 2^32 distinct positive integers (since int is typically 4B and size_t is typedef for unsigned int so no neg representations.) We should stick to size_t for portability (b/c of size issues across different machines where size is too little or something) and naturally like in loops to access indices so

Code:

for ( size_t i = 0; i < size; ++i )
cout << list[i] << " , ";

VS

we use int when we want to have negatives so the 2^32 distinct values is halved, so half of the values are neg, the other pos.

Also to clarify, the largest base-2 representation of a 32-bit size_t would be: 11111111111111111111111111111111 so whatever that is in base-10. But w/ the case of int (b/c it is signed), we largest base-10 value is half what that binary is (32 1's).

we use size_t when we deal w/ size and we want to be able to express largest size for a variable like in a calculation or data structure so the size is ALWAYS guaranteed to be able to represent 2^32 distinct positive integers

No, size_t is not necessarily an unsigned int. It is an implementation defined unsigned type, which means it could be an unsigned char or maybe unsigned long or maybe even an unsigned int. Never assume a size_t is a particular size.

From final draft C++11 standard: section 18.2 Types [support.types]

6
The type size_t is an implementation-deﬁned unsigned integer type that is large enough to contain the size
in bytes of any object.

Many of the standard functions use size_t. For example the std::vector.size() function returns a size_t. You should always use size_t when dealing with functions that use or return this type.

We should stick to size_t for portability (b/c of size issues across different machines where size is too little or something

But remember that size_t is not a fixed size. Today most systems may typedef this to unsigned int but tomorrow these same systems may redefine size_t to a different sized type.

size_t is usually a typedef alias for unsigned long. int and long are not defined by the standard to be any specific size, although most platforms have a 32-bit int these days. long is also usually the same size as a pointer. the range for an unsigned 32-bit integer is 0 to 4294967295, and the range for a signed 32-bit integer is -2147483648 to 2147483647 on most common systems. some systems use a different style of twos-complement for negative numbers, so their range differs slightly, but that's a bit outside the scope of your question.

This might sound weird, but when the range for an unsigned 32-bit integer is 0 to 4294967295, does that mean: in binary: 0 is 32 0's and the base-2 representation of 4294967295 is 32 1's, which implies the largest base-2 that a 32-bit int can represent.

Please ignore comment, I wasn't thinking, I 'forgot' that let's say: 2^16 is 65563 permutations, but it could be represented from offset of anything, but in programming it starts @ 0 to 65535 which is 65536 different items.

I'm still a little confused w/ size_t, this I found online:By definition, size_t is the result of the sizeof operator. size_t was created to refer to sizes.

The number of times you do something (10, in your example) is not about sizes, so why use size_t? int, or unsigned int, should be ok.

So size_t is 4B, plain int is 4B, but size_t is UNSIGNED, so when it talks about size, I'm guessing it means b/c of the fact that size_t is unsigned, it can represent double the number of 'real' objects in a data structure like an array (b/c no bits reserved for negative values). Is this right?

So size_t is 4B, plain int is 4B, but size_t is UNSIGNED, so when it talks about size, I'm guessing it means b/c of the fact that size_t is unsigned, it can represent double the number of 'real' objects in a data structure like an array (b/c no bits reserved for negative values). Is this right?

Yes, though there is also the issue that unless your items are made out of anti-matter or something like that, having a negative number of items usually does not make sense.

EDIT:
You should only assert "size_t is 4B, plain int is 4B" conditionally, e.g., "so assuming sizeof(size_t) == 4 and sizeof(int) == 4, we know that size_t is unsigned, so when we talk about size, ..."

std::vector<T>::size() returns a value of type std::vector<T>::size_type. In practice, std::vector's size_type is usually an alias for size_t, but is not strictly required to be (i.e. the standard does not mandate that it will be).

If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

in the code that I write, I basically only use size_t to avoid compiler warnings about comparisons between signed and unsigned when dealing with the size of stl containers. in nearly every other case, I use int.

std::vector<T>::size() returns a value of type std::vector<T>::size_type. In practice, std::vector's size_type is usually an alias for size_t, but is not strictly required to be (i.e. the standard does not mandate that it will be).

True size() returns a size_type but a size_type can not be larger than size_t because of the following clause in the standard.

The type size_t is an implementation-deﬁned unsigned integer type that is large enough to contain the size in bytes of any object.

Also since vector has this line in it's definition:

typedef size_t size_type;

I would say in the case of a std::vector the use of size_t or std::vector::size_type is appropriate.