[Insight-developers] Questions about operator= in ITK

[Matt McCormick]

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
<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.
> ________________________________
> _______________________________________________
> 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