dhruvbird@gmx.net ("Dhruv Matani") wrote (abridged):
> Yes, but practically it is not the case, so when the user just wanted to
> add 1 more entry and the vector fails is much worse IMHO to copy 1.2Gb
> in large amount of time and have the operation succeed.

What I had in mind was that the vector would not fail, but would instead
grow to the largest capacity which would succeed. (Probably it would need
to attempt to grow, catch the bad_alloc and then try again with a smaller
size, rather than use max_size().) I suggest that would be better than
growing by exactly 10 elements.

I think that would be conforming; I don't think the standard need change
to permit it. The notion of "amortised constant time" is a bit wooly
anyway if subsequent growths are going to fail.

I suppose there may be pathological cases where some other process is
releasing memory at the same rate the vector is growing, so the too-slow
growth might continue indefinitely. Perhaps the vector needs a minimum
growth rate and must fail if that is not reached - but it could be very
low.

In practice, programs which /nearly/ run out of memory usually /do/ run
out of memory, given just a bit more time. So we are probably just
postponing the inevitable and the real fix is to get more memory. As such
it probably isn't worth much extra complexity in std::vector.

Whether a timely fail is better than a delayed success is deep question.
For the C++ standard, "time is the essence of the contract" and a late
answer is a wrong one. I think a variation like, "Push_back() takes
amortised constant time unless memory is nearly full" would be too vague
to be useful.

-- Dave Harris, Nottingham, UK

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 03 Nov 2004 19:28:54 +0000, Dave Harris wrote:

> dhruvbird@gmx.net ("Dhruv Matani") wrote (abridged):
>> Yes, but practically it is not the case, so when the user just wanted to
>> add 1 more entry and the vector fails is much worse IMHO to copy 1.2Gb
>> in large amount of time and have the operation succeed.
>
> What I had in mind was that the vector would not fail, but would instead
> grow to the largest capacity which would succeed. (Probably it would need
> to attempt to grow, catch the bad_alloc and then try again with a smaller
> size, rather than use max_size().) I suggest that would be better than
> growing by exactly 10 elements.
>
> I think that would be conforming; I don't think the standard need change
> to permit it. The notion of "amortised constant time" is a bit wooly
> anyway if subsequent growths are going to fail.
>
> I suppose there may be pathological cases where some other process is
> releasing memory at the same rate the vector is growing, so the too-slow
> growth might continue indefinitely. Perhaps the vector needs a minimum
> growth rate and must fail if that is not reached - but it could be very
> low.

Ok, something like the silly window syndrome?


>
> In practice, programs which /nearly/ run out of memory usually /do/ run
> out of memory, given just a bit more time. So we are probably just
> postponing the inevitable and the real fix is to get more memory. As such
> it probably isn't worth much extra complexity in std::vector.

Yes, that's also true. And the extra complexity is probably not called for
anyway.

But, there are a few (maybe very few) cases where this does not happen.
Now singling those cases where the program actually crashes from those
where it does not would be very difficult for the vector to tell, and
could definitely not foretell the future!


>
> Whether a timely fail is better than a delayed success is deep question.
> For the C++ standard, "time is the essence of the contract" and a late
> answer is a wrong one. I think a variation like, "Push_back() takes
> amortised constant time unless memory is nearly full" would be too vague
> to be useful.

I guess what has let the cat out of the bag is the description of
vector<>::max_size(), which says that it denotes not the maximum
practical capacity, but the theoretical maximum.


Regards,
-Dhruv.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]