Do you mean whether there is a difference or whether there should be a difference? Regarding the former question, there's an informal standard in math and programming that "and" has higher precedence. Regarding the latter, note that order of operations serves only to simplify the presentation of expressions, and thus is merely a matter of convenience, so precedence rules should be selected to maximize convenience and consistency. In the context of math, "and" and "or" superficially mirror multiplication and addition, respectively, so it's more consistent mathematically for "and" to take precedence. In the context of Computer Science one could make an argument either way. For example, the classic problem of circuit satisfiability is equivalent to satisfiability of an expression in conjunctive normal form, whose parentheses can be eliminated if "or" takes precedence but not if "and" takes precedence, which would suggest that "or" should take precedence.

Do you mean whether there is a difference or whether there should be a difference? Regarding the former question, there's an informal standard in math and programming that "and" has higher precedence. Regarding the latter, note that order of operations serves only to simplify the presentation of expressions, and thus is merely a matter of convenience, so precedence rules should be selected to maximize convenience and consistency. In the context of math, "and" and "or" superficially mirror multiplication and addition, respectively, so it's more consistent mathematically for "and" to take precedence. In the context of Computer Science one could make an argument either way. For example, the classic problem of circuit satisfiability is equivalent to satisfiability of an expression in conjunctive normal form, whose parentheses can be eliminated if "or" takes precedence but not if "and" takes precedence, which would suggest that "or" should take precedence.

I mean whether there should be a difference. Most (if not all) programming languages have "and" at higher precedence than "or", but when I presented this behaviour in a DSL parser I'm writing to a co-worker, he said "you'd better poll our users about that behaviour and document it thoroughly". Our users are other computer-savvy types who program, so the "and higher than or" precedence shouldn't surprise them.

There's little inherent reason to prefer one over the other and as there's a standard, you need a compelling reason to go against it. In certain domains there might be such a reason but I doubt you're in one, so you're probably best either sticking with the standard or requiring parentheses to disambiguate.

From the 3 code lines you posted, choose the one you mean and use it. I don't know the answer and I probably wouldn't bother to find out since a few braces make it so much easier for some other code user (who also may or may not know). I wonder how the Tasking embedded compiler treats it? Probably best not to assume.

In Delphi, however, I have to explicitly group 100% of the expressions since the two are equal.

No, and is higher precedence than or in Delphi too. Most of the time in Delphi I end up grouping operations because relational and equality testing is lower precedence than the logical operators. In C# it's the other way around, so there's a lot less grouping that needs done.

I voted that and should be greater than or but I almost always use parentheses to group complex expressions, both to make sure it works the way I want and because it's a heck of a lot easier to read through later.

Using parentheses to make your code clearer just makes sense, like using short paragraphs to make your posts clearer *cough*.

In Delphi, however, I have to explicitly group 100% of the expressions since the two are equal.

No, and is higher precedence than or in Delphi too. Most of the time in Delphi I end up grouping operations because relational and equality testing is lower precedence than the logical operators. In C# it's the other way around, so there's a lot less grouping that needs done.

I'm am _technically_ corrected. In practice, there's no differenced between the two because you have to explicitly qualify everything to prevent conflicts.

I voted that and should be greater than or but I almost always use parentheses to group complex expressions, both to make sure it works the way I want and because it's a heck of a lot easier to read through later.

Yup... I make liberal use of parens. I know the order of precedence but adding the parens make it explicit and there is no ambiguity for anyone else looking at the code. The compiler doesn't care... the executable doesn't care... it's all for the humans (the weak links in the chain )

I never trust precedence beyond the basics; way too easy to get it wrong in real world situations. Either yourself, or the guy after you that is debugging or modifying the code. Order of operations should be obvious and explicit, not only is it easier to write but it's easier to decompose later if a flaw is found. It's also often easier to spot how it can be restructured if it's broken down in the first place.

Yup... I make liberal use of parens. I know the order of precedence but adding the parens make it explicit and there is no ambiguity for anyone else looking at the code. The compiler doesn't care... the executable doesn't care... it's all for the humans (the weak links in the chain )

I understand that, and you could use the much simpler example of integer subtraction to make the same point, but I don't think grouping multiple applications of the same operator is fitten was talking about.

I think it might not have been clear to someone reading fitten's post that he meant adding parens doesn't matter *if you do exactly what the compiler would have done*

Adding them in general, even if they do not even alter operator precedence ordering can change the order of application[1]. This is worth making crystal clear.

I don't know of any off hand but I suppose some languages compilers might be free to ignore the requested precedence order based on 'mathematical' associativity rules being followed despite it actually mattering in the realm of floating point (perhaps under some optimising scenarios like converting into an FMAC, or just as a bug!). They wouldn't be pleasant languages to be in if you really care about numerical stability.

I think it might not have been clear to someone reading fitten's post that he meant adding parens doesn't matter *if you do exactly what the compiler would have done*

Precisely. People adding parens to complicated floating-point expressions are doing so to enhance human readability, and thus may inadverently impact the compiler's interpretation of the expression. Moreover, I don't think fitten meant or even implied the part you wrote in **.

Quote:

I don't know of any off hand but I suppose some languages compilers might be free to ignore the requested precedence order based on 'mathematical' associativity rules being followed despite it actually mattering in the realm of floating point (perhaps under some optimising scenarios like converting into an FMAC, or just as a bug!). They wouldn't be pleasant languages to be in if you really care about numerical stability.

Many FORTRAN compilers optimized heavily by default, at the expense of precision, including the sort of optimizations you mention (among others). C and C++ compilers too. Defaults have changed on most of them to be more conservative, but all of them still support such optimizations.

Yup... I make liberal use of parens. I know the order of precedence but adding the parens make it explicit and there is no ambiguity for anyone else looking at the code. The compiler doesn't care... the executable doesn't care... it's all for the humans (the weak links in the chain )