Short-circuit and and or.

[rocketboy9000]

I noticed that the tutorial section on operators http://www.cplusplus.com/doc/tutorial/operators/ does not mention that the && || ?: or and operators only evaluate what is necessary to calculate their results. This can be important when you see code written by a person who came from Perl like me:
init_all_my_stuff() or my_abort("Couldn't load!");

[firedraco]

Submit it to here: http://www.cplusplus.com/member/contact.form?referrer=http://www.cplusplus.com/doc/tutorial/operators/

[Duthomhas]

That said, such code is aberrant and should not appear anywhere. It is just as efficient, if not more efficient, to use the language constructs properly:
if (!init_all_my_stuff()) my_abort("Couldn't load!");
This is more easily understood by humans and the compiler is more likely to optimize it.

[chrisname]

In languages like PHP and Perl, code like do_something() or die("Unable to do something"); is common and quite easy to understand.

[Duthomhas]

... Yes ... I got that much (and knew it already). As this is a C++ (and C) forum, my response is crafted for the C and C++ point of view. PHP is a disorganized mess and Perl has hysterical raisins.

[Seraphimsan]

I like raisins

[chrisname]

Duoas wrote:

I got that much (and knew it already). As this is a C++ (and C) forum, my response is crafted for the C and C++ point of view.

Ok, that's fair enough.

Duoas wrote:

PHP is a disorganized mess

What do you mean? I like PHP, it's very easy to use and to get things done in.

Duoas wrote:

Perl has hysterical raisins.

I don't get it.

[rocketboy9000]

"This is more easily understood by humans"
I don't agree with that. Many times we see and and or used in this capacity in English, like:
Give me back my daughter, or I'll hunt you down!

"and the compiler is more likely to optimize it."
Bah... C++ relies on the compiler to optimize much harder stuff than this. I have confirmed that my compiler emits identical code for:

if(i>5)std::cout << "WIN!\n";
i>5 and std::cout << "WIN!\n";

Anyway, another reason to know this is that it can lead to accidental conditionals, like:
if(flag && non_pure_function())
non_pure_function will only be called if flag is true.

Another corollary to this is that a?b:c; is the same as a&&b||c; except for precedence.

[Duthomhas]

Do you always use pure logical fallacy to argue your points? I'm sick of participating in threads where you are.

[rocketboy9000]

What logical fallacy? This form of conditional is found in colloquial English. Therefore it is not hard for humans to understand. The compiler knows the behavior of the standard operators when applied to POD. Therefore it can (and should) optimize that behavior. How are either of those statements fallacious?
The operators && || act as conditionals not as an optimization but as required, standard behaviour. Therefore I think it's good to use this form because it is simple, always works, and is readable to anyone with knowledge of English and its common constructions.
Also please tell me what "hysterical raisins" are.
Edit: ok, googled it. You're actually wrong, by the way, this use is encouraged in Perl for the reasons I outlined above, and because Perl likes to consider itself closer to natural language than other curly bracket languages. But that's not relevant to this discussion of C/C++. I don't understand why you don't want to use a feature of this language in a new way.

[Bazzy]

always works

Only with default && and ||, not when overloaded

(edit) And a&&b||c; is not as readable as a?b:c;

[rocketboy9000]

I agree with both of those, although I think that's a good reason not to overload those operators. If you did, templated code could fail mysteriously when you apply it to bool as opposed to SmartBool or ThreadSafeFlagBit. Better to overload & | instead, and use a special case for bool.

[Bazzy]

IMHO any tool should be used as intended.
This doesn't mean that short-circuit evaluation shouldn't be considered, but && and || should only be used when evaluating conditions.
Overloading them for classes representing such conditions may be useful ( maybe overloading operator bool will cause less trouble ).

Writing something like i < 10 || cout << "i >= 10"; is a bad idea and very unreadable

[rapidcoder]

PHP is a disorganized mess

PHPers say the same on C++, and they are probably right. Languages or systems designed by a bunch of kids or a committee (a bunch of grownup kids) are almost never elegant, consistent and organized. I doubt the number of annoyances and sharp edges in C++ is lower than in the newest versions of PHP. At least || and && operators have consistent semantics there.

[moorecm]

Bazzy wrote:

Only with default && and ||, not when overloaded

Quoted for emphasis.

[rapidcoder]

Bazzy wrote:

Only with default && and ||, not when overloaded

Jamie Zawinski wrote:

You have a problem and think, 'I know! I'll use operator overloading!' Now you have two problems.

[rocketboy9000]

LOL.
@Bazzy:

IMHO any tool should be used as intended.

Maybe, but this is like giving me a chrome steel spoon with tungsten carbide serrations and then telling me NOT to use it for my Haagen-Dazs.

[ne555]

Give me back my daughter, or I'll hunt you down!

xor

Another corollary to this is that a?b:c; is the same as a&&b||c; except for precedence.

They also differ in return value and type (this ain't python). If you aren't catching the returned value, use an if-else structure

[rocketboy9000]

xor

It's not xor, it's a conditional. If the unseen enemy doesn't do as I say, then the hunting will occur. If he gives back my daughter, then no hunting will occur. The hunting is only executed if my daughter is not returned.

They also differ in return value and type (this ain't python). If you aren't catching the returned value, use an if-else structure

The return value is different, but that's not relevant. There is a semicolon on the end of those sections. Besides, my point was to do with control flow. Specifically that b is only evaluated if a is not 0, and c is only evaluated if a is 0. The fact that control flow is altered by these operators can lead to mysterious bugs. Interestingly, my copy of "The C++ Programming Language" neglects to mention just what is returned by these operators. I'm writing a test program.
OK done, it always returns either one or zero.

[ne555]

void foo();
void bar();

(a)? foo(): bar(); //fine
a and foo() or bar(); //compile error 

a?b:c; is the same as a&&b||c;

I missed it before but,
for the Boolean operators if a=true and b=false, c will be executed.
That is not the case with operator ?: that only executes a and b