To save time ,just get to my point:I do not understand why such code below inside the switch ... case statement is allowed ,what is the point of do ... while...:

This example uses a mixin to implement a generic Duff's device for an arbitrary statement (in this case, the arbitrary statement is in bold). A nested function is generated as well as a delegate literal, these can be inlined by the compiler:
template duffs_device(alias id1, alias id2, alias s)
{
    void duff_loop()
    {
	if (id1 < id2)
	{
	    typeof(id1) n = (id2 - id1 + 7) / 8;
	    switch ((id2 - id1) % 8)
	    {
		case 0:        do {  s();
		case 7:              s();
		case 6:              s();
		case 5:              s();
		case 4:              s();
		case 3:              s();
		case 2:              s();
		case 1:              s();
				  } while (--n > 0);
	    }
	}
    }
}

void foo() { writefln("foo"); }

void test()
{
    int i = 1;
    int j = 11;

    mixin duffs_device!(i, j, delegate { foo(); } );
    duff_loop();	// executes foo() 10 times
}

Thanks in advance.

Regards,
Sam

Hello Sam,

> To save time ,just get to my point:I do not understand why such code
> below inside the switch ... case statement is allowed ,what is the
> point of do ... while...:

This is a classic C thing. The short explanation is that a switch is a conditional, many way goto and the labels can be *anywhere* in the body (except inside another switch). For the more in depth version Google "duff's device".

> 
> This example uses a mixin to implement a generic Duff's device for an
> arbitrary statement (in this case, the arbitrary statement is in
> bold).

BTW: where is this from?

> A nested function is generated as well as a delegate literal,
> these can be inlined by the compiler:
> template duffs_device(alias id1, alias id2, alias s)
> {
> void duff_loop()
> {
> if (id1 < id2)
> {
> typeof(id1) n = (id2 - id1 + 7) / 8;
> switch ((id2 - id1) % 8)
> {
> case 0:        do {  s();
> case 7:              s();
> case 6:              s();
> case 5:              s();
> case 4:              s();
> case 3:              s();
> case 2:              s();
> case 1:              s();
> } while (--n > 0);
> }
> }
> }
> }
> void foo() { writefln("foo"); }
> 
> void test()
> {
> int i = 1;
> int j = 11;
> mixin duffs_device!(i, j, delegate { foo(); } );
> duff_loop();	// executes foo() 10 times
> }

BCS wrote:
> Hello Sam,
> 
>> To save time ,just get to my point:I do not understand why such code below inside the switch ... case statement is allowed ,what is the point of do ... while...:
> 
> This is a classic C thing. The short explanation is that a switch is a conditional, many way goto and the labels can be *anywhere* in the body (except inside another switch). For the more in depth version Google "duff's device".
> 
>>
>> This example uses a mixin to implement a generic Duff's device for an arbitrary statement (in this case, the arbitrary statement is in bold).
> 
> BTW: where is this from?

I would guess from the D specs

http://www.digitalmars.com/d/1.0/template-mixin.html

Thanks so much for all your help!I am studying hard to *loop unrolling*.

> BTW: where is this from?
It is from the spec: http://www.digitalmars.com/d/1.0/template-mixin.html

BTW,is this Duff? http://groups.google.com/group/net.lang.c/msg/66008138e07aa94c

> http://groups.google.com/group/net.lang.c/msg/66008138e07aa94c

>Many people (even Brian Kernighan?) have said that the worst feature of C is that switches don't break automatically before each case label.

Oh god, that's from 1984, and even today we're struggling with this bullshit in the most modern dialect of C, D.

Hello grauzone,

>> http://groups.google.com/group/net.lang.c/msg/66008138e07aa94c
>> 
> Many people (even Brian Kernighan?) have said that the worst feature
> of C is that switches don't break automatically before each case
> label.
> 
> Oh god, that's from 1984, and even today we're struggling with this
> bullshit in the most modern dialect of C, D.
> 

I'm sorry, you don't have my sympathy on this one. There are to many place I've used fall throught to chuck it out.

BCS wrote:
> Hello grauzone,
> 
>>> http://groups.google.com/group/net.lang.c/msg/66008138e07aa94c
>>>
>> Many people (even Brian Kernighan?) have said that the worst feature
>> of C is that switches don't break automatically before each case
>> label.
>>
>> Oh god, that's from 1984, and even today we're struggling with this
>> bullshit in the most modern dialect of C, D.
>>
> 
> I'm sorry, you don't have my sympathy on this one. There are to many place I've used fall throught to chuck it out.

What kind of fall-throughs were these?

A:

case value1:
case value2:
case valueN:
	code1();
	break;

B:

case value1:
	code1();
case value2:
	code2();
	break;

Hello grauzone,

> BCS wrote:
> 
>> Hello grauzone,
>> 
>>>> http://groups.google.com/group/net.lang.c/msg/66008138e07aa94c
>>>> 
>>> Many people (even Brian Kernighan?) have said that the worst feature
>>> of C is that switches don't break automatically before each case
>>> label.
>>> 
>>> Oh god, that's from 1984, and even today we're struggling with this
>>> bullshit in the most modern dialect of C, D.
>>> 
>> I'm sorry, you don't have my sympathy on this one. There are to many
>> place I've used fall throught to chuck it out.
>> 
> What kind of fall-throughs were these?
> 
> A:
> 
> case value1:
> case value2:
> case valueN:
> code1();
> break;

I don't do that, I go with this form:

case value1, value2, valueN:
 code1();
 break;


case B, The most usefull case was where I used the switch as a "jump into the middle of this block of code" device.

> B:
> 
> case value1:
> code1();
> case value2:
> code2();
> break;

grauzone wrote:
> BCS wrote:
>> Hello grauzone,
>>
>>>> http://groups.google.com/group/net.lang.c/msg/66008138e07aa94c
>>>>
>>> Many people (even Brian Kernighan?) have said that the worst feature
>>> of C is that switches don't break automatically before each case
>>> label.
>>>
>>> Oh god, that's from 1984, and even today we're struggling with this
>>> bullshit in the most modern dialect of C, D.
>>>
>>
>> I'm sorry, you don't have my sympathy on this one. There are to many place I've used fall throught to chuck it out.
> 
> What kind of fall-throughs were these?
> 
> A:
> 
> case value1:
> case value2:
> case valueN:
>     code1();
>     break;
> 
> B:
> 
> case value1:
>     code1();
> case value2:
>     code2();
>     break;

The solution is to forbid fallthrough, and change the switch syntax:

switch(value) {
  case 1:
  case 2:
	// something
	break;
}

gives: Error, missing break at the end of case1.

But:

switch(value) {
  case 1, 2:
	// something
	break;
}

works as expected.

What's wrong with that?

>> What kind of fall-throughs were these?
>>
>> A:
>>
>> case value1:
>> case value2:
>> case valueN:
>>     code1();
>>     break;
>>
>> B:
>>
>> case value1:
>>     code1();
>> case value2:
>>     code2();
>>     break;
>
> The solution is to forbid fallthrough, and change the switch syntax:
>
> switch(value) {
>   case 1:
>   case 2:
> // something
> break;
> }
>
> gives: Error, missing break at the end of case1.
>
> But:
>
> switch(value) {
>   case 1, 2:
> // something
> break;
> }
>
> works as expected.
>
> What's wrong with that?

Doesn't support B :)

How about a warning instead?