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

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

> Even Stroustrup's 2nd edition C++ book is worse than worthless now!
> I have a book called "The STL <PRIMER>" which is similarly
> obsolete.  (I think Josuttis's book is great, by the way!)
> Think of all the C++ STL demo code without "using namespace std;"!

True, things change all the time, but the current C++ standard will not.
Stroustrup's 3rd edition is based on the final draft of the standard, and he
clearly states that a vector never shrinks, so it seems that he doesn't
think the standard is vague on this matter either.

> Ideally changes would never affect existing code.  The idea of
> Microsoft adding a "::deallocate()" method may have been a
> preferable alternative to changing "::clear()".  Microsoft
> would depart from STL in either case (if one accepts that
> ::clear() should not deallocate), but at least a new method
> is something that would not affect existing code, and there's
> always the chance that "STL 2" would one day appear, and
> Microsoft could advocate their "::deallocate()" method.

It would affect any code written using their non-standard extension which
you then tried to build on another compiler. That's what standards are for.
If they are not going to stick to them, why implement them in the first
place? The second option, advocating the addition of the method to the new
standard, is the way to go.

> But maybe the intention was to affect existing code!  Maybe
> making ::clear() do deallocation is a pragmatic solution to
> a serious problem plaguing 99% of the typical uses of vector.
> I'm not saying I would support something like that, but it
> would be the same kind of thinking that would lead a car
> company to lower safety standards and accept the increase in
> lawsuits because it ultimately lowered their costs.  If
> changing ::clear() reduces disk access due to swapping, and
> thus generally improves the performance of applications
> running under Windows, "it's worth giving developers one more
> gotcha to be aware of".

Yes, I'm pretty sure it was something like this that prompted them to make
the change. They probably thought that the average developer didn't
understand the no-shrink policy on vectors, and so decided it would be best
for most people if they changed it. Unfortunately, they didn't show any
concern for developers who took the time to understand exactly how it
worked, or developers who wanted to write portable code, or in fact anyone
who thinks that standards are worth a toss. They didn't even bother to
mention it as a change to watch out for when migrating from VC6.

> absurdity in allowing ::clear() to deallocate, so I think it
> was kind of irresponsible to *rely* on clear() to not do deallocate!
> Maybe most people didn't so much "rely" on not deallocating
> as much as become surprised by the slowdown when it does start
> deallocating!

No. What was irresponsible was changing the behaviour to something which is
illegal according to the standard. If anything, myself and others have been
complete saps for relying on standards to be worth anything.

- Neil.