Re: Software landmines (was: Why C++ is successful)

["John G. Volan" <johnvolan@sprintmail.com>]

Matthew Heaney wrote:
> 
> Yes.  Far too few programmers use declare blocks and constant object
> declarations to simplify complex expressions.  Instead of
> 
> Op (Get_A (10), Get_B (X), Get_C (Y));
> 
> it's better to do
> 
> declare
>    A : constant Integer := Get_A (10);
>    B : constant Float := Get_B (X);
>    C : constant Boolean := Get_C (Y);
> begin
>    Op (A, B, C);
> end;

There's a subtle difference between these two examples:  In the latter
case, the local constant declarations will be elaborated in the
indicated order, so the function calls are going to be done
sequentially.  But in the former case, the language defines no
particular order of evaluation of the actual procedure parameters, so
these function calls might occur in any order.  A smart compiler for the
right kind of target machine may even be able to schedule these calls to
occur in parallel. 

...
> The "renames" clause is a binding operator in Ada (although technically
> it binds a name to an object, not a value).  A hip way to do the above
> directly in the language is
> 
> declare
>    A : Integer renames Get_A (10);
>    B : Float renames Get_B (X);
>    C : Boolean renames Get_C (Y);
> begin
>    Op (A, B, C);
> end;

I'm curious: Does this have the same effect as the above, i.e., are the
function calls forced into a sequential order?  Or is their evaluation
deferred until the aliases A, B, and C are actually used as parameters
to the Op call, in which case the aliased function calls get executed in
an undefined order?

-- 
indexing
   description: "Signatures for John G. Volan"
   self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe"
   two_cents: "Java would be even cooler with Eiffel's assertions/DBC, %
              %generics, true MI, feature adaptation, uniform access, %
              %selective export, expanded types, etc., etc..."
class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant
   disclaimer: not (opinion implies employer.opinion)
end -- class JOHN_VOLAN_SIGNATURE