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