[Insight-developers] Questions about operator= in ITK

[Williams, Norman K]

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