[Insight-developers] Questions about operator= in ITK

[Williams, Norman K]

In an unrelated investigation about C++ operator=, I came upon a
recommendation to always check if an object is being assigned to itself.

At best, you can avoid potentially expensive code that does nothing. At
worst, you can get tangled up in a maze of problematic object creation and
deletion.

So I began an audit of operator= in ITK, using grep-find in Emacs with
this command:

find . -type f -exec grep -nH -e 'operator=[^=]' {} /dev/null \; | grep
-iv 'not impl' | grep -v ThirdParty | grep -v 'Superclass::operator=' |
grep -v 'purposely not'

In other words, ignore the cases where it is declared but not implemented,
which is the proper behavior of ITK object types.

I've discovered some curiosities:

1. operator= returning void -- this seems like it's completely wrong, even
if the result is never used in practice.

2. Explicitly invoking Superclass::operator=
  Self & operator=(const Self & other)
  {
    Superclass::operator=(other);
    return *this;  }

3. Many cases of not checking for self-assignment.

I'm working on a patch to try and address these issues, but it raises some
questions.

Is case #2 as redundant as it appears? Should those 'defer to superclass'
assignment methods remain?

In the first case, it amounts to a change in the public API. Is this going
to break anything?

As regards case #3, is there any reason NOT to add the self-assignment
check?


--
Kent Williams norman-k-williams at uiowa.edu






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