WHich one is evaluated first

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

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

:D thank monarchy

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

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.

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.

Code:

---

int * p = 0;

...

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

---

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

Quote:

---

Originally Posted by 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.

Code:

---

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

Quote:

---

Originally Posted by 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.

Code:

---

int * p = 0;

...

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

---

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

---

:D I thank Monachy I learn new things

Quote:

---

Originally Posted by HighCommander4

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

---

Lol. Nice catch sir.

Quote:

---

Originally Posted by monarch_dodra

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 ?

Quote:

---

Originally Posted by HighCommander4

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

Quote:

---

Originally Posted by Zaccheus

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

---

Scott Meyers recommends against overloading those operators for this reason.

Quote:

---

Originally Posted by Zaccheus

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.

Quote:

---

Originally Posted by monarch_dodra

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.

Quote:

---

Originally Posted by monarch_dodra

std::iostream does it this way.

---

This is weird, to me:

Code:

---

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

Quote:

---

Originally Posted by laserlight

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


This is weird, to me:

Code:

---

#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 :)

Code:

---

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.

Quote:

---

Originally Posted by monarch_dodra

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 ;)

Quote:

---

Originally Posted by laserlight

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 ;)

---

Just to be more specific ( and to see if I got it right :) ), in the next standard implicit boolean conversions are treated as direct initializations of the boolean target ( that is "bool b(t);" and not "bool b = t;" ). For this reason that code * would compile with an explicit bool conversion function (laserlight, correct me if I'm wrong :) ).

*: I mean the "if( std::cin )" snippet

Quote:

---

Originally Posted by laserlight

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 ;)

---

Holy crap, you're right!

Code:

---

27.5.4 Class template basic_ios [ios]
namespace std {
template <class charT, class traits = char_traits<charT> >
class basic_ios : public ios_base {
public:
// types:
typedef charT char_type;
typedef typename traits::int_type int_type;
typedef typename traits::pos_type pos_type;
typedef typename traits::off_type off_type;
typedef traits traits_type;
explicit operator bool() const;
bool operator!() const;
iostate rdstate() const;
void clear(iostate state = goodbit);
void setstate(iostate state);
bool good() const;
bool eof() const;
bool fail() const;
bool bad() const;

---

That's gonna break a lot of code!

Guess I'll just use

Code:

---

while (!!std::cin)

---

Much faster than typing static_cast<bool> ;)

From the Wikipedia page of C++0x:

Quote:

---

In C++0x, the explicit keyword can now be applied to conversion operators. As with constructors, it prevents the use of those conversion functions in implicit conversions. However, language contexts that specifically require a boolean value (the conditions of if-statements and loops, as well as operands to the logical operators) count as explicit conversions and can thus use a bool conversion operator.

---

So it's not that bad.

And as far as I'm aware, the C++0x committee goes out of its way not to break existing code.

Quote:

---

Originally Posted by HighCommander4

From the Wikipedia page of C++0x:



So it's not that bad.

And as far as I'm aware, the C++0x committee goes out of its way not to break existing code.

---

I see. But what about things like

Code:

---

while( (std::cin >> a) && a!=0 )

---

?

Quote:

---

Originally Posted by monarch_dodra

Much faster than typing static_cast<bool>

---

but what about (bool) ? and !! isn't that informative on what that actually means :)

Quote:

---

Originally Posted by monarch_dodra

I see.

---

Err... I was being serious. As far as I know, explicit conversion functions to bool are specifically designed to replace the safe bool idiom and other existing methods to try and convert to bool without allowing unexpected behaviour, i.e., it is the case that it is not going to break existing code.

Quote:

---

Originally Posted by monarch_dodra

But what about things like

Code:

---

while( (std::cin >> a) && a!=0 )

---

---

Consider:

Quote:

---

Originally Posted by C++ Standard Working Draft 2010-08-21 Clause 4 Paragraph 3 (part)

An expression e can be implicitly converted to a type T if and only if the declaration T t=e; is well-formed, for some invented temporary variable t. Certain language constructs require that an expression be converted to a Boolean value. An expression e appearing in such a context is said to be contextually converted to bool and is well-formed if and only if the declaration bool t(e); is well-formed, for some invented temporary variable t. The effect of either implicit conversion is the same as performing the declaration and initialization and then using the temporary variable as the result of the conversion.

---

Quote:

---

Originally Posted by C++ Standard Working Draft 2010-08-21 Clause 5.14 Paragraph 1 (part)

The && operator groups left-to-right. The operands are both contextually converted to type bool (Clause 4).

---

Quote:

---

Originally Posted by Joeman

but what about (bool) ? and !! isn't that informative on what that actually means :)

---

well, bool is a C-cast. I stay clear away from those. !! is just as informative as static_cast<bool> if you're used to them. As always, it is just a language construct you have seen before and understand, or it isn't and you have to think about it. Were I work, we have objects that can't be cast to bool, but have operator!. We use "if (!!a)" all the time, and when we see "!!" we know exactly what it means. And it's safe.

Quote:

---

Originally Posted by laserlight

Err... I was being serious. As far as I know, explicit conversion functions to bool are specifically designed to replace the safe bool idiom and other existing methods to try and convert to bool without allowing unexpected behaviour, i.e., it is the case that it is not going to break existing code.

---

I was acknowledging what was being said to me. Maybe "I see" can be interpreted as sarcasm in some context, but this was not the case here.

Thank you very much. You have taught me two very interesting things today. Pardon me if my surprised looked like mockery. It wasn't.

Quote:

---

Originally Posted by monarch_dodra

well, bool is a C-cast. I stay clear away from those

---

Yes, static_cast is preferable, but when it comes to the primitive types, the c-cast works fine. I only worry when it comes to polymorphism and class pointers in general.

I would hate to write this all over my code

Code:

---

int I = 10;
int I2 = 3;
float F = static_cast<float>( I ) /  I2;

---

vs

Code:

---

int I = 10;
int I2 = 3;
float F = (float) I  / I2;

---