size_t vs int in C++ and/or C

Question

Why is it that in C++ containers, it returns a size_type rather than an int? If we\'re creating our own structures, should we also be encouraged to

Answer 1

I assume you mean "size_t" -- this is a way of indicating an unsigned integer (an integer that can only be positive, never negative) -- it makes sense for containers' sizes since you can't have an array with a size of -7. I wouldn't say that you have to use size_t but it does indicate to others using your code "This number here is always positive." It also gives you a greater range of positive numbers, but that is likely to be unimportant unless you have some very big containers.

Answer 2

ints are not guaranteed to be 4 bytes in the specification, so they are not reliable. Yes, size_type would be preferred over ints

Answer 3

void f1(size_t n) {
    if (n <= myVector.size()) { assert(false); }
    size_t n1 = n - myVector.size(); // bug! myVector.size() can be > n       
    do_stuff_n_times(n1);
}

void f2(int n) {
    int n1 = n - static_cast<int>(myVector.size());
    assert(n1 >= 0);
    do_stuff_n_times(n1);
}

f1() and f2() both have the same bug, but detecting the problem in f2() is easier. For more complex code, unsigned integer arithmetic bugs are not as easy to identify.

Personally I use signed int for all my sizes unless unsigned int should be used. I have never run into situation where my size won't fit into a 32 bit signed integer. I will probably use 64 bit signed integers before I use unsigned 32 bit integers.

The problem with using signed integers for size is a lot of static_cast from size_t to int in your code.

Answer 4

C++ is a language that could be implemented on different hardware architectures and platforms. As time has gone by it has supported 16-, 32-, and 64-bit architecture, and likely others in the future. size_type and other type aliases are ways for libraries to insulate the programmers/code from implementation details.

Assuming the size_type uses 32 bits on 32-bit machines and 64 bits on 64-bit machines, the same source code likely would work better if you've used size_type where needed. In most cases you could assume it would be the same as unsigned int, but it's not guaranteed.

size_type is used to express capacities of STL containers like std::vector whereas size_t is used to express byte size of an object in C/C++.

Answer 5

size_t is unsigned, so even if they're both 32 bits it doesn't mean quite the same thing as an unqualified int. I'm not sure why they added the type, but on many platforms today sizeof (size_t) == sizeof (int) == sizeof (long), so which type you choose is up to you. Note that those relations aren't guaranteed by the standard and are rapidly becoming out of date as 64 bit platforms move in.

For your own code, if you need to represent something that is a "size" conceptually and can never be negative, size_t would be a fine choice.

Answer 6

All containers in the stl have various typedefs. For example, value_type is the element type, and size_type is the number stored type. In this way the containers are completely generic based on platform and implementation.

If you are creating your own containers, you should use size_type too. Typically this is done

typedef std::size_t size_type;

If you want a container's size, you should write

typedef vector<int> ints;
ints v;
v.push_back(4);
ints::size_type s = v.size();

What's nice is that if later you want to use a list, just change the typedef to

typedef list<int> ints;

And it will still work!