WHich one is evaluated first

[HochiminhCity]

Given
!=
==
&&

which are used within one conditional clause, how can I find out which one will be evaluated first ?

e.

if(c==a!=b&&c!=b)
//dosomething

Thank you

[monarch_dodra]

Operators:Precedence of operators : http://www.cplusplus.com/doc/tutorial/operators/

[HochiminhCity]

thank monarchy

[JohnW@Wessex]

Use parentheses to enforce the order so that no one else has to try to remember the precedence when they look at your code.

[laserlight]

Just a warning: "which one will be evaluated first" has to do with order of evaluation, which is sometimes a consequence of the grouping of subexpressions (and thus precedence), but generally the rules of precedence are specified, whereas order of evaluation is generally unspecified.

[monarch_dodra]

Also, be ware of short-circuit:

the (non-overloaded) operator&& and operator|| will NOT evaluate the second parameter if the first is false or true respectively. This is because it is useless. (false && x is always false, true || x is always true).

This is a very know behavior that is not only useful, but relied on.

int * p = 0;

...

if (p && p->is_valid())
    ...

if p->is_valid was evaluated, but p was null, the consequences would be catastrophic.

[HighCommander4]

Also, be ware of short-circuit:

the (non-overloaded) operator&& and operator|| will NOT evaluate the second parameter if the first is false or true respectively. This is because it is useless. (false && x is always false, true || x is always true).

This is a very know behavior that is not only useful, but relied on.

int * p = 0;

...

if (p && p->is_valid())
    ...

if p->is_valid was evaluated, but p was null, the consequences would be catastrophic.

Very true, but I'm sure you meant to declare p as some class type rather than int...

[HochiminhCity]

Also, be ware of short-circuit:

the (non-overloaded) operator&& and operator|| will NOT evaluate the second parameter if the first is false or true respectively. This is because it is useless. (false && x is always false, true || x is always true).

This is a very know behavior that is not only useful, but relied on.

int * p = 0;

...

if (p && p->is_valid())
    ...

if p->is_valid was evaluated, but p was null, the consequences would be catastrophic.

I thank Monachy I learn new things

[monarch_dodra]

Very true, but I'm sure you meant to declare p as some class type rather than int...

Lol. Nice catch sir.

[Zaccheus]

the (non-overloaded) operator&& and operator|| will NOT evaluate the second parameter if the first is false or true respectively.

Let me get this right ... that does not apply to overloaded && operators then.

Thinking about how it would be used, with two parameters (or 'this' and one parameter), the right hand parameter would have to be evaluated before the operator could be called.

I suppose you'd only ever overload it if you did not want the default && behaviour, but it still seems a shame that you cannot keep the 'lazy and' characteristics.

For smart pointers you could overload the boolean operator instead, but when would you ever want to overload && or || in real code ?

Very true, but I'm sure you meant to declare p as some class type rather than int...

Then again INT could have been anything.

[Lindley]

Let me get this right ... that does not apply to overloaded && operators then.

Scott Meyers recommends against overloading those operators for this reason.

[monarch_dodra]

Let me get this right ... that does not apply to overloaded && operators then.

Thinking about how it would be used, with two parameters (or 'this' and one parameter), the right hand parameter would have to be evaluated before the operator could be called.

I suppose you'd only ever overload it if you did not want the default && behaviour, but it still seems a shame that you cannot keep the 'lazy and' characteristics.

For smart pointers you could overload the boolean operator instead, but when would you ever want to overload && or || in real code ?

I highly recommend against the operator bool. If you were to implement it, it means your type could also be cast implicitly to int or double.

Instead, implement the "operator void const*" and "operator!". void* can be on be implicitly cast implicitly to bool. Since the compiler is only allowed 2 implicit casts before giving up, this make your type convertible to bool, and that is it. This make sure you don't have any weird behaviors.

std::iostream does it this way.

In real code, there is no reason to overload && or ||. Even if the overloaded version kept the short-circuit behavior, it is much more practical to allow your type to be evaluated as true or false, and use the default operator.

[laserlight]

this make your type convertible to bool, and that is it. This make sure you don't have any weird behaviors.

Not really: weird behaviour is still possible, though less likely.

std::iostream does it this way.

This is weird, to me:

#include <iostream>

int main()
{
    std::cout << std::cin;
}

The current solution for this weirdness is to implement the safe bool idiom; in the next version of C++ we can simply implement an explicit conversion function to bool.

[monarch_dodra]

Not really: weird behaviour is still possible, though less likely.


This is weird, to me:

#include <iostream>

int main()
{
    std::cout << std::cin;
}

The current solution for this weirdness is to implement the safe bool idiom; in the next version of C++ we can simply implement an explicit conversion function to bool.

All correct, but the problem with explicit conversion is that it is not implicit

if (std::cin)

This would fail to compile with safe conversion. I would say the only absolutely safe way to do it is to provide a "operator bool_proxy", where bool_proxy is a type that can't do anything but be (implicitly) cast to bool.

Kind of like null_ptr_t* I guess: It's not a pointer, but it can be converted to a pointer.

*As a matter of fact, null_ptr can be implemented as a template, so I don't see why you can't do the same thing with bool.

[laserlight]

This would fail to compile with safe conversion.

No. If you insist otherwise, then be prepared: a standard library implementation that conforms to what is expected to be the next version of the C++ standard will cause your code snippet to fail to compile