stdio line-streaming revisited

Andrei Alexandrescu (See Website For Email) SeeWebsiteForEmail at erdani.org
Thu Mar 29 11:47:28 PDT 2007


Frits van Bommel wrote:
> 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.

Exactly so, thanks for the clear explanation.

Andrei



More information about the Digitalmars-d mailing list