This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: vector<> can probably never grow to it's maximum size!
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.