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
