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

[Neil S. <ne...@r0...>]

> I think ::swap() is a lame way to "deallocate" a vector's
> memory.  It requires creating a temporary vector, swapping
> contents with the vector whose buffer you want to throw away,
> and then clobbering the temporary vector.  I find the idea
> of having to summon up a trashcan, trading its emptiness
> with the trash of another, and then destroying the trashcan
> is nutty!
>
> The vector class should have had a ::deallocate() method from
> the very beginning.

Yes it is lame and a deallocate() method, or something like it, would have
been better.

> Since it did not, and the ::swap() technique is lame, and
> clobbering the owner of vector instances is lame, and adding
> a new method to vector is lame, the least-lame option
> is to exploit the lack of implementation specification of
> ::clear().

My other post gives several reasons why this is a bad thing and, as I said,
I don't think there is a lack of specification in the standard on this
matter, something which is reflected in all the STLs I have seen, except for
the one in VC7.

The least lame option would be to leave things as they are for now, and fix
the problem in the forthcoming, new standard, but by adding something like
deallocate() and not changing clear().

> Sure, existing applications will suffer a speed hit when
> recompiled, but the fix is as easy as searching for
> "clear()" and replacing with "resize(0)".
>
> I know that the "ease of fixing" is not a justification for
> changing the historical implementation!

You're right, it's not a justification, so it isn't acceptable to just
change things and hope everyone realises that what they thought was true is
actually not the case. Think of all the C++ web pages out there, all the
books, and all the programmers that are working to an assumption (actually,
a specification) which is not being followed properly. It seems to me that
getting all of them to change is far more of an issue than sticking to the
accepted implementation and well-known swap() method for releasing the
memory.

> I think the new implementation of clear has a few benefits:
>
> (1) Reduce memory waste due to vectors keeping up to
>      (2 * max_bytes_needed) over their lifetimes;

Well, apart from the fact that people already know how to free the memory
used by a vector (the swap method), this won't work, because only one
implementation does this. It's a worthless feature, because you cannot rely
on it.

> (2) Make crashing due to stale pointers and references
>      more likely!  As it was(/is), when one did a clear()
>      of a vector, pointers to elements would still work
>      until the vector grew!  With a ::clear() that
>      deallocates, the probability of discovering stale
>      pointers and references increases.

I think you already know that this is a pretty ropey justification. ;)

> (3) Custom allocators and deallocators will now have a
>      better sense of actual required memory on an
>      ongoing basis.

What makes you think that?

> As far as I'm concerned, the idea of something only growing
> and never shrinking sounds like a black hole or a memory
> leak!

Well, you shouldn't be using vector then. That's what it is supposed to do,
and it's a very useful idiom for many applications.

> I think Microsoft faced tough choices:
> (a) Do nothing, and suffer the ever-expanding memory
>       consumption of vectors scattered all over code;

Or do nothing and - shock, horror - remain identical to every other
implementation.

- Neil.