Kent, Sorry for snow balling your topic which was almost ready to go :) But I think discussing the best practices for these issues is important.
Regarding how best to implement and document usage of default methods. Just another option is: C++x11 adds some interesting ways to define implicit methods as "default" or "deleted": http://en.cppreference.com/w/cpp/language/as_operator Basically you can add a "= default" or "= delete" after a declaration for certain methods like assignment operator, copy constructor, default constructor, etc. It would be plausible to use a macro for these situations that would do the C++x11 thing only when available. Say named ITK_IMPLICIT_DEFAULT and ITK_IMPLICIT_DELETE. The one advantage for this would be that is a developer tried to reimplement one of these methods there would be a compiler error on C++x11 systems. Beyond core ITK object I don't think its worth consider exception safety. Brad On Apr 2, 2013, at 9:57 AM, "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
