assignment operator

[subramanian100in]

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.

[Victor Bazarov]

su**************@yahoo.com 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

[James Kanze]

On Apr 19, 3:41 pm, "[e-mail], India"
<[e-mail]:

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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[xperthands]

On Apr 19, 10:06 am, James Kanze <[e-mail]:
<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.

[James Kanze]

On Apr 20, 3:53 am, xperthands <[e-mail]:

On Apr 19, 10:06 am, James Kanze <[e-mail]:
<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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[xperthands]

On Apr 20, 12:41 am, James Kanze <[e-mail]:

On Apr 20, 3:53 am, xperthands <[e-mail]:

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.

[Alf P. Steinbach]

* xperthands:

On Apr 20, 12:41 am, James Kanze <[e-mail]:

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

[James Kanze]

On Apr 22, 6:03 am, xperthands <[e-mail]:

On Apr 20, 12:41 am, James Kanze <[e-mail]:

On Apr 20, 3:53 am, xperthands <[e-mail]:

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: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Old Wolf]

On Apr 20, 5:06 am, James Kanze <[e-mail]:

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

[Jerry Coffin]

In article <11*********************@q75g2000hsh.googlegroups. com>,
ol*****@inspire.net.nz says...

On Apr 20, 5:06 am, James Kanze <[e-mail]:

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.