operator= function

[Rahul]

Hi Everyone,

I was just overloading operator = for a class and i have a problem in
one case...

class A
{
A& operator=(const A& obj)
{
return *this;
// please ignore the logic of this function
}
};

int main()
{
A a,b
a = b; //works fine
if(a=b) // causes compile time error as the operator=() returns a
reference to A and not a BOOL.
{
printf("both the objects are the same\n");
}
else
{
printf("both the objects are different\n");
}
}
return(0);
}

Now, i tried to overload operator=() function, but overloading just
based on the return type doesn't make sense.
So is there anyway to solve this problem, so that the user of the
class can get to work in both the cases just like any built in type?

Thanks in advance!!!

[Victor Bazarov]

Re: operator= function

Rahul wrote:

Hi Everyone,
>
I was just overloading operator = for a class and i have a problem in
one case...
>
class A
{
A& operator=(const A& obj)
{
return *this;
// please ignore the logic of this function
}
};
>
int main()
{
A a,b
a = b; //works fine
if(a=b) // causes compile time error as the operator=() returns a
reference to A and not a BOOL.
{
printf("both the objects are the same\n");
}
else
{
printf("both the objects are different\n");
}
}
return(0);
}
>
Now, i tried to overload operator=() function, but overloading just
based on the return type doesn't make sense.
So is there anyway to solve this problem, so that the user of the
class can get to work in both the cases just like any built in type?

A simple way would be to *also* provide a conversion function to type
'bool' in your 'A' class:

class A {
...
operator bool() const { return true; }
};

Or any other conversion function that yields a type that can be used
in a logical expression.

Now, let me ask you, why do you think you need assignment in the 'if'
expression

if (a = b)

instead of comparison

if (a == b)

? Or did you not know that those are two different operators?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Rahul]

Re: operator= function

On Dec 4, 8:46 pm, "Victor Bazarov" <v.Abaza...@com Acast.netwrote:

Rahul wrote:

Hi Everyone,

>

I was just overloading operator = for a class and i have a problem in
one case...

>

class A
{
A& operator=(const A& obj)
{
return *this;
// please ignore the logic of this function
}
};

>

int main()
{
A a,b
a = b; //works fine
if(a=b) // causes compile time error as the operator=() returns a
reference to A and not a BOOL.
{
printf("both the objects are the same\n");
}
else
{
printf("both the objects are different\n");
}
}
return(0);
}

>

Now, i tried to overload operator=() function, but overloading just
based on the return type doesn't make sense.
So is there anyway to solve this problem, so that the user of the
class can get to work in both the cases just like any built in type?

>
A simple way would be to *also* provide a conversion function to type
'bool' in your 'A' class:
>
class A {
...
operator bool() const { return true; }
};
>
Or any other conversion function that yields a type that can be used
in a logical expression.
>
Now, let me ask you, why do you think you need assignment in the 'if'
expression
>
if (a = b)
>
instead of comparison
>
if (a == b)
>
? Or did you not know that those are two different operators?
>

Yes i do. My point is to extend the support provided by c++ for
built-in types to custom types.
int a,b;
a=b; //works fine
if(a=b) // too works fine depending on the value of a.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Tadeusz B. Kopec]

Re: operator= function

On Tue, 04 Dec 2007 07:41:52 -0800, Rahul wrote:

Hi Everyone,
>
I was just overloading operator = for a class and i have a problem in
one case...
>
class A
{
A& operator=(const A& obj)
{
return *this;
// please ignore the logic of this function
}
};
>
int main()
{
A a,b
a = b; //works fine
if(a=b) // causes compile time error as the operator=() returns a
reference to A and not a BOOL.
{
printf("both the objects are the same\n");
}
else
{
printf("both the objects are different\n");
}
}
return(0);
}
>
Now, i tried to overload operator=() function, but overloading just
based on the return type doesn't make sense. So is there anyway to solve
this problem, so that the user of the class can get to work in both the
cases just like any built in type?

First of all - for integer types statement
if (a=b)
tests if b is zero, not if a and b are the same (after executing this
they are for sure the same).
Second - possibility of assignment in 'if' expression is rather a
misfeature and I don't see any point in extending this possibility.

--
Tadeusz B. Kopec (tkopec@NOSPAMP LEASElife.pl)
How many "coming men" has one known! Where on earth do they all go to?
-- Sir Arthur Wing Pinero

[GArlington]

Re: operator= function

On Dec 4, 4:06 pm, Rahul <sam_...@yahoo. co.inwrote:

On Dec 4, 8:46 pm, "Victor Bazarov" <v.Abaza...@com Acast.netwrote:
>
>
>

Rahul wrote:

Hi Everyone,

>

I was just overloading operator = for a class and i have a problem in
one case...

>

class A
{
A& operator=(const A& obj)
{
return *this;
// please ignore the logic of this function
}
};

>

int main()
{
A a,b
a = b; //works fine
if(a=b) // causes compile time error as the operator=() returns a
reference to A and not a BOOL.
{
printf("both the objects are the same\n");
}
else
{
printf("both the objects are different\n");
}
}
return(0);
}

>

Now, i tried to overload operator=() function, but overloading just
based on the return type doesn't make sense.
So is there anyway to solve this problem, so that the user of the
class can get to work in both the cases just like any built in type?

>

A simple way would be to *also* provide a conversion function to type
'bool' in your 'A' class:

>

class A {
...
operator bool() const { return true; }
};

>

Or any other conversion function that yields a type that can be used
in a logical expression.

>

Now, let me ask you, why do you think you need assignment in the 'if'
expression

>

if (a = b)

>

instead of comparison

>

if (a == b)

>

? Or did you not know that those are two different operators?

>
Yes i do. My point is to extend the support provided by c++ for
built-in types to custom types.
int a,b;
a=b; //works fine
if(a=b) // too works fine depending on the value of a.
>

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

if() expects boolean value (or int at least), a=b (assignment) returns
new value of a (equals to b) - the chances of this being boolean or
int are not too good considering the number of different data types
AND objects.

So, what was your question?

If you are overloading the = (assignment) operator, what do you expect
it to return? And how do you expect this return value to be converted
to boolean? And why in hell do you want to overload = operator, unless
you want to clone the object?
So, maybe you ARE trying to overload == (compare) operator after all?

[David Harmon]

Re: operator= function

On Tue, 4 Dec 2007 08:06:48 -0800 (PST) in comp.lang.c++, Rahul
<sam_cit@yahoo. co.inwrote,

Yes i do. My point is to extend the support provided by c++ for
>built-in types to custom types.
int a,b;
a=b; //works fine
if(a=b) // too works fine depending on the value of a.

You should never write an assignment in an if statement. Write it
as
a=b;
if (a) ...

Now, what do you think if(a) should mean, when a is some complex
class you have defined?

>

[Kira Yamato]

Re: operator= function

On 2007-12-04 11:06:48 -0500, Rahul <sam_cit@yahoo. co.insaid:

On Dec 4, 8:46 pm, "Victor Bazarov" <v.Abaza...@com Acast.netwrote:

>Rahul wrote:

>>Hi Everyone,

>>

>>I was just overloading operator = for a class and i have a problem in
>>one case...

>>

>>class A
>>{
>>A& operator=(const A& obj)
>>{
>>return *this;
>>// please ignore the logic of this function
>>}
>>};

>>

>>int main()
>>{
>>A a,b
>>a = b; //works fine
>>if(a=b) // causes compile time error as the operator=() returns a
>>reference to A and not a BOOL.
>>{
>>printf("bot h the objects are the same\n");
>>}
>>else
>>{
>>printf("bot h the objects are different\n");
>>}
>>}
>>return(0);
>>}

>>

>>Now, i tried to overload operator=() function, but overloading just
>>based on the return type doesn't make sense.
>>So is there anyway to solve this problem, so that the user of the
>>class can get to work in both the cases just like any built in type?

>>
>A simple way would be to *also* provide a conversion function to type
>'bool' in your 'A' class:
>>
>class A {
>...
>operator bool() const { return true; }
>};
>>
>Or any other conversion function that yields a type that can be used
>in a logical expression.
>>
>Now, let me ask you, why do you think you need assignment in the 'if'
>expression
>>
>if (a = b)
>>
>instead of comparison
>>
>if (a == b)
>>
>? Or did you not know that those are two different operators?
>>

>
Yes i do. My point is to extend the support provided by c++ for
built-in types to custom types.
int a,b;
a=b; //works fine
if(a=b) // too works fine depending on the value of a.

May not be a good idea. The syntax

if (a)
{
// do something
}

is not clear what you're testing for here. Code readability should be
highly sought for. Even with native data-types like integers, it's
better to write

if (n != 0) ...

than just

if (n) ...

unless you worry about performance, at which I would think a smart
compiler would generate equivalent codes for both cases anyway.

Also, don't overload the operator bool() just to support the if-test.
You might get yourself into trouble in other situations with this
implicit conversion.

My suggestion is to be explicit and have an method like
bool isValid() const;
so that your if statement reads more explicitly

if ((a=b).isValid( )) ...

--

-kira

[James Kanze]

Re: operator= function

On Dec 4, 5:06 pm, Rahul <sam_...@yahoo. co.inwrote:

Yes i do. My point is to extend the support provided by c++ for
built-in types to custom types.
int a,b;
a=b; //works fine
if(a=b) // too works fine depending on the value of a.

For what definition of "works"? For historical reasons, it's
formally legal (although there have been proposals to deprecate
it). It's only intentional use in real code is obfuscation,
however, and good compilers will generally warn if you do it.
the correct way of writing this is in two statements:

a = b ;
if ( a != 0 ) { /* ... */ }

Add the necessary == and != operators to your class, and this
will work.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[James Kanze]

Re: operator= function

On Dec 4, 8:44 pm, Kira Yamato <kira...@earthl ink.netwrote:

On 2007-12-04 11:06:48 -0500, Rahul <sam_...@yahoo. co.insaid:

[...]

is not clear what you're testing for here. Code readability
should be highly sought for. Even with native data-types like
integers, it's better to write

if (n != 0) ...

than just

if (n) ...

Support for the "if (n)" notation is really just a historical
abherition. Originally, C didn't have a boolean type; you had
to simulate it with int. And of course, "if ( n )" *is* the
correct way to write a test of a boolean variable.

When bool was added to C++, the original proposal was also to
deprecate the implicit conversions of int to bool. In the end,
this was dropped, because it was felt that it would break way
too much code.

unless you worry about performance, at which I would think a
smart compiler would generate equivalent codes for both cases
anyway.

Even a dumb compiler. Even before bool, the compiler needs some
sort of boolean value to make a binary test. Internally, you
generally cannot simply make a conditional jump on an integral
value. (This wasn't necessarily true for older processors.)
The result is that if an expression is used in a boolean
context, and the top node is not a comparison (which sets the
processor's condition codes), the compiler inserts a node with
the comparison. Whether you write "if ( n )" or "if ( n != 0
)", the expression trees used to generate the code are normally
identical.

Also, don't overload the operator bool() just to support the
if-test. You might get yourself into trouble in other
situations with this implicit conversion.

My suggestion is to be explicit and have an method like
bool isValid() const;
so that your if statement reads more explicitly

if ((a=b).isValid( )) ...

Don't do that either. With very few exceptions, a single
statement should to one, and only one thing, if you want your
code to be readable. An if statement is flow control, and so
shouldn't modify state.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[Rolf Magnus]

Re: operator= function

Victor Bazarov wrote:

>Also, don't overload the operator bool() just to support the if-test.
>You might get yourself into trouble in other situations with this
>implicit conversion.

>
Yes, that's why some folks define 'operator void*()' instead.

So that things like:

int i = std::cout + 3;

don't work, since it would be so dangerous if it did...

>My suggestion is to be explicit and have an method like
> bool isValid() const;
>so that your if statement reads more explicitly
>>
>if ((a=b).isValid( )) ...

>
Ouch. I still think that even
>
if (a=b, a.isValid())
>
is better. But nothing beats
>
a = b;
if (a.isValid())

As long as you want a to exist outside the if scope.

if (MyType a = somefunc())
{
}

I sometimes use that when I need to use dynamic_cast to handle things
differently based on the dynamic type (Using some external libraries that
give me no other choice):

BaseClass* base = somefunc();
// ...
if (Derived1* d1 = dynamic_cast<De rived1*>(base))
{
// do something
}
else if (Derived2* d2 = dynamic_cast<De rived2*>(base))
{
// do something else
}

vs:

BaseClass* base = somefunc();
// ...
Derived1* d1 = dynamic_cast<De rived1*>(base);
if (d1 != 0)
{
// do something
}
else
{
Derived1* d2 = dynamic_cast<De rived2*>(base);
if (d2 != 0)
{
// do something else
}
}

If you have a loop, you might even need to duplicate things:

while (MyType a = somefunc())
{
// do something with a
}

vs:

MyType a = somefunc();
while (a)
{
a = somefunc();
// do something with a
}

I consider the first variant more readable.

[terminator]

Re: operator= function

On Dec 4, 11:53 pm, "Victor Bazarov" <v.Abaza...@com Acast.netwrote:

Kira Yamato wrote:

On 2007-12-04 14:56:17 -0500, "Victor Bazarov"
<v.Abaza...@com Acast.netsaid:

Kira Yamato wrote:
>[..] The syntax

>

>if (a)
>{
>// do something
>}

>

>is not clear what you're testing for here.

>

Of course not! Who in their right mind would name a variable 'a'?
But imagine that the variable is 'statusIsValid' (and its type is not
necessarily 'bool'). What prevents me from writing

>

if (statusIsValid)
{
// do something
}

>

?

>

I was speaking from the OP's context. He's not likely to be using a
boolean flag. Instead, he's using some object of some class which he
also wants to test as a boolean also. He is trying to copy the
situation with the native type like the 'int'.

>

His code, which you ripped completely out so that the context is
gone, was
class A
{
A& operator=(const A& obj)
{
return *this;
// please ignore the logic of this function
}
};

>

int main()
{
A a,b
a = b; //works fine
if(a=b) // causes compile time error as the operator=() returns a
reference to A and not a BOOL.
{
printf("both the objects are the same\n");
}
else
{
printf("both the objects are different\n");
}
}
return(0);
}

>

This is a bad idea on at least a couple of level.

>

First, the statement
if (a=b)
looks suspiciously a typo to
if (a==b).
Second,
if (someobject)
is never explicit in what you are trying to test for about the object.
In the case of 'int', it is tolerated because it is stipulated in the
standard what that means. But for a user-defined class, the meaning
is not obvious from that if statement alone.

>

This is what I was talking about.

>
Now, you ripped my code completely out and jerked us back to the OP's
example which doesn't really present _any_ context simply because there
is no design intent recognisable in it. It's OK, I'll try to gently
nudge us back to the discussion on merits of the original syntax.
>
Imagine (and that will require you to think outside the box, I *am*
holding my breath for this one) that the OP wants to check the success
of the assignment operation. The OP could then define
>
class A {
bool operator=(const A& other);
};
>
so that the assignment could be either checked

you will lose the ability to chain:

{
int a, b, c;
a=b=c;//ok
}{
A a, b, c;
a=b=c;//error
}

I prefere a conversion operator to an intrinsic type ,or at least a
checker function like 'auto_ptr::get' or 'some_STL_conta iner::empty'.

regards,
FM.

[terminator]

Re: operator= function

On Dec 5, 7:06 pm, Rolf Magnus <ramag...@t-online.dewrote:

Victor Bazarov wrote:

Also, don't overload the operator bool() just to support the if-test.
You might get yourself into trouble in other situations with this
implicit conversion.

>

Yes, that's why some folks define 'operator void*()' instead.

>
So that things like:
>
int i = std::cout + 3;
>
don't work, since it would be so dangerous if it did...
>

My suggestion is to be explicit and have an method like
bool isValid() const;
so that your if statement reads more explicitly

>

if ((a=b).isValid( )) ...

>

Ouch. I still think that even

>

if (a=b, a.isValid())

>

is better. But nothing beats

>

a = b;
if (a.isValid())

>
As long as you want a to exist outside the if scope.
>
if (MyType a = somefunc())
{
>
}
>
I sometimes use that when I need to use dynamic_cast to handle things
differently based on the dynamic type (Using some external libraries that
give me no other choice):
>
BaseClass* base = somefunc();
// ...
if (Derived1* d1 = dynamic_cast<De rived1*>(base))
{
// do something}
>
else if (Derived2* d2 = dynamic_cast<De rived2*>(base))
{
// do something else
>
}
>
vs:
>
BaseClass* base = somefunc();
// ...
Derived1* d1 = dynamic_cast<De rived1*>(base);
if (d1 != 0)
{
// do something}
>
else
{
Derived1* d2 = dynamic_cast<De rived2*>(base);
if (d2 != 0)
{
// do something else
}
>
}
>
If you have a loop, you might even need to duplicate things:
>
while (MyType a = somefunc())
{
// do something with a
>
}
>
vs:
>
MyType a = somefunc();
while (a)
{
a = somefunc();
// do something with a
>
}
>
I consider the first variant more readable.

enclosing the loop/conditional statement in an extra pair of braces
gives similar functionality(I do not discuss readabilty for now):

{//extra braces
class X* xptr=whatever;
while (xptr){
....
};
};

regards,
FM.

[Victor Bazarov]

Re: operator= function

terminator wrote:

On Dec 4, 11:53 pm, "Victor Bazarov" <v.Abaza...@com Acast.netwrote:

>[..]
>Imagine (and that will require you to think outside the box, I *am*
>holding my breath for this one) that the OP wants to check the
>success of the assignment operation. The OP could then define
>>
> class A {
> bool operator=(const A& other);
> };
>>
>so that the assignment could be either checked

>
you will lose the ability to chain:
>
{
int a, b, c;
a=b=c;//ok
}{
A a, b, c;
a=b=c;//error
}

Chaining is not necessarily a good idea. Neither is the assignment
operator that can fail, of course. In that case it would probably
be best to have a member function that would return 'bool'.

I prefere a conversion operator to an intrinsic type ,or at least a
checker function like 'auto_ptr::get' or 'some_STL_conta iner::empty'.

Well, as we discussed elsethread, conversion to an integral type may
not be the right choice, but conversion to 'void*' could work (like
it does for streams).

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]

Re: operator= function

On Dec 5, 5:06 pm, Rolf Magnus <ramag...@t-online.dewrote:

Victor Bazarov wrote:

[...]

if ((a=b).isValid( )) ...

Ouch. I still think that even

if (a=b, a.isValid())

is better. But nothing beats

a = b;
if (a.isValid())

As long as you want a to exist outside the if scope.

I'd say that if it matters, your function is too big.

if (MyType a = somefunc())
{
}

I sometimes use that when I need to use dynamic_cast to handle
things differently based on the dynamic type (Using some
external libraries that give me no other choice):

BaseClass* base = somefunc();
// ...
if (Derived1* d1 = dynamic_cast<De rived1*>(base))
{
// do something}
>
else if (Derived2* d2 = dynamic_cast<De rived2*>(base))
{
// do something else

You mean, something like:

d1->xxx ;

You might as well move the declaration out of the if, so that
it's readable.

(If I had to chain the tests, of course, I'd probably put each
case in a separate function, with its test.)

}

vs:

BaseClass* base = somefunc();
// ...
Derived1* d1 = dynamic_cast<De rived1*>(base);
if (d1 != 0)
{
// do something}
>
else
{
Derived1* d2 = dynamic_cast<De rived2*>(base);
if (d2 != 0)
{
// do something else
>
}

If you have a loop, you might even need to duplicate things:

while (MyType a = somefunc())
{
// do something with a
}

vs:

MyType a = somefunc();
while (a)
{
a = somefunc();
// do something with a
}

I consider the first variant more readable.

No way. It hides an important change of state (and declaration)
in the middle of a condition.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[James Kanze]

Re: operator= function

On Dec 5, 10:31 pm, terminator <farid.mehr...@ gmail.comwrote:

On Dec 5, 7:06 pm, Rolf Magnus <ramag...@t-online.dewrote:

[...]

enclosing the loop/conditional statement in an extra pair of braces
gives similar functionality(I do not discuss readabilty for now):

{//extra braces
class X* xptr=whatever;
while (xptr){
....
};
};

And writing clean code, without outlandishly long functions,
eliminates the need for the functionality completely.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34