C++ vector of pointer to object - max_size()

Question

I have a class apples

class apples
{
  private:
      double x;
      double y;
      double z;
  public:
      //some methods
};

I want to store the pointer to apples objects in a vector. I am doing this so that i create any object in any file & use any object in any file. I used the following code to determine the max no of pointers i can store in that vector

int _tmain(int argc, _TCHAR* argv[])
{
vector<apples *> myvector;
cout<<"max :"<<myvector.max_size();
return 0;
}

it gave me:

1073741823

now, my question is that can i really store 1073741823 no of pointers in that vector or is this the memory limitation (i.e. 1073741823 bytes) of the vector?

so if there are 2 vectors

vector<int> A
& 
vector<double> B

can A have 1073741823 elements & B also have 1073741823 elements? i am asking this to clarify that, the max no of elements that a vector can store does not depend on the the type of entity (int or double) being stored? (this has nothing to do with the current capacity of the vector!) Also, what would be the size of a pointer to apples object (not asking the size of apples object!)? Thank You.

Answer 1

This is library limitation for storing elements in a vector.

vector::max_size() :

Returns the maximum number of elements that the vector container can hold.

This is not the amount of storage space currently allocated to the vector (this can be obtained with member vector::capacity), but the maximum potential size the vector could reach due to system or library implementation limitations.

So, you can not store more than it (and in practice maybe less than it due to system limitations)

In other words even if you have best resource (memory, CPU, ...) abilities and your elements have minimum size, you can not store more than max_size()

And according to the comment on max_size() in the header file: Returns the size of the largest possible %vector.

Answer 2

hex(1073741823) = '0x3fffffff'

So that looks like some pre-defined limit.

Answer 3

max_size returns an upper bound on the number of elements the vector can hold. This doesn't mean that v.resize(v.max_size()) will succeeds. It merely means that v.resize(v.max_size() + 1) will fail.

Answer 4

Also, what would be the size of a pointer to apples object (not asking the size of apples object!)?

I'm sure some language lawyer will come around and point out that this is not correct, but in practice: 32bit builds will use 32 bit pointers, so a pointer to an object is four bytes. In 64bit builds, you get eight bytes per pointer.

Answer 5

It is the size at which, if not bound by any resource limits (CPU, memory, time), the vector will no longer be able to add any more items to itself.

The amount you can actually store is generally substantially lower due to mainly memory constraints.

The current capacity can be found by calling vector::capacity(), and if you'd like to find out how far you can stretch the vector on your current setup, then keep resizing the vector until a bad_alloc exception is thrown)

Answer 6

can i really store 1073741823 pointers in that vector or is this the memory capacity of the vector?

max_size() tells you that this implementation of vector can't handle a size larger than that; vectors up to that size are possible, if there is enough memory available to contain them.

does the max no of entities store able in a vector depend on the type of entity? if yes, how to calculate that?

That depends on the implementation of both vector, and the allocator it uses. In practice it usually will; you'll probably find that it's equal to something like numeric_limits<size_t>::max() / sizeof (value_type); the maximum number of bytes that can be allocated in an array, divided by the object size.

Also, what would be the size of a pointer to apples object (not asking the size of apples object!)?

That depends on your platform. Since max_size() is so small, I'm guessing you're using a 32-bit platform, in which case a pointer will be 32 bits (4 bytes). Other platforms will have different pointer sizes.