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

[Dhruv Matani]

Hi,
	I attaching a patch to implement my ideas on Issue2:
"Issue2: Allocators such as mt_alloc<> already having some spare memory
which can be re-used not causing the vector to copy the data."

I would like to know what your take is on this, and should it be
implemented?

Also attached is a test-case. std::allocator with the base allocator as
__mt_alloc<> enables the optimization.

-Dhruv.

On Tue, 2004-10-19 at 00:41, Paolo Carlini wrote:
> 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.
-- 
        -Dhruv Matani.
http://www.geocities.com/dhruvbird/

The price of freedom is responsibility, but it's a bargain, because
freedom is priceless. ~ Hugh Downs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vec_expand.cpp
Type: text/x-c++
Size: 343 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20041020/4b4cdb6e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_beta_vector_allocator_20102004_dhruv
Type: text/x-patch
Size: 6025 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20041020/4b4cdb6e/attachment-0001.bin>