[Insight-developers] Questions about operator= in ITK

Tue Apr 2 11:40:12 EDT 2013

Matt,

I think I am disagree with you, regarding C++ requiring the explicit destructor to be virtual. And your interpretation of the slashdot page.

A virtual destructor is required to be explicitly implemented in base classes. We should have that in the itk::LightObject.

Derived classes' implicit destructor is also virtual. No need for an explicit empty destructor.

Further from your second provided link:

Checklist
To be able to quickly decide whether a class needs an empty non-inline destructor definition I condensed the above analysis into a short checklist. When designing a class interface, ask yourself the following three questions:

1) Do you need to anchor the vtbl (doesn’t apply to class templates)?
2) Does proper destruction of data members require additional declarations or functionality that is not available in the class interface? Does the destruction need to be done consistently with construction (e.g., using the same runtime)?
3) Do you need to define a stable interface and chances are that later you may have to add some functionality to the destructor?
If the answers to all these questions are “No”, then let the compiler provide the default implementation of the destructor.

So for the template classes where are derived from the itk::LightObject hierarchy , the answer is No to all of them. So this basically excludes compiled *.cxx, and absolute base classes. The rest should be OK, for implicit destructors.

Brad

On Apr 2, 2013, at 10:50 AM, Matt McCormick <matt.mccormick at kitware.com> wrote:

> 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