Re: std::vector::clear (was: [GD-Windows] VS.net rants, was Re: VC++ lag)
Brought to you by:
vexxed72
From: Neil S. <ne...@r0...> - 2003-06-14 11:23:24
|
> 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. |