vector<> can probably never grow to it's maximum size!

[Paolo Carlini]

Dhruv Matani wrote:

>As I have explained earlier, but forgot to mention this:
>
>We may force the user to pass a non-const memory region's address to
>allocate(n, hint) if hint is non-zero. This is possible because the
>__mt_alloc<> is after all an extension, and we can demand such things.
>  
>
You can't in the current framework, since __mt_alloc is used as-is to 
implement
std::allocator, in particular std::allocator::allocate (with the correct 
const void*
type). You would need an additional wrapper around __mt_alloc.

>Issue1: About operator new failing with a large request.
>  
>
This one (the only one that you mentioned at the beginning of this thread,
by the way ;) you can't really fix by catching the exceptions thrown by
::operator new, I think. Here we are considering any possible size, and
my previous comment about vector grow unduly limited stand.

>Issue2: Allocators such as mt_alloc<> already having some spare memory
>which can be re-used not causing the vector to copy the data.
>  
>
This is a completely new issue.

>std::allocator will just ignore the hint, and __mt_alloc will take the
>correct action! Doesn't this look exciting?
>  
>
Well, something is troubling me *a lot*: our std::vector is not supposed 
to be
used only with the bunch of allocators that we are providing, but with *any*
standard conforming allocator. You would pass to those allocators an 
hint not
correct wrt to the standard requirements: Table 31 says, about it

 "a value of type T::const_pointer obtained by calling Y::allocate or 
else 0"

More comments later...
Paolo.