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

[Dhruv Matani <dhruvbird at gmx dot net>]

On Wed, 2004-10-20 at 19:28, Paolo Carlini wrote:
> Dhruv Matani wrote:
> 
> >The part which handles this case is within the
> >__mt_alloc::allocate(n,hint,hint_passer) overload.
> >
> >Look at the case where __n*sizeof(_Tp) > 128. There is a series of try
> >catch which use the _M_at_least field of the hint_passer to detect if
> >the allocator can if the __n failed, allocate at least _M_at_least
> >objects. If so, then it will succeed.
> >  
> >
> You never answered my first objection: if, for whatever reason, 
> ::operator new starts
> throwing and every time you allocate only 1 position more, the container 
> doesn't
> grow anymore with the speed mandated by the standard. The only way to be 
> correct
> is multiplying the previous size by factor bigger than 1, typically 1.5-2.0.

Yes, but isn't it better to have the container grow somehow rather than
have it throw bad_alloc even though it can grow by whatever little it
can in situations where the memory available is low.


> 
> Also, please, don't send every time a whole patch including 
> *everything*: you
> understand that we are definitely at the general design stage, so many 
> things and
> details have to be sorted out and discussed before something like this 
> finds its
> way in the repository...

Ok, sure!

> 
> And, please, again, let's discuss one issue at a time.

Ok, to get it straight, we are discussing the issue of:
1. mt_alloc over-allocating memory, and the containers taking advantage
of that.
2. operator new failing with very large sizes even though the vector can
grow by asking for slightly lesser amount of memory. I have unwillingly
clubbed these 2 issued, because they are inter-related and the
infrastructure that allows to deal with either is common and
overlapping.


> 
> 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