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

[Dhruv Matani]

Hi,
	I have attached a patch that modifies the files:
allocator.h
vector.tcc
mt_allocator.h

And tries to explain more concretely what I'm trying to achieve and also
shows that it's do able in current C++.

Also, attached is a test case which shows that you get 2 times the speed
with the patch than without the patch. To enable the speedup, define
ALLOC_ to std::allocator, and to disable it, use ALLOC_
__gnu_cxx::mt_alloc

So, this is definitely do able with the present situation.

This is a very rough patch that just about compiles and works, and is
not something to be comitted. The organization is very bad, and vector
and the allocator use global types defined in the .cpp file.


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: patch_beta_vector_allocator_19102004_dhruv
Type: text/x-patch
Size: 4487 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20041019/bf310fcf/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vec_expand.cpp
Type: text/x-c++
Size: 1384 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20041019/bf310fcf/attachment-0001.bin>