In practice, the difference is in the location where the preprocessor searches for the included file.
For #include <filename> the preprocessor searches in an implementation dependent manner, normally in search directories pre-designated by the compiler/IDE. This method is normally used to include standard library header files.
For #include "filename" the preprocessor searches first in the same directory as the file containing the directive, and then follows the search path used for the #include <filename> form. This method is normally used to include programmer-defined header files.
A more complete description is available in the GCC documentation on search paths.
Yes, short-circuiting and evaluation order are required for operators || and && in both C and C++ standards.
C++ standard says (there should be an equivalent clause in the C standard):
1.9.18
In the evaluation of the following expressions
a && b
a || b
a ? b : c
a , b
using the built-in meaning of the operators in these expressions, there is a sequence point after the evaluation of the first expression (12).
In C++ there is an extra trap: short-circuiting does NOT apply to types that overload operators || and &&.
Footnote 12: The operators indicated in this paragraph are the built-in operators, as described in clause 5. When one of these operators is overloaded (clause 13) in a valid context, thus designating a user-defined operator function, the expression designates a function invocation, and the operands form an argument list, without an implied sequence point between them.
It is usually not recommended to overload these operators in C++ unless you have a very specific requirement. You can do it, but it may break expected behaviour in other people's code, especially if these operators are used indirectly via instantiating templates with the type overloading these operators.
Best Solution
Here's a secret: I don't bother learning precedence rules. They are too easy to get wrong, and it makes the next person to look at the code think too much. To paraphrase: assume the person who maintains your code is an axe-wielding psycho who knows where you live. Be nice too them.
So rather than:
I would use:
Or perhaps better (subjective), break it down into separate statements The trickier question, perhaps, is what happens in "clever" lines of code that has side-effects on expressions later in the line:
Such things should be used sparingly, and you should try to know what behaviour is defined and what is explicitly undefined but works (or fails) depending on the compiler you use.