Re: operator= function
Kira Yamato wrote:
On 2007-12-04 14:56:17 -0500, "Victor Bazarov"
<v.Abazarov@comAcast.net> said:
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
if (a = b) ...
or
bool success = a = b;
if (success)
Yes, I agree that it's not the idiomatic use of the assignment operator.
But it's possible the OP wanted exactly that! I am simply showing how
those things _can_ be done.
Code readability should be
highly sought for.
Sure. Don't name your variables 'a' or 'b'.
Hmm... This is somewhat controversial, but I actually prefer single
letter variable names for local variables. Perhaps this is because of
my math background.
Perhaps.
I would think that in a clean program, most functions should not be
more than 100 lines of code anyway. So, it's ok for local variables
to be single letter and not get lost in just 100 lines of code.
Those two things are orthogonal. The meaning of the object in the
program should *not* have to be deducible from the code in which it
is involved (10 lines or 10000 lines), but from its name!
But I'm not holding my breath on this one.
Good idea.
Even with native data-types like integers, it's
better to write
if (n != 0) ...
than just
if (n) ...
Now, with integers it may make sense. But with a class object
I would have to define non-equality comparison to 'int' in order
for 'if (n != 0)' to compile. OTOH, if I just define operator
bool() (known as type conversion function), both 'int' _and_ my
type would work in 'if (n)' beautifully.
Like I said before, just because you could, should you? For integer
variables, the standard says very clearly what
if (n)
means, but for objects, what can you really tell from the code below
if (my_car_engine)
what it means?
Right, for 'my_car_engine' it probably doesn't mean anything specific.
Now, consider the alternative
if (my_car_engine.isReady()).
This was my point in my last post.
I get your point. However, if it does make sence for 'bool', why
shouldn't you be _able_ to have a wrapper, an object with more than
one state, of which some would be "true" and some "false", when used
in an 'if' statement? Again, you need to be able to think outside
of the car... ahem!.. box.
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.
Yes, that's why some folks define 'operator void*()' instead.
I don't get your point here.
The point is that if you don't want an implicit conversion to 'int'
or any other arithmetic type (that 'bool' provides), use something
that has an explicit conversion to 'bool' instead. Use 'void*'.
Non-null value (like the object's address) would mean 'true', and
a null pointer value would mean 'false'.
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask