Re: Can a temporary be assigned to itself?

Discussion in 'C++' started by Öö Tiib, Mar 22, 2013.

  1. Öö Tiib

    Öö Tiib Guest

    On Friday, 22 March 2013 11:05:54 UTC+2, Juha Nieminen wrote:
    > If you are implementing the regular operator=() for a class, you (usually)
    > need to take into account the special case that the same object is being
    > assigned to itself. (If you don't, you may end up deleting the managed
    > resource when you shouldn't.)


    The other reason is that self-assignment (while not illegal) is typo defect on
    most cases. Sometimes it is worth trying to achieve some run-time diagnostic
    in debug builds.

    Typical implementation is copy-construct local and swap with it. That will
    work on case of self assignment.

    > However, is the same true for the operator=() taking an rvalue reference?
    > Do you have to take into account the possibility that the object may be
    > assigned to itself?


    I do not think so. Even if someone can conjure up a trick, it does not feel
    to be reasonable situation.
    Öö Tiib, Mar 22, 2013
    #1
    1. Advertising

  2. Öö Tiib

    Balog Pal Guest

    On 3/22/2013 10:37 AM, Öö Tiib wrote:
    > On Friday, 22 March 2013 11:05:54 UTC+2, Juha Nieminen wrote:
    >> If you are implementing the regular operator=() for a class, you (usually)
    >> need to take into account the special case that the same object is being
    >> assigned to itself. (If you don't, you may end up deleting the managed
    >> resource when you shouldn't.)

    >
    > The other reason is that self-assignment (while not illegal) is typo defect on
    > most cases.


    Is it really? Sure, a=a makes little sense, but that hardly survives
    review. The normal case is like a = foo() or vec = vec[foo(i))].

    > Sometimes it is worth trying to achieve some run-time diagnostic
    > in debug builds.


    I never thought of that.
    Btw the more serious case for self-assignment and aliasing are not the
    plain but the compound assignments. where the straight form a+=a makes
    perfect sense too.

    >> However, is the same true for the operator=() taking an rvalue reference?
    >> Do you have to take into account the possibility that the object may be
    >> assigned to itself?

    >
    > I do not think so. Even if someone can conjure up a trick, it does not feel
    > to be reasonable situation.


    Yeah, IMO it would need some pretty evil trickery that is a more serious
    issue in itself.
    Balog Pal, Mar 22, 2013
    #2
    1. Advertising

  3. Öö Tiib

    Öö Tiib Guest

    On Friday, 22 March 2013 14:30:55 UTC+2, Balog Pal wrote:
    > On 3/22/2013 10:37 AM, �� Tiib wrote:
    > > On Friday, 22 March 2013 11:05:54 UTC+2, Juha Nieminen wrote:
    > >> If you are implementing the regular operator=() for a class, you (usually)
    > >> need to take into account the special case that the same object is being
    > >> assigned to itself. (If you don't, you may end up deleting the managed
    > >> resource when you shouldn't.)

    > >
    > > The other reason is that self-assignment (while not illegal) is typo
    > > defect on most cases.

    >
    > Is it really? Sure, a=a makes little sense, but that hardly survives
    > review. The normal case is like a = foo() or vec = vec[foo(i))].


    If this has high likelihood to end with self-assignment then there might be
    is some higher level logic error. For me self-assignment is legal thing
    that should happen very rarely and on most cases is worth attention.

    Same is with 'swap(x,x)' ... it is often worth attention why it did happen.

    > > Sometimes it is worth trying to achieve some run-time diagnostic
    > > in debug builds.

    >
    > I never thought of that.


    When you do not care then it makes sense to write something very simple,
    like that:

    Foo& Foo::eek:perator=(Foo rhs)
    {
    swap(rhs);
    return *this;
    }

    All ways to worry about self assignment erased.

    > Btw the more serious case for self-assignment and aliasing are not the
    > plain but the compound assignments. where the straight form a+=a makes
    > perfect sense too.


    Yes, but that is totally different function. Usually operator+(2) is implemented in terms of it.

    > >> However, is the same true for the operator=() taking an rvalue reference?
    > >> Do you have to take into account the possibility that the object may be
    > >> assigned to itself?

    > >
    > > I do not think so. Even if someone can conjure up a trick, it does not feel
    > > to be reasonable situation.

    >
    > Yeah, IMO it would need some pretty evil trickery that is a more serious
    > issue in itself.


    Also now I checked my code and seems that I have none assignments that
    need a self assignment check for other purposes than for the debug
    diagnostic. Those just somehow work without that check on case of a=a too..
    It is perhaps gone so because I was achieving exception safety.

    The shortest such trickery is perhaps ...

    x = std::move(x);
    Öö Tiib, Mar 22, 2013
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    7
    Views:
    3,204
    James Kanze
    Feb 12, 2008
  2. James Kanze
    Replies:
    15
    Views:
    305
    Öö Tiib
    Mar 24, 2013
  3. Howard Hinnant
    Replies:
    4
    Views:
    179
    88888 Dihedral
    Mar 22, 2013
  4. Krishnan Shankar

    List getting extended when assigned to itself

    Krishnan Shankar, Aug 25, 2013, in forum: Python
    Replies:
    1
    Views:
    104
    Steven D'Aprano
    Aug 25, 2013
  5. Benjamin Kaplan
    Replies:
    0
    Views:
    89
    Benjamin Kaplan
    Aug 25, 2013
Loading...

Share This Page