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

[Dhruv Matani]

On Mon, 2004-10-18 at 19:02, Paolo Carlini wrote:
> Dhruv Matani wrote:
> 
> >// Ok, we did not get how much we asked for. But the allocate(n, hint)
> >is implemented such that if the allocator could not allocate the
> >required memory, it gives us whatever little it can, and sets
> >settle_for_less_memory to the number of objects that it actually has
> >allocated space for. This magic should go into the allocator.
> >  
> >
> This is interesting, but I cannot understand anymore what you want to work
> on!! Do you want to work on a new allocator? Or improve the conformance
> of std::vector? Or specialize its behavior for a new allocator? Or you want
> to change the standard as far as vector memory allocation is concerned?

Sorry for the confusion!
Ok, here's what I want to do:

1. Include support for such an allocator in our library(more
specifically vector).
2. You must have noticed that __mt_alloc<> allocates more memory than
required at times. We can take advantage of this fact, and include
support for this functionality within __mt_alloc::allocate(n, hint)
itself!
3. The standard already permits hint to take on any implementation
defined meaning, so changing the standard is out of question. The
changes proposed herein can be implemented within the realms of the
current standard itself!
4. The post on google also hints at changing the behaviour of
new_allocator<> for in-built types so that copying is not required if
realloc is used. This is probably a not so related issue, so clubbing
these would probably not be right.

Another advantage of (2) would be that if the newly returned pointer is
the same is _M_start, then we may elide the copy altogether! Thus,
improving the run-time speed of vector further until it grows larger
than 128-bytes.

These improvements should be made to currently used allocators such as
__mt_alloc<> who so many people including yourself have worked so hard
on, so that that effort also does not go wasted. Also, __mt_alloc<> is
amenable quire readily to these changes AFAICS! A new allocator is
probably uncalled for.



> 
> I'm confused, just let us know and we can plan the *remaining* tasks... ;)
> 
> 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