RE: std::vector::clear (was: [GD-Windows] VS.net rants, was Re: VC++ lag)
Brought to you by:
vexxed72
From: Paul B. <pa...@mi...> - 2003-06-14 16:16:59
|
=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 |