Is there an option for Pascal order of operators evaluation of conditionals?

[HenrikErlandsson]

I'd appreciate your thoughts on performance hits of having to add extraneous parentheses in conditions, specifically loop exit conditions such as for while and repeat.

As for editing, this is pretty much the only code change from Delphi so far. Just adding them is obviously no problem, I'd just like to know if they eat stack and affect performance (the normal questions for any compiler).

It is a hard compile error, and I use a lot of formulas in my sources, so if there is an option it will additionally save some editing time for me. (It seems that parentheses around the complete condition (as separated by boolean operators) will avoid the hard stop, if this is a useful suggestion for the Delphi convert project.)

But my personal time editing is secondary, primarily I'd like to learn the performance hits+workarounds (if any). This is outside the boolean short-circuit evaluation, just math.

Ref: Operator precedence in Pascal

[HeavyUser]

I'd appreciate your thoughts on performance hits of having to add extraneous parentheses in conditions, specifically loop exit conditions such as for while and repeat.

As for editing, this is pretty much the only code change from Delphi so far. Just adding them is obviously no problem, I'd just like to know if they eat stack and affect performance (the normal questions for any compiler).

It is a hard compile error, and I use a lot of formulas in my sources, so if there is an option it will additionally save some editing time for me. (It seems that parentheses around the complete condition (as separated by boolean operators) will avoid the hard stop, if this is a useful suggestion for the Delphi convert project.)

But my personal time editing is secondary, primarily I'd like to learn the performance hits+workarounds (if any). This is outside the boolean short-circuit evaluation, just math.

Ref: Operator precedence in Pascal

your question is at best confusing (to me at least). As far as I remember even in delphi more than one boolean checks need to be enclosed in parenthesis. I have never had any problem with boolean checks either in a loop (while repeat etc) or in an "if" statements. everything I have working on delphi, works as is on lazarus too. I do understand that means nothing, even worst it might be a case of "old dog and new tricks" kind of thing aka my code does not use any newer delphi features.
A specific question with a short sample that works on delphi and raises an error on fpc will probably help to shine some light on the subject and hopefully get more responses.

Sorry I couldn't really help.

[Thaddy]

What code did you needed to change/? Can you give a small example. Usually that is not necessary with some older Delphi code.
I suspect you rely on the value of a loop variable after the loop has fully ended end - not prematurely cut short by a condition: this is officially undefined in both Delphi and FPC....and can differ.
Relying on such a value was always wrong but there is a lot of Delphi code that will byte you.
Operator precedence is 100% exactly the same as in Delphi. And mind that Boolean shortcut evaluation is ON by default.
This can have side effects in both Delphi and FPC but are the same side effects. So make sure that the code is compiled for the correct Boolean evaluation setting.

[HenrikErlandsson]

A simple example would be this:

Code: Pascal  [Select][+][-]

1.         i:=0;
2.         while i>=0 and i<10 do
3.         begin
4.           inc(i);
5.         end;

This gives

unit1.pas(87,16) Error: Incompatible types: got "Boolean" expected "Int64"

And putting (i>=0) and (i<10) instead makes it work.

...and the page I linked explains perfectly why. 

It's not possible, and I heavily doubt there's an option to change operator order of precedence.

Whether extra parentheses apart from the ones around the conditional parts affect performance I can measure myself.

So, question answered in the question itself, how do I mark it solved? Sorry about that.

[correa.elias]

I think its this way because in pascal the 'and' operator serves two porpouses:
- as logic operator
- as bitwise operator (because of this, the precedence is higher than relational operators)
So its the expected behavior. Otherwise you need to have diferent operators like in C '&&' for 'and' e '&'  for 'bitwise and'.

[lucamar]

Whether extra parentheses apart from the ones around the conditional parts affect performance I can measure myself.

I seriously doubt that using parenthesis impacts more than slightly in compilation times, or anything at all at run-time.

So, question answered in the question itself, how do I mark it solved? Sorry about that.

Edit the first post and change the Subject to add "[SOLVED]"

[Leledumbo]

It's not possible, and I heavily doubt there's an option to change operator order of precedence.

Indeed, this is only parsing problem, that actually boost compiler performance as it has only a few level of operator precedence (5 or so). Without the forced parentheses, my experience shows at least it will add another 2 levels, due to logical operator needs to be parsed later after relational operator, compared to if they're on the same level as the arithmetic ones.

Whether extra parentheses apart from the ones around the conditional parts affect performance I can measure myself.

It will be negligile for most cases, and it only affects compile time (by a few nano or millisecond, depending how many and how complex expressions that you have and how strong your CPU is), runtime won't be affected as the generated code will be exactly the same.

[Thaddy]

<sigh> Boolean operators in Delphi and FreePascal have equal weight, which means evaluation left to right. Period.
There is simply no difference.