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

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

> 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.

Things are changing all the time.  I bought a new book on Linux driver
development two years ago, and the very first program in the entire
book, the "Hello, World!" of kernel modules, failed to compile due to
the relocation of header files.  Starting with a certain version of
Red Hat Linux, the technique of getting network stuff to work radically
changed -- lots of configuration files, etc, had been moved around.
HTTP is changing.  Java is changing.  PHP is changing.

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;"!

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.
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".

Speaking of awareness, Stroustrup's 3rd edition C++ book does
not mention the "well-known swap() method for releasing the
memory" of a vector.  Stroustrup does propose that one can
free up memory by assigning a new value to a vector, but
how lame is his example:

    v = vector<int>(4,99);  ?

It's worse than the ::swap() idea -- unless creating and
initializing a new vector to replace the existing vector
makes additional sense to one's particular application.

Josuttis's book does mention the ::swap() trick briefly, and
I imagine that if I did a Google search for "STL vector deallocate"
or something like that, I am sure I would discover the ::swap()
trick.

But, at the same time, one would discover that one cannot
rely on "::clear()" NOT doing deallocation anymore...!

Anyhow, if it is really critical to an application that
a core function, class, or data struction work or look a
certain way, then it should be wrapped!  Maybe it's lame
to wrap something that itself was meant to be the end-all
and be-all of wrappers in the first place, like STL,
but one has to dial up the countermeasures to address
the paranoia.

To summarize, I agree that changes cost humanity a lot of
time and effort.  I am intrigued by what may have motivated
Microsoft to change ::clear()...Was it to address an
internal need?  At the same time I am wondering what
application does so much vector filling and clearing
that malloc() takes 10% of the CPU time.  Polygon buffers
that are adapting every frame?

I'm glad this topic came up.  In my opinion it is further
support for defensive programming.  I think it's safe to assume
"Sleep(10000)" won't be added to the implementation of cos()
any time in the future, but I don't see the same kind of
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!

--- Colin

cp...@ea...