On Mon, 28 Jan 2013, Kirk, Benjamin (JSC-EG311) wrote:
> On Jan 28, 2013, at 12:54 PM, Roy Stogner <royst...@ices.utexas.edu> wrote: > >> The downside is that any attempt to destroy a Node via a DofObject >> could then fail horribly. This used to be a concern for us, when we >> had an API returning AutoPtr<DofObject>, but library code should be >> fine now. >> >> Opinions? > > Yeah, actually needing to delete a Node or Elem from a DofObject pointer > seems like just a bad design, so I appreciate the fix. > This sounds like a good thing. Okay, in that case maybe you'd like to help quell my only concern: if someone *does* try to delete a Node or Elem from a DofObject pointer, is there any way we can make that give a sane run-time or preferably compile-time error rather than "eh, they'll notice the memory corruption eventually"? It seems like conceptually we want DofObject to be an abstract base class that never actually gets instantiated on its own, but making it abstract is exactly what we *can't* do if we want to keep it clear of virtual functions. Would it be sufficient to make the constructor and destructor protected? --- Roy ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
