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

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

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.

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

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!

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;

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

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

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

I think Microsoft faced tough choices:
(a) Do nothing, and suffer the ever-expanding memory 
      consumption of vectors scattered all over code;
(b) Add a ::deallocate() method to vector, and experience
      the paranoia and wrath of cross-platform users of
      STL;
(c) Change ::clear() to do deallocation and suffer the
      wrath and paranoia of cross-platform users of STL
      who relied on the *implementation* of ::clear()
      operating a certain way;

Perhaps Microsoft will one day employ AIs in their workforce,
and so some poor AI can take the fall when the public gets
enraged.  This would bring new meaning to employee 
"termination"!  Of course, they would just reboot the 
employee to give it a new process ID, and thus flush away
liability without affecting productivity.  "Sure, PID 1337
put spyware and crash-hooks in IE 10.0, but PID 1337 was...
fired."

--- Colin

cp...@ea...