void send(int *to,int *from, int count) {
   int n = (count + 7) / 8;

   switch(count % 8) {
      case 0:  do { *to++ = *from++;
      case 7:       *to++ = *from++;
      case 6:       *to++ = *from++;
      case 5:       *to++ = *from++;
      case 4:       *to++ = *from++;
      case 3:       *to++ = *from++;
      case 2:       *to++ = *from++;
      case 1:       *to++ = *from++;
               } while (--n > 0);
   }

Finally, Stroustrup asks the rhetorical question ``why would anyone
want to write something like this.''  Any guesses?!

thanks,

Why?  To quote a certain infamous C language hack :-) , `It looks exactly
like what an optimising compiler generates when it does loop unrolling.'

-Now, much to my surprise, this is not only valid C++, it is also valid C!
-Could some one please explain to me why this is so?

Could you explain why it shouldn't be?  "case" labels are just a
special form of label.  You can stick a label on most statements.

-It seems like the case 7-1 labels are actually nested inside the
-do {} while loop, and thus not in the scope of the switch

?? "Thus"?  Why would the labels go out of scope?  They're
definitely within the body of the switch.

-(should a break statement exit both the switch and the loop, or just one?!?!)

A "break" applies to whatever the innermost container is.  A "break"
between two of the "*to++ = *from++;" statements would exit the
do-while loop.

-Finally, Stroustrup asks the rhetorical question ``why would anyone
-want to write something like this.''  Any guesses?!

#define duff16(counter, block) \
  switch (counter & 0x0f) { \
   do \
   { \
     counter -= 16; \
     { block; } \
     case 15:   { block; } \
     case 14:   { block; } \
     case 13:   { block; } \
     case 12:   { block; } \
     case 11:   { block; } \
     case 10:   { block; } \
     case 9:    { block; } \
     case 8:    { block; } \
     case 7:    { block; } \
     case 6:    { block; } \
     case 5:    { block; } \
     case 4:    { block; } \
     case 3:    { block; } \
     case 2:    { block; } \
     case 1:    { block; } \
     case 0:    /* null statement */; \
   } while (counter >= 16); \
  }

  duff16(n, *to++ = *from++)

This only makes if the author knows he's got a hardware instruction pipeline
or cache that's no less than 8 and no more than 9 byte-copy instruction widths
long, and stuff executing out of the pipeline is a lot faster than if the
copies are interleaved with control transfers. Dollars to doughnuts this code
was written on a RISC machine.

(Gawrsh. That sounded just like one of the big boys on comp.arch tawkin'. I
think I'll cross-post over there just to see if I get shot down in flames...)

Break breaks out of the innermost construct that it could apply to, i.e.
"just one".

[ a do loop within a switch, with cases all through the do loop ]

This does not seem to be clearly covered in the latest dpANS (section
3.6). The issue is if it is legal *and defined* to jump into a loop.
While a case label behaves just like any other label, it's not clear
what a jump into a loop implies, and I don't see that the existing
standard is any clearer on the topic than the discussion was three years
ago.

Consider:
        i = 15;
        if (j < 10) goto BadMove;

        /* more code here */

        do {
          int i = 7;
          int myvect[400];
        BadMove: /* entry into block */
          myvect[300] = i;
          if (j < 5) return i;
        } while (j-- > 302);

  There was a lot of discussion of this and I don't see a clarification
in the standard as it stands. I think there are several possibilities:
  1) it's not allowed
  2) it's allowed, but the initializations at the start of the
        block don't take place. What does this imply about the
        block local variables?
  3) it's allowed and the block local variables are allocated and
        initialized as you would expect.
  4) it's allowed but the results are implementation dependent.

  In all other cases entry into a block causes allocation of the block
local (auto) variables. Initialization is performed at the time of
allocation. By allowing entry at any point the expected behavior is
unspecified.

Suggestion:
  Forget (1), it's there for completeness. Pick any of 2-4 and add it to
the standard NOW, as an editorial change. We talked about this three
years ago, it can hardly be considered a recent issue. I would not
suggest (1) because it breaks a lot of existing code, but I would be
happy to see a (5) "you can't jump into a block with local variables."

A couple of people have complained about the tone of my previous response
on this topic.  I meant it to be informative and minimal, i.e. requiring
some thought on the reader's part.  Since some have missed the point, let
me summarize the C style issue:

        Since the constructs are not forbidden by the C language
        rules, they are perforce permitted.  One should have an
        explicit rule to point at as being violated in order to
        think that the code is not valid.  "Intuition" is a lousy
        guide, particularly when it was formed by experience in
        other contexts (e.g. Pascal).

        Now, because of the demands made on one's understanding
        of the language, the cited code would be considered bad
        programming style IF what it did could be effectively
        accomplished in some other way.  As I pointed out in my
        previous posting on this, Duff's device does indeed have
        use in cases where other approaches fail, namely moving
        overlapping unaligned data.  Eventually we can all use
        memmove() for this, but not today.

   Since I posted my original question there has been a great deal of
abstract discussion about the relative merits of the loop unrolling
scheme.  The topic has piqued my curiousity, so I when ahead and
implemented a short test program, included below, to test Duff's
device against the ``ordinary for loop w/index variable'' technique.
See for yourself....  

After some quick testing I found that gcc 1.26 -O on a Sun 3 and a
Sequent Balance was pretty heavily in favor of the regular (non-Duff)
loop.  Your mileage may vary.  I realize that there may be other
tests, and if anyone has a better version, I'd like to see it!

Doug Schmidt
----------------------------------------
#include <sys/time.h>
#include <sys/resource.h>

double Start_Timer();
double Return_Elapsed_Time();

#define MAX_NUM 100000
int array1[MAX_NUM ];
int array2[MAX_NUM ];
int *A = array1, *B = array2;

main(int argc, char *argv[]) {
   double Elapsed_Time;
   int    Count = argc > 1 ? atoi(argv[1]) : MAX_NUM;
   int i;

   for (i = 0;i < Count ;i++) {
      array1[i] = i + 1;
      array2[i] = i;
   }

   printf("Starting Duff's device timing...\n");
   Start_Timer();

   {
      int n = (Count + 7) / 8;

      switch(Count % 8) {
         case 0:  do { *A++ = *B++;
         case 7:       *A++ = *B++;
         case 6:       *A++ = *B++;
         case 5:       *A++ = *B++;
         case 4:       *A++ = *B++;
         case 3:       *A++ = *B++;
         case 2:       *A++ = *B++;
         case 1:       *A++ = *B++;
                  } while (--n > 0);
      }
   }

   Elapsed_Time = Return_Elapsed_Time(0.0 );
   printf("Elapsed time = %.3f\n",Elapsed_Time);

   for (i = 0;i < Count ;i++) {
      if (array1[i] != array2[i]) {
         printf("Yow, problems at location %d!\n",i);
         break;
      }
   }

   for (i = 0;i < Count ;i++) {
      array1[i] = i + 1;
      array2[i] = i;
   }

   printf("Starting ordinary copy timing...\n");
   Start_Timer();

   for (i = 0;i < Count ;i++) {
      array1[i] = array2[i];
   }

   Elapsed_Time = Return_Elapsed_Time(0.0 );
   printf("Elapsed time = %.3f\n",Elapsed_Time);

   for (i = 0;i < Count ;i++) {
      if (array1[i] != array2[i]) {
         printf("Yow, problems at location %d!\n",i);
         break;
      }
   }

static struct rusage Old_Time;
static struct rusage New_Time;
static int    Timer_Set = 0;

#ifdef __STDC__
double Start_Timer(void)
#else
double Start_Timer()
#endif
{
   Timer_Set = 1;
   getrusage(RUSAGE_SELF,&Old_Time);        /* set starting process time */
   return(Old_Time.ru_utime.tv_sec + (Old_Time.ru_utime.tv_usec / 1000000.0));