Jump to content
Sign in to follow this  
dummzeuch

Complete Boolean Evaluation

Complete Boolean Evaluation  

28 members have voted

  1. 1. Has anybody ever enabled Complete Boolean Evaluation, and if yes, why? (see associated post for comments)



Recommended Posts

Has anybody ever enabled Complete Boolean Evaluation, and if yes, why?

(see associated poll)

 

Here is a use case (but I still would not do it this way but simply switch the conditions):

 

 

Edited by dummzeuch

Share this post


Link to post
1 hour ago, dummzeuch said:

Has anybody ever enabled Complete Boolean Evaluation, and if yes, why?

(see associated poll)

 

Here is a use case (but I still would not do it this way but simply switch the conditions):

 

 

I can't see the full context of the case, but say you have:

Result := condition1;
...
Result := (functionCall1(x) or functionCall2(y)) and Result;

In the above case, you may want to have both functions called, even if functionCall1(x) already returns True (or another function call returns False in a subexpression with and).

 

But even then, you can call the functions separately, put their results in variables and then combine the results later on. You may need one or more extra Boolean variables for the functoin results and a few lines more, but the code flow will be clearer. So complete Boolean evaluation is never really a necessity. Other languages manage without it too.

 

And of course you can do:

Result := condition1;
...
Result := functionCall1(x) or Result;
Result := functionCall2(y) and Result;

But finding out whether you should use or or and in the two lines above is a bit hairy, IMO, and can be done wrong (I am still not sure I did it correctly, to get the result I expect). I'd prefer separate functon result variables.

Edited by Rudy Velthuis

Share this post


Link to post
1 hour ago, dummzeuch said:

Has anybody ever enabled Complete Boolean Evaluation, and if yes, why?

The more subtle cases are when code requires to switch that off to work properly and someone compiles with that switch on:

if (something <> nil) and (something.someinstanceaccess) then 

 

Share this post


Link to post
2 minutes ago, Uwe Raabe said:

The more subtle cases are when code requires to switch that off to work properly and someone compiles with that switch on:


if (something <> nil) and (something.someinstanceaccess) then 

 

Ah, indeed. A construct I use quite often. With complete boolean eval that could crash. But you can avoid such problems:

if something <> nil then
begin
  if something.someinstanceaccess then
    ...

 

Edited by Rudy Velthuis
  • Like 1

Share this post


Link to post

I believe that complete expression evaluation was made for lazy people ! The only useful scenario is that your condition contains a function call that must run on all situations.

Otherwise it's just useless:

Result := Variable and (Variable2 = 5) and Variable3; // completely useless ! additional CPU-time for nothing !
Result := Variable and OtherWork();  // maybe useful. 

It's important to mention that many programming language do not support full expression evaluation and some of them provide logical operators (such && and ||) and name long-circuit (complete expression evaluation) as a flow control (they use 'and', 'or' keyword). Here is an example:

exists($filename) and doWork() or error("Could not open file filename"); // parsed as (exists($filename) and doWork()) or error("Could not open file filename");
exists($filename) and doWork() || error("Could not open file filename"); // parsed as exists($filename) and (doWork() || error("Could not open file filename"));

 

Share this post


Link to post
11 minutes ago, Mahdi Safsafi said:

I believe that complete expression evaluation was made for lazy people ! The only useful scenario is that your condition contains a function call that must run on all situations.

Otherwise it's just useless:


Result := Variable and (Variable2 = 5) and Variable3; // completely useless ! additional CPU-time for nothing !
Result := Variable and OtherWork();  // maybe useful. 

It's important to mention that many programming language do not support full expression evaluation and some of them provide logical operators (such && and ||) and name long-circuit (complete expression evaluation) as a flow control (they use 'and', 'or' keyword). Here is an example:


exists($filename) and doWork() or error("Could not open file filename"); // parsed as (exists($filename) and doWork()) or error("Could not open file filename");
exists($filename) and doWork() || error("Could not open file filename"); // parsed as exists($filename) and (doWork() || error("Could not open file filename"));

 

I am not so sure. If I remember correctly, in the very olden days, it was the only option (TP3 or some such -- memories about those days have become a little vague). Short-circuit boolean evaluation came later.

 

Also: https://www.gnu-pascal.de/gpc/and.html:

Quote

However, since it seems to be a de-facto standard among ISO Pascal compilers to evaluate both operands of and

For such cases, GNU Pascal even knows the and then construct, to force short-circuit evaluation.

Edited by Rudy Velthuis
  • Like 1

Share this post


Link to post

I am working on a legacy project which has it enabled. I did not dare to disable it, so all new units get a compiler directive to switch full bool eval off while you have to be extra careful and always keep in mind that full boolean eval is enabled when editing "old" units.

 

Reason? I suppose there was none and "full Boolean evaluation" sounded better than "mediocre Boolean evaluation"

Share this post


Link to post
16 minutes ago, David Heffernan said:

So I guess you are happy to rely on the left to right order ......

Wow, that was important for you, I guess.

 

Yes, I am happy to use it. I just use it, and if it doesn't work, I find out soon enough.

 

Just like I always forget the order of directives like virtual, stdcall, static, inline, overload, etc., so I just try out an order and find out if it is wrong. <g>

Share this post


Link to post
18 hours ago, Der schöne Günther said:

I am working on a legacy project which has it enabled. I did not dare to disable it, so all new units get a compiler directive to switch full bool eval off while you have to be extra careful and always keep in mind that full boolean eval is enabled when editing "old" units.

 

Reason? I suppose there was none and "full Boolean evaluation" sounded better than "mediocre Boolean evaluation"

Not necessarily mediocre, but short-circuit might sound like something went wrong. <g>

Edited by Rudy Velthuis

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×