Dear John, On Tue, 17 Nov 2009, John Peterson wrote:
> Despite it being Item 9 in the 3rd ed. of "Effective C++" I admit to > being unaware that you should never call virtual functions in (base > class) constructors or destructors! Nice to hear that I'm not the only person here that didn't know that. > Since this is potentially misleading to users deriving from LibMesh > classes: "Hey, I don't need to call clear() in my destructor because > it's already done in the base class!" my vote would be to make all > "clear()-like" functions (functions intended to be used in > destructors) non-virtual in the library. I suspect this will be > difficult to enforce in practice though... > > The idea of a virtual clear() function seems like a nice one, but I > suspect it's rarely exactly what you want, Well, there could possible be some cases (in the library or in user code) where, say, NumericVector::clear() is called *outside* its destructor. Assuming the actual instance is, say, a PetscVector, this would put it into an invalid state, that is _is_initialized would be false, but data would still be allocated. A subsequent call to PetscVector::init() would allocate a new block of memory without freeing the old one, thus be a memory leak. Of course, if one is intending to call PetscVector::init(), there is no need to previously call NumericVector::clear() rather than PetscVector::clear() (or just nothing since PetscVector::init() will call clear() itself if necessary), one one never knows what people are doing. In particular since in the current implementation (having clear() be virtual) it doesn't make any difference. > As I understand the way destructors work, if you delete an object of > type derived through an object of type pointer-to-base, as long as the > base class destructor is declared virtual, the derived class > destructor will be called *in addition to* the destructor for *every* > intermediate type. Correct? This is always done, no matter whether the destructor is virtual or not. Actually, I'm not sure any more myself what the best solution is. Perhaps, keep everything as it is, but place an eye-catching comment inside of virtual destructors that call virtual clear() methods, explaining this problem. (Say, if this would have been the case previously, I think I would not have run into this error.) This would also have the advantage of not being prone to break user code since it's only comments. Best Regards, Tim -- Dr. Tim Kroeger [email protected] Phone +49-421-218-7710 [email protected] Fax +49-421-218-4236 Fraunhofer MEVIS, Institute for Medical Image Computing Universitaetsallee 29, 28359 Bremen, Germany ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
