For almost all cases where we have virtual classes, we should declare the destructor explicitly so that it can be declared virtual per
http://stackoverflow.com/questions/827196/virtual-default-destructors-in-c http://www.codesynthesis.com/~boris/blog/2012/04/04/when-provide-empty-destructor/ Matt On Tue, Apr 2, 2013 at 1:57 PM, Williams, Norman K <[email protected]> wrote: > I agree in principle with using the implicit destructor/copy > constructor/operator= but as we've discussed, perhaps these should be > documented in a comment/Doxygen. > If someone changes the class to require a non-default version, they need > to know they're responsible for adding one. Compilers are no help as far > as I know. > > Default copy/operator= is good enough in most cases; for each instance var > it does an assignment. Brad King (and > http://www.cplusplus.com/articles/y8hv0pDG/ ) make the point that if > there's any circumstances where an exception could be thrown, an > exception-safe copy constructor/operator= should be provided, and use the > copy/swap pattern. > > As for ITK object types, default copy/operator= could be scary. That's > why it was a good design decision to use the SmartPointer/Factory pattern > for object creation. > > There isn't a problem for having SmartPointer members per-se -- their > explicit operator= should do the thread-safe copy and reference count. Of > course a distinction needs to be very clear between a shallow copy and a > deep copy that doesn't copy the object reference but creates a new object > with the same contentŠ > > -- > Kent Williams [email protected] > > > > > > > On 4/1/13 2:49 PM, "Bradley Lowekamp" <[email protected]> wrote: > >>Kent, >> >>In looking at your patch a large number of the operator= methods do what >>the the C++ implicit implementation would do. If the compiler will >>generate and maintain the method for use I think we should use it. It'll >>decrease the likely hood of errors being made when new IVARS are added to >>these classes. >> >>Similarly, there are ALOT of destructors which are empty and could be >>removed to just use the C++ implicit one. >> >>Should we use these implicit methods in ITK? >>Should be require a comment that the method is implicitly defined? >> >>Brad >> >>On Mar 28, 2013, at 11:41 AM, Brad King <[email protected]> wrote: >> >>> On 03/28/2013 11:29 AM, Williams, Norman K wrote: >>>> There is a standard way to poison assignment and copy constructor, >>>>which >>>> is to declare them protected and then not implement them. This is >>>> implemented consistently across all classes that derive ultimately from >>>> itk::LightObject. >>> >>> I meant that *those* poisoned operators return void. Others should not. >>> >>>> The copy/swap paradigm is recommended a lot of places. I haven't >>>> encountered a case in ITK that it would make a difference. The usual >>>> pattern suggested is >>>> >>>> X& operator=(const X &x) >>>> { >>>> X tmp(x); >>>> swap(*this,x); >>> >>> s/x/tmp/ >>> >>> However, see here for why to pass by value: >>> >>> >>>http://stackoverflow.com/questions/3279543/what-is-the-copy-and-swap-idio >>>m >>> http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/ >>> >>> -Brad >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Kitware offers ITK Training Courses, for more information visit: >>> http://kitware.com/products/protraining.php >>> >>> Please keep messages on-topic and check the ITK FAQ at: >>> http://www.itk.org/Wiki/ITK_FAQ >>> >>> Follow this link to subscribe/unsubscribe: >>> http://www.itk.org/mailman/listinfo/insight-developers >> >>_______________________________________________ >>Powered by www.kitware.com >> >>Visit other Kitware open-source projects at >>http://www.kitware.com/opensource/opensource.html >> >>Kitware offers ITK Training Courses, for more information visit: >>http://kitware.com/products/protraining.php >> >>Please keep messages on-topic and check the ITK FAQ at: >>http://www.itk.org/Wiki/ITK_FAQ >> >>Follow this link to subscribe/unsubscribe: >>http://www.itk.org/mailman/listinfo/insight-developers > > > > ________________________________ > Notice: This UI Health Care e-mail (including attachments) is covered by the > Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential > and may be legally privileged. If you are not the intended recipient, you > are hereby notified that any retention, dissemination, distribution, or > copying of this communication is strictly prohibited. Please reply to the > sender that you have received the message in error, then delete it. Thank > you. > ________________________________ > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Kitware offers ITK Training Courses, for more information visit: > http://kitware.com/products/protraining.php > > Please keep messages on-topic and check the ITK FAQ at: > http://www.itk.org/Wiki/ITK_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.itk.org/mailman/listinfo/insight-developers _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Kitware offers ITK Training Courses, for more information visit: http://kitware.com/products/protraining.php Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ Follow this link to subscribe/unsubscribe: http://www.itk.org/mailman/listinfo/insight-developers
