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