# of elements in vector

[Ralf Goertz]

Hi,

is there a general limit for the number of elements that can be stored
in a vector or is it implementation specific?

Thanks,

Ralf

 

[Daniel T.]

is there a general limit for the number of elements that can be stored
in a vector or is it implementation specific?

Yes and yes. The limit is defined by vector::max_size().

 

[Pete Becker]

Yes and yes. The limit is defined by vector::max_size().

Well, sort of. max_size gives you a value that might succeed, but there
are many other things that affect the actual number of elements that you
can store, the most important being available memory. In fact, max_size
is basically useless.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

 

[Daniel T.]

Well, sort of. max_size gives you a value that might succeed, but there
are many other things that affect the actual number of elements that you
can store, the most important being available memory.

I was incomplete in my answer... max_size() defines the upper limit, the
actual limit, as you say, may be lower.

In fact, max_size is basically useless.

It's useless only in that it is usually so large that the likelihood of
trying to allocate memory larger than it is extremely rare. As I
understand it though, sending a value to resize() that is greater than
max_size() is undefined isn't it? If so, then it has some use.

 

[Pete Becker]

It's useless only in that it is usually so large that the likelihood of
trying to allocate memory larger than it is extremely rare. As I
understand it though, sending a value to resize() that is greater than
max_size() is undefined isn't it? If so, then it has some use.

I don't think so. vector::resize is defined as a call to insert, and
insert "causes reallocation if the new size is greater than the old
capacity." At that point, if memory isn't available for whatever reason,
you get bad_alloc. It's certainly possible to implement that
reallocation badly so that you get erroneous results when the new size
is larger than max_size, but I don't see that that's allowed.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

 

[Duane Hebert]

Well, sort of. max_size gives you a value that might succeed, but there
are many other things that affect the actual number of elements that you
can store, the most important being available memory. In fact, max_size is
basically useless.

Except that given unlimited memory, and an element of size 1, you
can't have more than the maximum value held in size_t.

 

[Daniel T.]

Except that given unlimited memory, and an element of size 1, you
can't have more than the maximum value held in size_t.

Which is what max_size would return.

 

[Pete Becker]

Except that given unlimited memory,

I've never had the opportunity to use a system with unlimited memory.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

 

[F.J.K.]

Well, sort of. max_size gives you a value that might succeed, but there
are many other things that affect the actual number of elements that you
can store, the most important being available memory. In fact, max_size
is basically useless.

Well, I "fondly" remember an implementation, that had a
list::max_size() of 32267. This really did pose serious practical
problems for large lists of triangles in isosurfaces for the programs I
worked with.

I don't remember any more if I could get away with switchching to
vector (which probably would have been the smarter approach from the
start) or if I had to go back to malloc and trusty old C. Ah, the fun
days of VC6 ;-)

 

[Duane Hebert]

I've never had the opportunity to use a system with unlimited memory.

No. My reply was mostly "tongue in cheek" but the
OP was asking about any restrictions of the max elements
by the standard. AFAIK, the only one would be size_t
(or as Daniel says max_size.)

In practice however...