Re: std::vector::clear (was: [GD-Windows] VS.net rants, was Re: VC++ lag)

[Colin F. <cp...@ea...>]

> > For some reason, they have changed the functionality of vector::clear()
to
> > actually deallocate memory, rather than simply doing erase(begin(),
end()),
> > which leaves the memory allocated.
>
> It sounds to me like you were relying on an implementation dependency.
> My copy of "C++ Standard Library" by Josuttis just says that both of
> these will remove all the elements of the vector.  AFAIK, the standard
> makes no requirements about allocation/deallocation behavior for these
> operations, but I would expect both to potentially deallocate memory
> when I delete the whole vector.  If you want to clear the vector
> without changing its allocation, you should do vector::resize(0) IMO.

Suppose the author of a popular library changed the implementation of the
sin() function to include Sleep(10000).  Ah, it was a mistake for the
programmer to DEPEND on the timing of the sin() function!  ;-)

Still, I like the idea of vector::clear() deallocating memory.  I think
that should have been the explicit specification all along.  Using
vector::resize(0) would have become a well-known optimization for avoiding
future malloc() calls when the same vector is drained and filled to a
similar level of capacity numerous times.

If vector::clear() didn't guarantee deallocation, then would the only
alternative be to clobber the object that contained the vector?
(Wouldn't calling the destructor explicitly be bad?)

Anyhow, unless I'm misunderstanding something, I'm glad for the
change.  I never liked the idea of memory sticking around,
and the memory persisting as the maximum size of all previous
uses of that vector.  Sure, I can clobber the object that owns
the vector, but sometimes that doesn't seem appropriate.

The weird thing is DEPENDING on the NEW implementation of
vector::clear() is just as bad as depending on the old implementation.
It's a shame, because vector::clear() becomes a useless method --
unless users of vector::clear() can hope that the implementation
will do what is statistically best for the platform.  Could it
be said that doing deallocation is an improvement under the
Windows platform?  Apparently not for some people.  But maybe
the dominant use of vector benefits from the deallocation behavior.

Still, I could imagine a persisting vector getting a spike of
stuff to fill it, getting cleared, and yet holding on to a huge
amount of memory.  Maybe it's bad design to keep the vector
around after it was drained after a big spike.

I suppose profiling memory and speed performance will always
reveal what is really important for an application, and the design
can be changed to respond to the reality of the current circumstances.

--- Colin

cp...@ea...