stdio line-streaming revisited

Frits van Bommel fvbommel at REMwOVExCAPSs.nl
Thu Mar 29 11:00:25 PDT 2007


Sean Kelly wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
>> kris wrote:
>>> There used to be a tango/example like this variation:
>>>
>>>     import tango.io.Console;
>>>
>>>     void main()
>>>     {
>>>         Cout ("Please enter your name: ").flush;
>>>         Cout ("Hello, ") (Cin.get);
>>>     }
>>
>> Ah, also, the last line is translated into:
>>
>> Cout.opCall("Hello, ").opCall(Cin.get);
>>
>> D does not specify evaluation order, so the code might end up printing 
>> "Hello, " before reading the standard input.
> 
> We discussed this a long time ago and came to the conclusion that while 
> the D spec does not guarantee evaluation order for this scenario, it 
> seems impossible for it to be anything other than left to right because 
> the chained calls rely on the return value from previous calls.  If this 
> is untrue then I'd love to know the reasoning.  Perhaps an aggressive 
> inlining mechanism could violate this?

Actually if you go a bit lower-level (explicit 'this'), that line is 
equivalent to something like:
---
write(write(Cout, "Hello, "), get(Cin));
---
or
---
write(get(Cin), write("Hello, ", Cout));
---
depending on whether the calling convention passes 'this' first or last. 
(except with more complicated function names because of mangling, obviously)
So actually 'this' is just another parameter. As such, evaluation can 
happen before or after other parameters.
If the parameters happen to be evaluated in the "wrong" order 
(left-to-right in the first case, right-to-left in the second) the 
Cout("Hello, ") gets evaluated before write("Hello, ", Cout).
If it happens to be in the "right" order, it's the other way around. But 
I'm pretty sure there's no guarantee.
For that matter, 'this' could be treated specially (e.g. always passed 
in a specific register not otherwise used in the calling convention) and 
then there's no way to tell what the evaluation order will be, except 
for a specific implementation.

What I'm trying to say here is basically this: you shouldn't rely on the 
order of evaluation of parameters. Not even if one of them happens to be 
used as 'this' for the method in question.



More information about the Digitalmars-d mailing list