Re: [Libmesh-devel] Virtual destructor ~Node()

[Kirk, B. (JSC-EG311) <ben...@na...>]

Im fine with the proposed removal - in general anyone outside the library deleting nodes deserves what they get! ;-)

On Nov 11, 2011, at 10:26 AM, "Roy Stogner" <roy...@ic...> wrote:

> 
> 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-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel