[Insight-developers] Questions about operator= in ITK

Tue Apr 2 11:52:29 EDT 2013

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" <norman-k-williams at uiowa.edu> 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 norman-k-williams at uiowa.edu
> 
> 
> 
> 
> 
> 
> On 4/1/13 2:49 PM, "Bradley Lowekamp" <blowekamp at mail.nih.gov> 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 <brad.king at kitware.com> 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.
> ________________________________