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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

=20
I'm not arguing for/against the change in VC7, but I read through good
chunks of the standard last night and found only a couple references
to the requirements of clear().  And each of those was in context of
running time and not implementation.
=20
Is there a particular part of the standard that clearly says that clear
*must be implemented* as erase(begin(), end())?
=20
Moreover, the point of standards (especially the C++ standard) is as
much what they say and what they *do not* say.  Your argument that
since it doesn't explicitly say clear() deallocates means that it should
not is wrong.  There is a clear language in the standard of phrases
like "should have" and "must have" and such that have well defined
meanings.  Lack of specification is exactly that - something the=20
standard fails to specify. =20
=20
A similar argument used to occur with list<>::size() being O(N) on=20
one implementation and O(1) on just about nearly every other=20
implementation. =20
=20
Luckily the next round of C++ standards (probably around 2020 at
the current pace) should clearly define more implementation=20
requirements of the STL, but I still doubt they will define allocation
deallocation requirements.
=20
Paul
=20

________________________________

From: gam...@li... on behalf of Neil =
Stewart
Sent: Sat 6/14/2003 6:25 AM
To: gam...@li...
Subject: Re: std::vector::clear (was: [GD-Windows] VS.net rants, was Re: =
VC++ lag)

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

-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D555