Max_size() for std::vector<char>

Sam Varshavchik mrsam at courier-mta.com
Sat Feb 14 18:36:18 UTC 2015


Francois Fayard writes:

> Hi,
>
>
> I am puzzled by the result of std::vector<char>::max_size() on the n=32 and  
> n=64 bits system I have tested. The result is 2^n - 1. Let me explain why I  
> am puzzled.
>
> Libc++ implementation of std::vector<T> has three members of  
> type T*: begin_, end_, capacity_. 
>
> begin_ points to the first value of the vector and end_ points to the one  
> after the last. Therefore, the size of the vector is given by end_ - begin_.  
> But the result of this difference is of type std::ptrdiff_t which is a signed  
> integer of n bits on every implementation that I know of. 
>
> Therefore, this type can not store 2^n - 1, but only up to 2^(n-1) - 1. So,  
> how come they can max_size() pretend to store more than 2^(n - 1) elements  
> without breaking .size() ?

On x86_64, std::vector<char>::max_size() returns 0xffffffffffffffff, or  
2^64-1.

Presuming that it was actually possible to instantiate something like that,  
your begin() would return 0, your end() would be 2^64-1, and no rules appear  
to be broken. I have no idea what nullptr would evaluate in such a  
situation. Maybe nullptr would be 2^64-1, on such a platform.

P.S. – something like that wouldn't actually be the right topic for this  
list, but that's fine.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.fedorahosted.org/pipermail/libcxx-users/attachments/20150214/a2a20c6a/attachment.sig>


More information about the libcxx-users mailing list