On Thursday, 17 July 2014 at 19:56:23 UTC, Johannes Pfau wrote:
Am Thu, 17 Jul 2014 11:43:04 -0700
schrieb Andrei Alexandrescu <[email protected]>:
On 7/17/14, 9:06 AM, John Colvin wrote:
> On Thursday, 17 July 2014 at 15:58:05 UTC, Andrei
> Alexandrescu
> wrote:
>> I think an approach based on functions peek/poke is a lot
>> more
>> promising. D programs must define sequences of std calls
>> anyway,
>> otherwise even the simplest programs that use
>> writeln("What's your
>> name?") followed by a readln() are incorrect. So in a way
>> peek/poke
>> come for "free".
>
> Could you expand on this "sequences of calls"? What exactly
> do you
> mean by defining it?
For example if you run this C program:
printf("ur name: ");
fflush(stdout);
scanf("%s", &name);
printf("Hello, %s!", name);
it's guaranteed the order of calls is preserved.
only because rearranging those cannot be proved to create the
same observable semantics (in this case of course it can be
actively disproved). That doesn't apply to all sequences of
function calls, thankfully.
Function calls are actually compiler barriers in every C (like)
compiler, I guess that's even in the standard. Relying on this
too
much can be dangerous with inlining though.
As I understand it (I'm not a compiler writer or a C standard
expert):
*Opaque* function calls are a compiler memory barrier in C and
that's only by necessity (that opaque function could contain a
memory barrier, amongst other problems).
If the compiler can guarantee to maintain the same visible
semantics of defined behaviour it can rearrange function calls
just as freely as anything else.
