From: Roy S. <roy...@ic...> - 2010-01-11 15:24:01
|
Cody, might I ask why you changed the LibMeshInit destructor to be virtual? I'm not disagreeing with the change (one extra vptr for a singleton object isn't a big deal), but I'm curious about the reason behind it. If you're creating an object for your own framework's initialization that inherits from LibMeshInit, it might be safer to create one that contains a LibMeshInit instead. There's less change of anyone accidentally breaking things out from under you that way, which might be a worry since (clearly) we weren't picturing LibMeshInit as being a base class. --- Roy |
From: Cody P. <cod...@gm...> - 2010-01-11 19:44:55
|
On Jan 11, 2010, at 8:23 AM, Roy Stogner wrote: > > Cody, might I ask why you changed the LibMeshInit destructor to be > virtual? I'm not disagreeing with the change (one extra vptr for a > singleton object isn't a big deal), Yes we figured this wasn't a big deal as well > but I'm curious about the reason > behind it. If you're creating an object for your own framework's > initialization that inherits from LibMeshInit, it might be safer to > create one that contains a LibMeshInit instead. We started with this idea but then quickly decided that we didn't want to rewrap or force end users to dig through our object to get at the LibMeshInit interface. > There's less change > of anyone accidentally breaking things out from under you that way, > which might be a worry since (clearly) we weren't picturing > LibMeshInit as being a base class. We do understand the risk of having things break out from underneath us with the chosen path but figured that the extra encapsulation and cleaner end interface would be worth the extra potential maintenance. Either model for wrapping the LibMeshInit object has it's ups and downs and both options seemed to have nearly equal tradeoffs so we picked one for our library. If it becomes a problem to inherit from an object that wasn't designed to be a base class we will reconsider our strategy and implement a different solution. If you believe that there might be further negative implications to this strategy please share with us. Thanks, Cody > --- > Roy > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |