Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Inconsistent behaviour with short boolean evaluation !!!

2 views
Skip to first unread message

Skybuck Flying

unread,
Feb 11, 2015, 7:59:48 PM2/11/15
to
Hello,

Delphi XE 7 behaves inconsistent concerning function result "build up":

// CASE 1 (AND): will always call all functions !
function Example1 : boolean;
begin
result := True;
result := result and FunctionA;
result := result and FunctionB;
result := result and FunctionC;
end;

// CASE 2 (OR): short boolean evaluation makes this code fail ! once
functionA returns true, the other 2 functions will not called !
function Example2 : boolean;
begin
result := False;
result := result or FunctionA;
result := result or FunctionB;
result := result or FunctionC;
end;

// This kind of inconsistent behaviour is bad !!!

// Recommendation: Always execute functions which are called on "boolean
chains !"

Bye,
Skybuck.


Skybuck Flying

unread,
Feb 11, 2015, 8:07:43 PM2/11/15
to
For now I solve this problem as follows:

function Example2 : boolean;
var
vResult : array[0..12] of boolean;
vIndex : integer;
begin
result := false;

vResult[00] := Function00;
vResult[01] := Function01;
vResult[02] := Function02;
vResult[03] := Function03;
vResult[04] := Function04;

for vIndex := 0 to 4 do
begin
result := result or vResult[vIndex];

if result then break;
end;
end;

(Needless to say, this is annoying and error prone).

Hopefully my recommendation gets implemented some day ! ;) :)

Bye,
Skybuck.

Grinder

unread,
Feb 12, 2015, 8:06:14 AM2/12/15
to

Skybuck Flying

unread,
Feb 12, 2015, 11:15:14 AM2/12/15
to
http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/compdirsbooleanshortcircuitevaluation_xml.html

I know that compiler option exists but turning off short evaluation is not
good enough, because I do want short evaluation in all other cases.

I don't want short evaluation when functions are involved. That's all... so
I hope to see improvements in Delphi XE 7.

I also consider it a bit of a bug... because those functions may actually do
something usefull... simply "disabling" something usefull just basic some
other "boolean logic" part can be short-circuited doesn't really make sense.

Bye,
Skybuck.

Skybuck Flying

unread,
Feb 12, 2015, 11:19:47 AM2/12/15
to
Then again... one could argue that just the mere "act" of reading some
boolean could also trigger something.

Like an access violation.

In that case my desired behaviour would introduce a new inconsistency.

If functions were executed they could access violate, but the booleans
themselfes not.

Perhaps it's best to leave Delphi XE 7 the way it is.

I will have to live with writing around it.

Or maybe some other solution exists... perhaps indicating somehow that the
functions must be fully evaluated when on "boolean chains".

function test : boolean; no_short_circuit;
function test : boolean; full_boolean_evaluation; // or this.
begin

end;

result := result or test;

^ test always executes.

Bye,
Skybuck.

Grinder

unread,
Feb 12, 2015, 5:35:59 PM2/12/15
to
On 2/12/2015 10:14 AM, Skybuck Flying wrote:
> http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/compdirsbooleanshortcircuitevaluation_xml.html
>
>
> I know that compiler option exists but turning off short evaluation is
> not good enough, because I do want short evaluation in all other cases.
>
> I don't want short evaluation when functions are involved. That's all...

That doesn't seem very consistent.

Skybuck Flying

unread,
Feb 12, 2015, 5:39:56 PM2/12/15
to


"Grinder" wrote in message
news:R8mdnXirqr1Tt0DJ...@mchsi.com...
It seems to be a conflict/paradox.

On one hand it's consistent... on the other hand it's not.

Which kinda sucks.

Bye,
Skybuck.

Skybuck Flying

unread,
Feb 12, 2015, 5:42:43 PM2/12/15
to
It is not as bad as it seems though.

Fortunately there is a way out of the paradox.

"Enable full boolean evaluation".

Drawback is less performance/more instructions required... nobody/most
people probably don't wanna pay that price :)

So that the funny thing.

They'd rather live with a little paradox now and then... then sacrifice
speed ;)

Bye,
Skybuck.

0 new messages