operator = overloading...

Discussion in 'C++' started by Rahul, Dec 20, 2007.

  1. Rahul

    Rahul Guest

    Hi Everyone,

    I was overloading the operator= function as a class member function,

    #include <iostream.h>

    class A
    {
    int value;
    public : A& operator = (const A& ref)
    {
    this->value = ref.value;
    cout<<"in"<<endl;
    return *this;
    }
    A(int value) : value(value)
    {
    }
    A(const A& copy)
    {
    this->value = copy.value;
    cout<<"copy with a value of "<<copy.value<<endl;
    }
    void print()
    {
    cout<<"value is"<<value<<endl;
    }
    };

    int main()
    {
    A obj(0);
    A obj1(10);
    A obj2(20);
    obj.print();
    obj1.print();
    obj2.print();
    obj1 = obj = obj2;
    obj.print();
    obj.print();
    obj2.print();
    }

    It works fine and all objects have a value of 20 as expected...

    Next i changed the return type of the operator = function, like
    so that it returns an object instead of a reference...

    A operator = (const A& ref)
    {
    this->value = ref.value;
    cout<<"in"<<endl;
    return *this;
    }

    And as the object is returned by value, each call to operator= also
    invokes the copy constructor for the temp object, which is again
    passed to the operator= function, and the end result happens to be
    same as with operator= function which returns a reference.

    Is there any thumb rule while overloading operators, when we have
    alternative implementations?

    Thanks in advance!!!
     
    Rahul, Dec 20, 2007
    #1
    1. Advertising

  2. Rahul

    Craig Scott Guest

    On Dec 20, 6:43 pm, Rahul <> wrote:
    > Is there any thumb rule while overloading operators, when we have
    > alternative implementations?


    Yes. Member operators are generally expected to return a reference to
    themselves (at least, that's my undestanding). This provides the
    expected behaviour when chaining operators. For example:

    MyClass a, b, c;
    // Presumably do stuff with c here, then.....
    a = b = c;

    No extra copies are involved when operator=() returns by reference.

    --
    Computational Modeling, CSIRO (CMIS)
    Melbourne, Australia

    Why do you want to return by value from operator=()?
     
    Craig Scott, Dec 20, 2007
    #2
    1. Advertising

  3. Rahul

    Rahul Guest

    On Dec 20, 1:52 pm, Craig Scott <> wrote:
    > On Dec 20, 6:43 pm, Rahul <> wrote:
    >
    > > Is there any thumb rule while overloading operators, when we have
    > > alternative implementations?

    >
    > Yes. Member operators are generally expected to return a reference to
    > themselves (at least, that's my undestanding). This provides the
    > expected behaviour when chaining operators. For example:
    >
    > MyClass a, b, c;
    > // Presumably do stuff with c here, then.....
    > a = b = c;
    >
    > No extra copies are involved when operator=() returns by reference.
    >
    > --
    > Computational Modeling, CSIRO (CMIS)
    > Melbourne, Australia
    >
    > Why do you want to return by value from operator=()?


    But the chaining works even when operator= returns a copy too...
     
    Rahul, Dec 20, 2007
    #3
  4. Rahul

    Kira Yamato Guest

    On 2007-12-20 02:43:29 -0500, Rahul <> said:

    > Hi Everyone,
    >
    > I was overloading the operator= function as a class member function,
    >
    > #include <iostream.h>
    >
    > class A
    > {
    > int value;
    > public : A& operator = (const A& ref)
    > {
    > this->value = ref.value;
    > cout<<"in"<<endl;
    > return *this;
    > }
    > A(int value) : value(value)
    > {
    > }
    > A(const A& copy)
    > {
    > this->value = copy.value;
    > cout<<"copy with a value of "<<copy.value<<endl;
    > }
    > void print()
    > {
    > cout<<"value is"<<value<<endl;
    > }
    > };
    >
    > int main()
    > {
    > A obj(0);
    > A obj1(10);
    > A obj2(20);
    > obj.print();
    > obj1.print();
    > obj2.print();
    > obj1 = obj = obj2;
    > obj.print();
    > obj.print();
    > obj2.print();
    > }
    >
    > It works fine and all objects have a value of 20 as expected...
    >
    > Next i changed the return type of the operator = function, like
    > so that it returns an object instead of a reference...
    >
    > A operator = (const A& ref)
    > {
    > this->value = ref.value;
    > cout<<"in"<<endl;
    > return *this;
    > }
    >
    > And as the object is returned by value, each call to operator= also
    > invokes the copy constructor for the temp object, which is again
    > passed to the operator= function, and the end result happens to be
    > same as with operator= function which returns a reference.
    >
    > Is there any thumb rule while overloading operators, when we have
    > alternative implementations?
    >
    > Thanks in advance!!!


    I can't see any legitimate situation where you would prefer to return a
    value instead of a reference here.

    So, I would say, between those two options, always choose return by
    reference since it avoids a copy constructor invocation.

    --

    -kira
     
    Kira Yamato, Dec 20, 2007
    #4
  5. Rahul

    James Kanze Guest

    On Dec 20, 10:40 am, Kira Yamato <> wrote:
    > On 2007-12-20 02:43:29 -0500, Rahul <> said:


    [...]
    > > Is there any thumb rule while overloading operators, when we
    > > have alternative implementations?


    > > Thanks in advance!!!


    > I can't see any legitimate situation where you would prefer to
    > return a value instead of a reference here.


    > So, I would say, between those two options, always choose
    > return by reference since it avoids a copy constructor
    > invocation.


    The general rule is to be as much like the built-in operators as
    possible. This basically means that if the built-in operator is
    an lvalue, return a reference, and if it is not, return a value.
    Since = (and all of the <op>=) are lvalues, you return a
    reference.

    Note too that if there are implicit conversions to the data
    type, you probably want the operators which don't require an
    lvalue to be non-members.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Dec 20, 2007
    #5
  6. Rahul

    Kira Yamato Guest

    On 2007-12-20 04:49:53 -0500, James Kanze <> said:

    > On Dec 20, 10:40 am, Kira Yamato <> wrote:
    >> On 2007-12-20 02:43:29 -0500, Rahul <> said:

    >
    > [...]
    >>> Is there any thumb rule while overloading operators, when we
    >>> have alternative implementations?

    >
    >>> Thanks in advance!!!

    >
    >> I can't see any legitimate situation where you would prefer to
    >> return a value instead of a reference here.

    >
    >> So, I would say, between those two options, always choose
    >> return by reference since it avoids a copy constructor
    >> invocation.

    >
    > The general rule is to be as much like the built-in operators as
    > possible. This basically means that if the built-in operator is
    > an lvalue, return a reference, and if it is not, return a value.
    > Since = (and all of the <op>=) are lvalues, you return a
    > reference.
    >
    > Note too that if there are implicit conversions to the data
    > type, you probably want the operators which don't require an
    > lvalue to be non-members.


    Can a temporary object be an lvalue? The following code compiles fine
    under g++ 4.0.1:

    int main()
    {
    class T {};
    T() = T();
    return 0;
    }

    --

    -kira
     
    Kira Yamato, Dec 20, 2007
    #6
  7. Rahul

    siddhu Guest

    On Dec 20, 5:53 am, Kira Yamato <> wrote:
    > On 2007-12-20 04:49:53 -0500, James Kanze <> said:
    >
    >
    >
    >
    >
    > > On Dec 20, 10:40 am, Kira Yamato <> wrote:
    > >> On 2007-12-20 02:43:29 -0500, Rahul <> said:

    >
    > > [...]
    > >>> Is there any thumb rule while overloading operators, when we
    > >>> have alternative implementations?

    >
    > >>> Thanks in advance!!!

    >
    > >> I can't see any legitimate situation where you would prefer to
    > >> return a value instead of a reference here.

    >
    > >> So, I would say, between those two options, always choose
    > >> return by reference since it avoids a copy constructor
    > >> invocation.

    >
    > > The general rule is to be as much like the built-in operators as
    > > possible. This basically means that if the built-in operator is
    > > an lvalue, return a reference, and if it is not, return a value.
    > > Since = (and all of the <op>=) are lvalues, you return a
    > > reference.

    >
    > > Note too that if there are implicit conversions to the data
    > > type, you probably want the operators which don't require an
    > > lvalue to be non-members.

    >
    > Can a temporary object be an lvalue? The following code compiles fine
    > under g++ 4.0.1:
    >
    > int main()
    > {
    > class T {};
    > T() = T();
    > return 0;
    >
    > }
    >
    > --
    >
    > -kira- Hide quoted text -
    >
    > - Show quoted text -


    For user defined types temporaries can be lvalue. But its useless. So
    whenever you return by value ,try to return it as const value in order
    to make it consistent with POD types.

    I have a question.

    obj = obj1 = obj2;

    In the above statement what is the order of calling of assignment
    operators? I think standard does not specify any order. please
    clarify.
     
    siddhu, Dec 20, 2007
    #7
  8. siddhu wrote:
    > [..]
    > I have a question.
    >
    > obj = obj1 = obj2;
    >
    > In the above statement what is the order of calling of assignment
    > operators? I think standard does not specify any order. please
    > clarify.


    Yes, it does. Associativity of assignment operators is right-to-left.
    That means the expression is evaluated as if it is written as

    obj = (obj1 = obj2);

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Dec 20, 2007
    #8
  9. Rahul

    siddhu Guest

    On Dec 20, 10:38 am, "Victor Bazarov" <> wrote:
    > siddhu wrote:
    > > [..]
    > > I have a question.

    >
    > > obj = obj1 = obj2;

    >
    > > In the above statement what is the order of calling of assignment
    > > operators? I think standard does not specify any order. please
    > > clarify.

    >
    > Yes, it does. Associativity of assignment operators is right-to-left.
    > That means the expression is evaluated as if it is written as
    >
    > obj = (obj1 = obj2);

    So how does chaining come into play?
    >
    > V
    > --
    > Please remove capital 'A's when replying by e-mail
    > I do not respond to top-posted replies, please don't ask
     
    siddhu, Dec 20, 2007
    #9
  10. Rahul

    Rahul Guest

    On Dec 20, 8:53 pm, siddhu <> wrote:
    > On Dec 20, 10:38 am, "Victor Bazarov" <> wrote:> siddhu wrote:
    > > > [..]
    > > > I have a question.

    >
    > > > obj = obj1 = obj2;

    >
    > > > In the above statement what is the order of calling of assignment
    > > > operators? I think standard does not specify any order. please
    > > > clarify.

    >
    > > Yes, it does. Associativity of assignment operators is right-to-left.
    > > That means the expression is evaluated as if it is written as

    >
    > > obj = (obj1 = obj2);

    >
    > So how does chaining come into play?
    >
    >
    >
    > > V
    > > --
    > > Please remove capital 'A's when replying by e-mail
    > > I do not respond to top-posted replies, please don't ask


    It is as good as saying,
    obj.operator=(obj1.operator=(obj2))
     
    Rahul, Dec 20, 2007
    #10
  11. Rahul

    James Kanze Guest

    On Dec 20, 11:53 am, Kira Yamato <> wrote:
    > On 2007-12-20 04:49:53 -0500, James Kanze
    > <> said:


    > > On Dec 20, 10:40 am, Kira Yamato <> wrote:
    > >> On 2007-12-20 02:43:29 -0500, Rahul <> said:


    > > [...]
    > >>> Is there any thumb rule while overloading operators, when we
    > >>> have alternative implementations?


    > >>> Thanks in advance!!!


    > >> I can't see any legitimate situation where you would prefer to
    > >> return a value instead of a reference here.


    > >> So, I would say, between those two options, always choose
    > >> return by reference since it avoids a copy constructor
    > >> invocation.


    > > The general rule is to be as much like the built-in operators as
    > > possible. This basically means that if the built-in operator is
    > > an lvalue, return a reference, and if it is not, return a value.
    > > Since = (and all of the <op>=) are lvalues, you return a
    > > reference.


    > > Note too that if there are implicit conversions to the data
    > > type, you probably want the operators which don't require an
    > > lvalue to be non-members.


    > Can a temporary object be an lvalue?


    Not normally. The standard doesn't actually make an explicit
    equivalence, but most of the cases listed in §12.2 where a
    temporary comes into existence involve expressions which are
    rvalues.

    > The following code compiles fine under g++ 4.0.1:


    > int main()
    > {
    > class T {};
    > T() = T();
    > return 0;
    > }


    Yes. The reason is that there is no problem calling a member
    function on a temporary, and for class types, operator= is a
    member function.

    To return to my initial point: there is no way to restrict a
    user defined operator to lvalues. By making it a member,
    however, you do prevent conversions: built-in operators
    which require lvalues will not accept the results of
    conversions, and those that do not require lvalues do.

    At least, that's the commonly accepted point of view. On
    thinking about it, however: if you define something like
    operator+= as a non-member (friend), then the first argument
    will be a non-const reference (otherwise you cannot possibly
    give it the semantics it should have). And you can't initialize
    a non-const reference with a temporary. Which would argue for
    making operators requiring an lvalue free functions, and not
    members. (Except for operator=, which for other reasons cannot
    be a free function.)

    Note that the issue is far from moot. Suppose you want an
    iterator to the last element in a container you know is not
    empty, and that has at least a bidirectional iterator (e.g. any
    of the standard sequences). You might be tempted to write:
    -- container.end()
    . If the operator-- function of the iterator is a member (which
    it is in most, if not all, current implementations), this works.
    If it is not (or if the "iterator" is just a typedef for a
    pointer, which was the case in a lot of early implementations of
    std::vector), then it doesn't. (Since the abstraction of STL
    iterators is a pointer, we'd really like for it not to work.)

    So it's worth thinking about, even if the currently accepted
    best practice is as I originally stated: that operators which
    require lvalues be members, and operators that don't be free
    functions. (And of course, when you deviate from currently
    accepted best practices, aka the standard way of doing things,
    you raise questions in your readers' minds. It's better not to
    without very strong reasons.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Dec 21, 2007
    #11
  12. Rahul

    James Kanze Guest

    On Dec 20, 4:31 pm, siddhu <> wrote:
    > On Dec 20, 5:53 am, Kira Yamato <> wrote:


    [...]
    > > Can a temporary object be an lvalue? The following code compiles fine
    > > under g++ 4.0.1:


    > > int main()
    > > {
    > > class T {};
    > > T() = T();
    > > return 0;
    > > }


    > For user defined types temporaries can be lvalue.


    No. For class types, an rvalue is an object: it has an address,
    and a cv-qualified type. (For non-class types, an rvalue does
    not have an address, and the type is always non cv-qualified.
    Although if it results in a temporary, trying to modify it is
    undefined behavior, even if it isn't const.)

    FWIW: at various times, different experts have suggested that
    functions or operators returning class types should declare them
    const, e.g.:
    MyClass const operator+( MyClass const& lhs,
    MyClass const& rhs ) ;
    This would prevent calling non-const functions on them, e.g.
    (a + b) = x ;
    would be illegal, because operator= is a non-const function.
    This recommendation doesn't seem to have caught on, however,
    perhaps because there's no way to make it cover the case in your
    example---there is no way to explicitly create a const
    temporary.

    > But its useless. So whenever you return by value ,try to
    > return it as const value in order to make it consistent with
    > POD types.


    It's still not really consistent, since class type rvalues do
    have different behavior than non-class type rvalues. It's just
    less inconsistent (and abouty the best you can do).

    As I said, you're not the first to recommend this. (I think
    Scott Meyers recommends it as well.) But it doesn't seem to be
    happening.

    > I have a question.


    > obj = obj1 = obj2;


    > In the above statement what is the order of calling of
    > assignment operators? I think standard does not specify any
    > order. please clarify.


    The standard specifies a binding: obj is assigned the results of
    the expression (obj1 = obj2). In the case of user defined types
    (where the operator= is a function, and introduces sequence
    points), this imposes an actual order. In the case of the
    built-in operator=, however, the order in which obj and obj1 are
    modified is not specified (although the value assigned to obj
    must be the value that is assigned to obj1, and not the original
    value of obj2). There is, of course, no way you could tell in a
    standard conforming program, but if you look at the generated
    code, or place watch points in a debugger, you could. (The
    order could also, in theory, be observable in a multithreaded
    environment. But in all the multithreaded environments I know,
    if you haven't serialized all accesses to obj and obj1 by some
    external locking mechanism, then the program has undefined
    behavior anyway.)

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Dec 21, 2007
    #12
  13. Rahul

    Kira Yamato Guest

    On 2007-12-21 04:27:06 -0500, James Kanze <> said:

    > On Dec 20, 11:53 am, Kira Yamato <> wrote:
    >> On 2007-12-20 04:49:53 -0500, James Kanze
    >> <> said:

    >
    >>> On Dec 20, 10:40 am, Kira Yamato <> wrote:
    >>>> On 2007-12-20 02:43:29 -0500, Rahul <> said:

    >
    >>> [...]
    >>>>> Is there any thumb rule while overloading operators, when we
    >>>>> have alternative implementations?

    >
    >>>>> Thanks in advance!!!

    >
    >>>> I can't see any legitimate situation where you would prefer to
    >>>> return a value instead of a reference here.

    >
    >>>> So, I would say, between those two options, always choose
    >>>> return by reference since it avoids a copy constructor
    >>>> invocation.

    >
    >>> The general rule is to be as much like the built-in operators as
    >>> possible. This basically means that if the built-in operator is
    >>> an lvalue, return a reference, and if it is not, return a value.
    >>> Since = (and all of the <op>=) are lvalues, you return a
    >>> reference.

    >
    >>> Note too that if there are implicit conversions to the data
    >>> type, you probably want the operators which don't require an
    >>> lvalue to be non-members.

    >
    >> Can a temporary object be an lvalue?

    >
    > Not normally. The standard doesn't actually make an explicit
    > equivalence, but most of the cases listed in §12.2 where a
    > temporary comes into existence involve expressions which are
    > rvalues.
    >
    >> The following code compiles fine under g++ 4.0.1:

    >
    >> int main()
    >> {
    >> class T {};
    >> T() = T();
    >> return 0;
    >> }

    >
    > Yes. The reason is that there is no problem calling a member
    > function on a temporary, and for class types, operator= is a
    > member function.
    >
    > To return to my initial point: there is no way to restrict a
    > user defined operator to lvalues. By making it a member,
    > however, you do prevent conversions: built-in operators
    > which require lvalues will not accept the results of
    > conversions, and those that do not require lvalues do.
    >
    > At least, that's the commonly accepted point of view. On
    > thinking about it, however: if you define something like
    > operator+= as a non-member (friend), then the first argument
    > will be a non-const reference (otherwise you cannot possibly
    > give it the semantics it should have). And you can't initialize
    > a non-const reference with a temporary. Which would argue for
    > making operators requiring an lvalue free functions, and not
    > members. (Except for operator=, which for other reasons cannot
    > be a free function.)
    >
    > Note that the issue is far from moot. Suppose you want an
    > iterator to the last element in a container you know is not
    > empty, and that has at least a bidirectional iterator (e.g. any
    > of the standard sequences). You might be tempted to write:
    > -- container.end()
    > . If the operator-- function of the iterator is a member (which
    > it is in most, if not all, current implementations), this works.
    > If it is not (or if the "iterator" is just a typedef for a
    > pointer, which was the case in a lot of early implementations of
    > std::vector), then it doesn't. (Since the abstraction of STL
    > iterators is a pointer, we'd really like for it not to work.)
    >
    > So it's worth thinking about, even if the currently accepted
    > best practice is as I originally stated: that operators which
    > require lvalues be members, and operators that don't be free
    > functions. (And of course, when you deviate from currently
    > accepted best practices, aka the standard way of doing things,
    > you raise questions in your readers' minds. It's better not to
    > without very strong reasons.)


    Very interesting read.

    So, this is telling me that we should do things in your suggested way:
    that is, declare operators that should require lvalues be free
    functions and declare its first parameter a non-const reference.

    Well, even if it is not standard practice, I'll start doing that.

    --

    -kira
     
    Kira Yamato, Dec 21, 2007
    #13
    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. John Smith
    Replies:
    2
    Views:
    449
    Ivan Vecerina
    Oct 6, 2004
  2. Replies:
    11
    Views:
    769
    James Kanze
    May 16, 2007
  3. hurcan solter
    Replies:
    3
    Views:
    757
    Cholo Lennon
    Aug 29, 2007
  4. Replies:
    11
    Views:
    587
  5. Replies:
    2
    Views:
    336
Loading...

Share This Page