VC STL - Re: HELP :: STL Vectors in VC7 - behaviour changed for clear() reserve()

Author

Re: HELP :: STL Vectors in VC7 - behaviour changed for clear() reserve()

Tom Widmer

2005-03-23, 9:01 am

Krishnan R.S. wrote:
> Hello Carl,
>
> Ahhhh - somehow thought that clear was implemented as clear() { erase(
> begin(), end() ); }
>
> At least that's what I gathered from the often referenced SGI site ...
>
> http://www.sgi.com/tech/stl/Vector.html
>
> And
>
> http://www.sgi.com/tech/stl/Sequence.html
>
> If you look at clear() in the Sequence.htm link it essentially says that
> clear() is an erase from begin() to end()

And so it is in SGI's STL.

> So calling erase() on the set of elems would not have changed much - or so
> it seems ....
>
> I guess that relying on clear() to remove only elems from the used part of
> the vector was really non-standard!!

Well, the standard is not particularly well specified when it comes to
the set of operations that can reduce the capacity of a vector.

> But they don't really say that capacity() will be affected in anyway - and
> size() and capcity() were _meant_ to be different things!
>
> But I'm glad to see that at least I'm not doing something that was
> fundamentally wrong in vc7.

I argued with the Dinkumware authors that this new behaviour was
surprising to many users regardless of the exact wording of the
standard, and they seemed to say that they would put it back the way it
was before (e.g. clear() doesn't modify capacity()). Does anyone have a
VC8 beta with which to confirm or deny this?

Tom

Tom Widmer

2005-03-23, 4:01 pm

Ken Alverson wrote:
> "Tom Widmer" <tom_usenet@hotmail.com> wrote in message
> news:eL61tE5LFHA.3632@TK2MSFTNGP10.phx.gbl...
>
>
>
> Judging by the number of times I've seen the "why doesn't my memory usage go
> down when I call vector<>.clear(), the "old" behavior was surprising to many
> users as well.

True, though I for one used to rely on it. Having resize(0), clear()
and/or erase(begin(), end()) behave differently doesn't seem like a good
idea to me. We have the well known shrink-to-fit and shrink-to-nothing
idioms if we really do want to reduce capacity. This is confusing enough
and it makes writing portable code hard enough that I think the standard
should be explicit on this point, and then there wouldn't be any need to
argue about it as a QOI issue.

Tom

Sponsored Links