Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > assignment operator

Reply
Thread Tools

assignment operator

 
 
subramanian100in@yahoo.com, India
Guest
Posts: n/a
 
      04-19-2007
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.

 
Reply With Quote
 
 
 
 
Victor Bazarov
Guest
Posts: n/a
 
      04-19-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) 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


 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      04-19-2007
On Apr 19, 3:41 pm, "(E-Mail Removed), India"
<(E-Mail Removed)> 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:(E-Mail Removed)
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


 
Reply With Quote
 
xperthands
Guest
Posts: n/a
 
      04-20-2007
On Apr 19, 10:06 am, James Kanze <(E-Mail Removed)> 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.

 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      04-20-2007
On Apr 20, 3:53 am, xperthands <(E-Mail Removed)> wrote:
> On Apr 19, 10:06 am, James Kanze <(E-Mail Removed)> 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:(E-Mail Removed)
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

 
Reply With Quote
 
xperthands
Guest
Posts: n/a
 
      04-22-2007
On Apr 20, 12:41 am, James Kanze <(E-Mail Removed)> wrote:
> On Apr 20, 3:53 am, xperthands <(E-Mail Removed)> 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.

 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      04-22-2007
* xperthands:
> On Apr 20, 12:41 am, James Kanze <(E-Mail Removed)> 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?
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      04-22-2007
On Apr 22, 6:03 am, xperthands <(E-Mail Removed)> wrote:
> On Apr 20, 12:41 am, James Kanze <(E-Mail Removed)> wrote:


> > On Apr 20, 3:53 am, xperthands <(E-Mail Removed)> 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: (E-Mail Removed)
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

 
Reply With Quote
 
Old Wolf
Guest
Posts: n/a
 
      04-22-2007
On Apr 20, 5:06 am, James Kanze <(E-Mail Removed)> 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.

 
Reply With Quote
 
Jerry Coffin
Guest
Posts: n/a
 
      04-23-2007
In article <(E-Mail Removed). com>,
(E-Mail Removed) says...
> On Apr 20, 5:06 am, James Kanze <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
POD and assignment operator and test operator Hicham Mouline C++ 2 09-01-2009 06:00 PM
conditions for automatic generation of default ctor, copy ctor,and default assignment operator (operator) puzzlecracker C++ 8 04-15-2008 09:56 PM
Assignment operator self-assignment check Chris C++ 34 09-26-2006 04:26 AM
Augument assignment versus regular assignment nagy Python 36 07-20-2006 07:24 PM
comma operator and assignment operator G Patel C Programming 4 02-08-2005 02:53 AM



Advertisments