assignment operator

Discussion in 'C++' started by subramanian100in@yahoo.com, India, Apr 19, 2007.

  1. , India

    , India Guest

    In C, we can compare(ie apply the equality operators == and != to)
    pointers to elements of the same array only. We cannot compare the
    pointers to different objects of the same type. In C++, consider the
    operator=.

    For a class X,

    X& operator=(const X &ref)
    {
    if (this != &ref)
    {
    ...
    }

    return *this;
    }

    Here we are comparing the pointers to objects of the same type X. But
    they need not belong to the same array. Kindly explain how this is
    allowed.
     
    , India, Apr 19, 2007
    #1
    1. Advertising

  2. wrote:
    > In C, we can compare(ie apply the equality operators == and != to)
    > pointers to elements of the same array only.


    OK, I didn't know that there was a restriction on the equality ops.
    IIRC, there was only the restriction for comparison ops (< > <= >=).

    > We cannot compare the
    > pointers to different objects of the same type. In C++, consider the
    > operator=.
    >
    > For a class X,
    >
    > X& operator=(const X &ref)
    > {
    > if (this != &ref)
    > {
    > ...
    > }
    >
    > return *this;
    > }
    >
    > Here we are comparing the pointers to objects of the same type X. But
    > they need not belong to the same array. Kindly explain how this is
    > allowed.


    Pointers are allowed to be compared for equality regardless of the
    objects' belonging to the same array. The restriction exists for the
    use of comparison operators (< > <= >=). Those can only be used to
    _compare_ pointers to elements of the same array or members of the
    same object.

    Consider this: you compare pointers to 0 (or to a null pointer) all
    the time, right? A null pointer is not a pointer to any object, yet
    you have no problem comparing a pointer to any other object to it.

    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, Apr 19, 2007
    #2
    1. Advertising

  3. , India

    James Kanze Guest

    On Apr 19, 3:41 pm, ", India"
    <> wrote:
    > In C, we can compare(ie apply the equality operators == and != to)
    > pointers to elements of the same array only.


    Since when? This restriction isn't present in C99, and it
    certainly wasn't present in earlier versions. As far as I know,
    C and C++ use exactly the same rules with regards to pointer
    comparison.

    > We cannot compare the
    > pointers to different objects of the same type. In C++, consider the
    > operator=.


    > For a class X,


    > X& operator=(const X &ref)
    > {
    > if (this != &ref)


    This is a red flag: if a test for self assignment is necessary,
    9 times out of 10, the assignment operator is broken.

    > {
    > ...
    > }
    > return *this;
    > }


    > Here we are comparing the pointers to objects of the same type X. But
    > they need not belong to the same array. Kindly explain how this is
    > allowed.


    Kindly explain why you think it's not allowed.

    --
    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, Apr 19, 2007
    #3
  4. , India

    xperthands Guest

    On Apr 19, 10:06 am, James Kanze <> wrote:
    <snip>
    > > X& operator=(const X &ref)
    > > {
    > > if (this != &ref)

    >
    > This is a red flag: if a test for self assignment is necessary,
    > 9 times out of 10, the assignment operator is broken.


    I have a couple of problems with this "rule of thumb":

    1) That it is a bit of an overstatement. It would only be broken in
    the sense of
    exception-safety. Those concerns are not universal.

    2) You may use the comparison for performance reasons, not for
    correct
    behavior.
     
    xperthands, Apr 20, 2007
    #4
  5. , India

    James Kanze Guest

    On Apr 20, 3:53 am, xperthands <> wrote:
    > On Apr 19, 10:06 am, James Kanze <> wrote:
    > <snip>


    > > > X& operator=(const X &ref)
    > > > {
    > > > if (this != &ref)


    > > This is a red flag: if a test for self assignment is necessary,
    > > 9 times out of 10, the assignment operator is broken.


    > I have a couple of problems with this "rule of thumb":
    >
    > 1) That it is a bit of an overstatement. It would only be broken in
    > the sense of
    > exception-safety. Those concerns are not universal.


    In what sense: that the concern for writing correct code is not
    universal? If the class consists of only primitive types, which
    cannot throw, then there's no need for the test; some would
    argue that there's no need for the user defined operator= to
    begin with.

    > 2) You may use the comparison for performance reasons, not for
    > correct
    > behavior.


    Bullshit. It could only improve performance if most assigns
    were self assigns; if not assigning to self, it slows things
    down (slightly).

    The fact remains that when looking at foreign code, a test for
    self assignment is a red flag that the operator= is broken.

    --
    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, Apr 20, 2007
    #5
  6. , India

    xperthands Guest

    On Apr 20, 12:41 am, James Kanze <> wrote:
    > On Apr 20, 3:53 am, xperthands <> wrote:
    >
    > > 1) That it is a bit of an overstatement. It would only be broken in
    > > the sense of
    > > exception-safety. Those concerns are not universal.

    >
    > In what sense: that the concern for writing correct code is not
    > universal? If the class consists of only primitive types, which
    > cannot throw, then there's no need for the test; some would
    > argue that there's no need for the user defined operator= to
    > begin with.


    Your overstating again. Your class may be composed of non-
    primitives that also have nothrow guarantees. primitives are not
    the only types that fit that.

    > Bullshit.


    I know you're a moderator, but such rude language is
    offensive. I should think that moderators would be held
    to a higher standard.

    > It could only improve performance if most assigns
    > were self assigns; if not assigning to self, it slows things
    > down (slightly).


    Again, your knowledge of the use of the type can make
    the world of difference. Which was indeed my point.

    > The fact remains that when looking at foreign code, a test for
    > self assignment is a red flag that the operator= is broken.


    I still disagree with that it is necessarily broken. I also use
    that as a sign to look more deeply at the class and the
    assignment operator, but when doing a code review, I try
    not to jump to conclusions. That can introduce
    unnecessary tension into the process. That tenson can
    lead to problems in your review process.
     
    xperthands, Apr 22, 2007
    #6
  7. * xperthands:
    > On Apr 20, 12:41 am, James Kanze <> wrote:
    >
    >> Bullshit.

    >
    > I know you're a moderator, but such rude language is
    > offensive. I should think that moderators would be held
    > to a higher standard.


    I disagree with James on the technical issue, that the statement to
    which he replied was bullshit (that doesn't necessarily mean I agree
    with you, but I certainly disagree with James here), but, /if/ I'd
    agreed with James' reasoning, I may have used the same word.

    We shouldn't be afraid to use what we think are accurate labels, short
    concise language, just because someone might be offended.

    It would be quite another matter to characterize a person, as opposed to
    a statement, that way.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Apr 22, 2007
    #7
  8. , India

    James Kanze Guest

    On Apr 22, 6:03 am, xperthands <> wrote:
    > On Apr 20, 12:41 am, James Kanze <> wrote:


    > > On Apr 20, 3:53 am, xperthands <> wrote:


    > > > 1) That it is a bit of an overstatement. It would only be broken in
    > > > the sense of
    > > > exception-safety. Those concerns are not universal.


    > > In what sense: that the concern for writing correct code is not
    > > universal? If the class consists of only primitive types, which
    > > cannot throw, then there's no need for the test; some would
    > > argue that there's no need for the user defined operator= to
    > > begin with.


    > Your overstating again. Your class may be composed of non-
    > primitives that also have nothrow guarantees. primitives are not
    > the only types that fit that.


    I'm still waiting for an example of a class where such a test
    would be appropriate. As I said, it's a red flag---when I see
    it, I get very suspicious. To date, my suspicions have always
    been confirmed.

    > > Bullshit.


    > I know you're a moderator, but such rude language is
    > offensive. I should think that moderators would be held
    > to a higher standard.


    This isn't a moderated group. And the comment applies to your
    statement, not to you. While I might have used a more
    politically correct word in a moderated group, I wouldn't
    participate in a group where I couldn't say the equivalent in
    some way or another. I find it essential to be able to
    criticize statements. (Fundamentally, except for the level of
    language, what is the difference between "bullshit", and what
    you said about my statements. Both are, IMHO, comments about
    what was said, and not the person.)

    And I'll admit that I'm letting myself go a bit. admit In a
    newgroup, where you don't know the sensibilities of your
    interlocutors, it's probably better to err on the side of
    caution, and to avoid such language. Sometimes, however, it
    feels good to just let off steam, especially after having been
    bottled up for so long.

    > > It could only improve performance if most assigns
    > > were self assigns; if not assigning to self, it slows things
    > > down (slightly).


    > Again, your knowledge of the use of the type can make
    > the world of difference. Which was indeed my point.


    > > The fact remains that when looking at foreign code, a test for
    > > self assignment is a red flag that the operator= is broken.


    > I still disagree with that it is necessarily broken.


    Saying that something is a red flag doesn't mean that it is
    necessarily broken. It does say that most of the time the idiom
    is used, it is mistakenly, and that when I see it, I start
    checking, because I've seen it used so often mistakenly.

    And as I said, I've never seen a case where it was necessary, if
    the operator was otherwise correct.

    > I also use that as a sign to look more deeply at the class and
    > the assignment operator, but when doing a code review, I try
    > not to jump to conclusions. That can introduce unnecessary
    > tension into the process. That tension can lead to problems in
    > your review process.


    OK. Then we're really in agreement, just expressing ourselves
    differently. At least in the English I know, a "red flag" means
    a signal to look closer. Just as obviously, in code review, I
    will adjust the tone of my comments to the people present---some
    people are more sensitive than others, and my presentation will
    take that into account. And I've been in code reviews where I
    could say that something was bullshit; it all depends on the
    personality of the person involved. (Depending on the people
    involved and the context, informal language can sometimes serve
    to break down tension, as well as to create it.)

    --
    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, Apr 22, 2007
    #8
  9. , India

    Old Wolf Guest

    On Apr 20, 5:06 am, James Kanze <> wrote:
    >
    > Since when? This restriction isn't present in C99, and it
    > certainly wasn't present in earlier versions. As far as I know,
    > C and C++ use exactly the same rules with regards to pointer
    > comparison.


    The rules are the same for equality comparisons (namely, it is
    always allowed). The rules for relational comparisons are different;
    in C it is undefined behaviour if the pointers do not point to parts
    of the same object (or one past the end), but in C++ it is
    unspecified.
     
    Old Wolf, Apr 22, 2007
    #9
  10. , India

    Jerry Coffin Guest

    In article <>,
    says...
    > On Apr 20, 5:06 am, James Kanze <> wrote:
    > >
    > > Since when? This restriction isn't present in C99, and it
    > > certainly wasn't present in earlier versions. As far as I know,
    > > C and C++ use exactly the same rules with regards to pointer
    > > comparison.

    >
    > The rules are the same for equality comparisons (namely, it is
    > always allowed). The rules for relational comparisons are different;
    > in C it is undefined behaviour if the pointers do not point to parts
    > of the same object (or one past the end), but in C++ it is
    > unspecified.


    It's also worth mentioning that std::less gives (loosely) specified
    results even when the operators don't.

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
     
    Jerry Coffin, Apr 23, 2007
    #10
    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. Wolfgang Groiss
    Replies:
    0
    Views:
    400
    Wolfgang Groiss
    Nov 19, 2003
  2. nagy
    Replies:
    36
    Views:
    1,014
    Terry Reedy
    Jul 20, 2006
  3. G Patel

    comma operator and assignment operator

    G Patel, Feb 7, 2005, in forum: C Programming
    Replies:
    4
    Views:
    492
    Barry Schwarz
    Feb 8, 2005
  4. Chris
    Replies:
    34
    Views:
    1,529
  5. Hicham Mouline
    Replies:
    2
    Views:
    699
    Juha Nieminen
    Sep 1, 2009
Loading...

Share This Page