We have virtual destructors for Node and its parent classes (DofObject, TypeVector, Point, ReferenceCountedObject<Node>, and ReferenceCounter) now, and the resulting vptr tacks on 8 bytes (4 on 32-bit systems) to each Node in the mesh. Since there's no longer any other virtual functions in those classes, the vptr ought to go away if we make the destructor non-virtual, saving us a few megabytes of memory on large problems. So I'm thinking of getting rid of the virtual destructors.
The problem is then that if anyone tries to delete a Node through a pointer-to-parent-class (or delete any other ReferenceCountedObject subclass through a pointer-to-RCO, or delete an Elem through a pointer-to-DofObject...), it would be undefined behavior. Of course, it would still be okay to delete a subclass of Elem, which will still have its vptr regardless, through a pointer-to-Elem. I'm happy with the alternative solution of "don't ever delete a Node through a pointer-to-parent-class, etc.", but if anyone else isn't happy with that then please speak up and veto me. (Cc: to libmesh-users in case anyone's depending on that level of OOP in their application code) Sadly, although the above discussion is about efficiency, this issue came up in the context of correctness: when generating MPI datatypes for C++ classes with vptrs, you need to take the changed offsets into account. Expect to see libMesh 0.7.2.1 out soon, with the new exciting feature of "Parallel::*(Point&) actually works properly in 3D"... --- Roy ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
