[Insight-developers] Questions about operator= in ITK

Bradley Lowekamp blowekamp at mail.nih.gov
Mon Apr 1 15:49:55 EDT 2013


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-idiom
> 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



More information about the Insight-developers mailing list