Bagikan melalui

Operator precedence of && and ||

  • Artikel

There is an issue concerning logical expressions (i.e. expressions that are evaluated to true or false, a.k.a Boolean expressions) in X++. The essence of this issue is that the X++ language is not aligned with other languages in its precedence of the logical and (&&) and or (||) operators. In X++ these two operators have the same precedence, whereas in other languages && is higher priority than ||.

The issue here is that programmers might unexpectedly create bugs for themselves when writing complex Boolean expression involving these two operators. For instance:

A || B && C

(where A, B and C are Boolean subexpressions) will be evaluated as (A||B) && C in X++, but as A || (B && C) in every other languages that I know of.

This unfortunate operator priority choice has been there since the first version of the X++ language. The workaround, of course, is simple (use parenthesis to group together the sub-expressions), but there is a potential for bugs that may be subtle. We have had no reports from the user base about this problem. It is unclear to me at this time if this is explicitly called out in any documentation that we have, but I doubt it.

The morale is this: Always group together your complex Boolean expressions with parenthesis to aid both you and the compiler.

We have been very reluctant to align the precedence of the logical operators to other languages, because we fear breaking existing code in the user code base. I would love to hear the opinions of the people out there in the trenches. Let us know: Do we let sleeping dogs lie, or go ahead and fix it?

Comments

  • Anonymous
    June 25, 2007
    Personally, I have never relied on the X++ operator precedence of ||/&& (I use parenthesis as described). This precedence is a remnant of XAL (and where XAL got it, I don't know). My advice: get rid of it. Maybe add a search tool to search for combined use of &&/|| without parenthesis.

  • Anonymous
    July 01, 2007
    The comment has been removed

  • Anonymous
    July 12, 2007
    The comment has been removed

  • Anonymous
    July 21, 2007
    Oh please, you won't change this will you? I am dead sure that a change of this 'aberration' will break thousand lines of code. And though I know that most other languages works differently I got used to this behavior during the last six year and I think many other people too. You could have done this in 2000 latest but now? Please not!

  • Anonymous
    July 24, 2007
    I am on the "don't fix it" side.  Even thought it would be cleaner if it was like other languages, I think it doesn't worth the trouble of taking a chance of creating new bugs just to conform to the norm.  Like others said, when an expression get a bit complex, just use parenthesis and you'll be safe.

  • Anonymous
    November 27, 2007
    I'm new to X++ and am fortunate to have stumbled here before falling into this trap.  Here's what I'd like to see done (in order of difficulty):

  1.  A 1-page beginner reference on x++ language paradigms (such as this) that are non-standard vs. other common languages.
  2.  This particular idiosyncrasy eliminated along with a code conversion script... or at least a compiler warning if there's there a logical operation without parenthesis.
  3.  X++ (along with its weak text editor) deprecated entirely and converge to c#/Visual Studio.
  • Anonymous
    December 20, 2007
    At the end of the day I'm on "fix it" side. And actually I don't believe that there are solutions that are conciously depend on such behavior. But since we actually can not predict the impact of the change (we can on SYS / GLS / DIS side but there are partner/customer solutions!) my proposed steps are
  1. Adding BP warning on logical operator mixing && and || without parenthesis.
  2. Following release (+1) - switch to BP error.
  3. Following release (+2) - stick to standard && / || precedence. PS: [ emotion ] arithmetical bug (3/3 + 3/3) = 3 was corrected relatively fast, while bug in logical operation (true || false && false) = false persists for years...