Std::vector::clear() in constructor and destructor?

From the sound of things, the people who wrote that code were the ones who missed something. The only time it would make sense to call clear() in a ctor or dtor would be in the middle of some other code. For example, a ctor might read in some data, process it, then read in more data.In such a case, it's probably faster to use a single container for the data as you read it in, and clear it each time, than to create a new container every iteration.

No, you're not missing anything. I suspect this is (harmless) voodoo programming, sort of like setting a pointer to null after freeing it, or randomly calling repaint/revalidate in GUI code. The programmer remembers that it helped with some sort of bug in the past and now adds it unnecessarily "just in case".

Who knows, maybe it'll help. Voodoo.

1 nice term, 'voodoo programming' :) – xtofl Oct 19 '09 at 20:51 5 Setting a pointer to null isn't voodoo, it helps greatly in debugging. Also prevents you from deleting the same pointer twice, but nobody ever does that - right? – Mark Ransom Oct 19 '09 at 21:01 10 If anything, you want to know that you deleted the same pointer twice.It is better to fail loudly (and find out about it) than accidentally succeed (masking a bug that will come back to bite you) – Greg Rogers Oct 19 '09 at 21:04 I like that saying, "better to fail loudly" – GMan Oct 20 '09 at 0:37 @Mark: setting a pointer member to NULL in a dtor, when it's about to disappear entirely?

Because that's the context we're talking about. – MSalters Oct 20 '09 at 8:50.

Nope, you're right. Unless there is some additional business in the constructor (or constructor of the base classes) that require that, but the chances are very low... Later edit In case of destructor, one of the most common mistakes I saw is that some people assume that clear method will also call delete for vectors of pointers (vector), which, of course, it is not the case.

It's COMPLETELY unnessecary to clear the contents of an stl container in a constructor It's unnessecary to clear the contents of an stl container in a destructor UNLESS the container contains a pointer. If the pointer has been created using new, it still needs to be deleted first. After that it still will not be nessecary to .

Clear the container. Consider this : #define BOOST_TEST_MODULE StlContainers #define BOOST_LIB_DIAGNOSTIC #include #include #include #include #include using namespace boost::assign; using namespace std; const vector my_ints_vector = list_of(0)(1)(1)(2)(3)(5)(8)(13)(21)(34); struct ScopedStruct1 { ScopedStruct1(const vector & v) : m_v(v) {} ~ScopedStruct1() {} private : vector m_v; }; class A { public : A(int i) : m_i(i) {} ~A() {} private : int m_i; }; struct ScopedStruct2 { ScopedStruct2() {} ~ScopedStruct2() { for(vector::iterator it = m_v.begin(); it! = m_v.end(); ++it) delete *it; } vector m_v; }; struct ScopedStruct3 { ScopedStruct3() {} ~ScopedStruct3() { /* no deletion */ } vector m_v; }; BOOST_AUTO_TEST_CASE(StlContainer_storing_something_simple) { ScopedStruct1 str(my_ints_vector); } BOOST_AUTO_TEST_CASE(StlContainer_storing_pointers_with_delete) { ScopedStruct2 str; for(int I = 0; I M_v.

Push_back(new A(i)); } BOOST_AUTO_TEST_CASE(StlContainer_storing_pointers_without_delete) { ScopedStruct3 str; for(int I = 0; I Push_back(new A(i)); } Using boost's unit_test framework I've created 3 test cases. The unit_test framework is greate because it tracks memory leaks. You'll notice that the 1st and 2nd test case don't generate memory leaks, but the 3rd case does because the vector's contents are not deleted.

The only case I can think of where it would be useful is where the order of destruction matters and the destructor wants to ensure that the objects in the vector are destroyed before something else. Of course, it is better to structure code to not require that; however, it is a conceivable reason.

Despite what what said so far, there's at least one scenario when an explicit call to clear in the destructor might be necessary. Imagine the situation when the object being destroyed has several member subobjects, which require some specific order of destruction, i.e. The subobjects somehow depend on each other, and an incorrect order of their destruction will lead to undesirable results.As you probably know, the order of member subobject destruction (as well as member initialization) is determined by the order of members' declararion in class definition.

So, one way to achive the proper order of destruction is to arrange the member declarations accordingly. However, firstly, this is not a very good solution maintenance-wise. Secondly, the desired order of destruction might depend on some run-time conditions.

Thirdly, the desired order of destruction might contradict the desired oreder of initialization. This all means that it might not be possible (or wise) to command the proper order of destruction by re-arranging the declarations. A reasonable approach in this case might be to clean-up some critical member subobjects manually, by calling their clean methods or such, until the destruction order dependency "disappears".

I would guess, that maybe the code that you saw was trying to resolve to ordering problem by calling clean on a strategically selected vector subobject. As for calling clean in constructor... I have no idea why anyone would do something like that.

Apperently you live in too reallistic word :) Every time I examined code, it tried to achive "clean" in constructor/destructor. As regards to situation you describe, I can hardly amagine it. Best should be done to avoid it and if not possible should be well commented – dimba Oct 20 '09 at 4:00 I might be wrong, but when the stl object is dying at an end of scope - for instance.It calls the destructor of the object within.

If that said object is also an stl container it should clear itself up automatically too. Exceptional situation would arise with a pointer initiated by "new" - as usual – Maciek Oct 20 '09 at 23:42 1 @Maciek: Nobody argues with that. What I'm saying, again, that the order of that automatic cleanup might be unacceptable in some cases.

In which cases you might have to do your own, custom ordered pre-cleanup before the automatic cleanup begins. – AndreyT Oct 21 '09 at 0:02.

Of course one has to call clear() or resize(0) or the equivalent say (std::_Destroy_range(...) in the destructor before deallocating. Deallocation is done via allocator::deallocate which does NOT run any destructors. It just frees the memory.Clear() is equivalent to resize(0) which runs destructors on the first size() things in the allocated buffer NOT just allocated pointers, file handles, held mutexes, all other recoverable resources held by the object.

The destructors MUST be run. Before instantiation the template doesn't know that the destructor is trivial. If the destructor is trivial, THEN its gets optimized out AFTER instantiation.

1 No, destructors are definitely called when a vector goes out of scope. Not calling destructors makes no sense. I suggest you examine your implementation carefully.

You can test this by running something like this: #include #include struct Test { ~Test() { std::cout t(1); std::cout.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.