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

[Dhruv Matani <dhruvbird at gmx dot net>]

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.

The wrapper would go around std::allocator<>, but never mind, because
the assumption about 'hint' that I started off with was flawed from the
outset. See below.

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

I shall think more about this, because I'm still not convinced.

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

Yes, I stand corrected. Now, the situation as it stands is:
pointer allocate(size_type n, allocator<void>::const_pointer hint=0);

  Notes:
    Uses ::operator new(size_t) (_lib.new.delete_).
  Requires:
    hint  either  0  or previously obtained from member allocate and not
    yet passed to member deallocate.  The value hint may be used  by  an
    implementation to help improve performance3).
  Returns:
    a pointer to the initial element of an array of storage of size n  *
    sizeof(T), aligned appropriately for objects of type T.
  Note:
    the storage is obtained by calling ::operator new(size_t), but it is
    unspecified when or how often this function is called.  The  use  of
    hint is unspecified, but intended as an aid to locality if an imple-
    mentation so desires.
  Throws:
    bad_alloc if the storage cannot be obtained.




So, the hint argument has to be a previously returned pointer, not just
about anything. However, what the allocator does with it is
implementation defined.

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