Tomas Lindquist Olsen wrote:
> On Wed, Jul 15, 2009 at 2:18 AM, Walter Bright<newshound1@digitalmars.com> wrote:
>> Don wrote:
>>> In this case you may have a long function, with only a single instruction right in the middle which needs to be changed.
>> void foo()
>> {
>>    asm
>>    {
>>        mov EAX,EAX;
>>        ... lots more instructions ...
>>    }
>>    version (bar) asm
>>    {
>>        mov EAX,EAX;
>>    }
>>    asm
>>    {
>>        ... even more instructions ...
>>        mov EAX,EAX;
>>    }
>> }
>>
> 
> 
> Since when does D guarantee that no code is inserted before/after asm blocks?

I think it was around the time that the mail service guaranteed that
they wouldn't leave a dead cat in your mailbox on every alternate Wednesday.

On Wed, Jul 15, 2009 at 12:24 PM, Daniel Keep<daniel.keep.lists@gmail.com> wrote:
>
> Tomas Lindquist Olsen wrote:
>> On Wed, Jul 15, 2009 at 2:18 AM, Walter Bright<newshound1@digitalmars.com> wrote:
>>> Don wrote:
>>>> In this case you may have a long function, with only a single instruction right in the middle which needs to be changed.
>>> void foo()
>>> {
>>>    asm
>>>    {
>>>        mov EAX,EAX;
>>>        ... lots more instructions ...
>>>    }
>>>    version (bar) asm
>>>    {
>>>        mov EAX,EAX;
>>>    }
>>>    asm
>>>    {
>>>        ... even more instructions ...
>>>        mov EAX,EAX;
>>>    }
>>> }
>>>
>>
>>
>> Since when does D guarantee that no code is inserted before/after asm blocks?
>
> I think it was around the time that the mail service guaranteed that
> they wouldn't leave a dead cat in your mailbox on every alternate Wednesday.
>


Funny.

But seriously, it actually takes some effort to make sure all
successive asm statements are merged into a single asm block when
generating code for LLVM.
The DMD frontend "unpacks" asm blocks, so each line is a seperate
AsmStatement, and with version blocks, you have to look into blocks as
well.

LLVM will restore registers etc. when an asm block is done!

And besides this is not in the spec, it might be implied, somehow, but it's not in the spec.

> The interesting question is is the construct itself the cause or the effect of incoherence and bugginess?

Maybe. But the real problem is, that you can't force the user to specify either a "yes" or "no" for a specific version/define identifier. He still could just forget about it.

Of course, you could always write something like:

version (DEBUGGING) {
} else version (NODEBUGGING) {
} else {
	static assert(false, "you forgot something!");
}

(Or something similar.)

But that's a bit annoying.

> Even so, you *can* use negation in D version statements:
> 
>     version (NO_DEBUGGING) {} else
>     {
>     ... debugging is on ...
>     }

Only marginally better than a #ifndef NO_DEBUGGING.

grauzone wrote:

> Walter Bright wrote:
>> Bill Baxter wrote:
>>> On Tue, Jul 14, 2009 at 5:13 PM, Walter Bright<newshound1@digitalmars.com> wrote:
>>>> Why do C and C++ (and D) make it difficult to do:
>>>>
>>>>   char *p;
>>>>   p |= 1;
>>>>
>>>> ? There's no implementation difficulty in accepting such and generating
>>>> correct code for it. It's purely a matter of making what is generally
>>>> considered to be bad practice harder to do. I've never heard anyone
>>>> argue
>>>> that this was a bad decision.
>>>
>>> I've never ever needed to do that, or been the slightest bit tempted to.  The operation doesn't make sense.  So I think the analogy is inappropos.
> 
> Often I wanted to write p &= ~3 in low level code. And that does make sense, because it aligns the pointer.
> 
>> The #ifndef NO_DEBUGGING is awful. The #ifndef __GNUC__ means compile for every unknown compiler ever, except gcc. Can't possibly be right.
> 
> The #ifndef NO_DEBUGGING causes the code to be compiled in debugging mode, if it isn't explicitly deactivated. This is a good thing. I think dmd should compile in debug mode too, and force the user to pass -nodebug to disable it.

So that reads as:

if not not actived then if not defined no debugging then do stuff

nice!

The idea is to make writing garbage more work than doing it right. But not make it impossible.

Lutger wrote:
> if not not actived then if not defined no debugging then do stuff

Ain't nobody doing nothing around here! Not no how, not no way! No sirree!

Daniel Keep wrote:
> I think it was around the time that the mail service guaranteed that
> they wouldn't leave a dead cat in your mailbox on every alternate Wednesday.

So that's why my mailbox stinks!

Tomas Lindquist Olsen wrote:
> And besides this is not in the spec, it might be implied, somehow, but
> it's not in the spec.

It never occurred to me that this might be necessary, but it obviously is.