Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #8566 > unrolled thread

do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0);

Back to article view | Back to comp.lang.c

Contents

  do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Francois Grieu <fgrieu@gmail.com> - 2011-07-22 08:49 +0200
    Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-07-22 00:58 -0700
    Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); gwowen <gwowen@gmail.com> - 2011-07-22 01:46 -0700
      Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); gazelle@shell.xmission.com (Kenny McCormack) - 2011-07-22 13:16 +0000
        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-07-22 06:35 -0700
        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); tom st denis <tom@iahu.ca> - 2011-07-22 08:37 -0700
        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Kenneth Brody <kenbrody@spamcop.net> - 2011-07-22 12:20 -0400
      Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Francois Grieu <fgrieu@gmail.com> - 2011-07-22 16:41 +0200
      Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Kenneth Brody <kenbrody@spamcop.net> - 2011-07-22 12:10 -0400
        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-22 19:39 +0100
        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); luser- -droog <mijoryx@yahoo.com> - 2011-07-22 21:05 -0700
          Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-07-23 13:24 +0100
            Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); gazelle@shell.xmission.com (Kenny McCormack) - 2011-07-23 15:11 +0000
            Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); "io_x" <a@b.c.invalid> - 2011-07-23 22:16 +0200
      Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Keith Thompson <kst-u@mib.org> - 2011-07-22 09:39 -0700
        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-07-22 22:30 +0300
          Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Keith Thompson <kst-u@mib.org> - 2011-07-22 13:15 -0700
            Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-07-23 01:02 +0300
              Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Jens Schweikhardt <usenet@schweikhardt.net> - 2011-07-23 13:06 +0000
                Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-07-23 16:51 +0300
                Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Kenneth Brody <kenbrody@spamcop.net> - 2011-07-25 12:06 -0400
                  Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Jens Schweikhardt <usenet@schweikhardt.net> - 2011-07-25 20:39 +0000
                    Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Kenneth Brody <kenbrody@spamcop.net> - 2011-07-26 10:43 -0400
                      Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Keith Thompson <kst-u@mib.org> - 2011-07-26 08:58 -0700
              Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Kenneth Brody <kenbrody@spamcop.net> - 2011-07-25 12:03 -0400
                Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-07-29 01:51 +0300
    Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); August Karlstrom <fusionfile@gmail.com> - 2011-07-22 12:15 +0200
      Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Francois Grieu <fgrieu@gmail.com> - 2011-07-22 16:11 +0200
        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); "Kleuskes & Moos" <kleuske@xs4all.nl> - 2011-07-22 08:14 -0700
          Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Thomas Boell <tboell@domain.invalid> - 2011-07-29 14:38 +0200
            Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); James Kuyper <jameskuyper@verizon.net> - 2011-07-29 09:23 -0400
              Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Thomas Boell <tboell@domain.invalid> - 2011-07-29 15:58 +0200
                Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); James Kuyper <jameskuyper@verizon.net> - 2011-07-29 10:42 -0400
                  Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Willem <willem@toad.stack.nl> - 2011-07-29 14:56 +0000
                    Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); James Kuyper <jameskuyper@verizon.net> - 2011-07-29 20:47 -0400
                      Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Willem <willem@toad.stack.nl> - 2011-07-30 09:12 +0000
                        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); James Kuyper <jameskuyper@verizon.net> - 2011-07-30 07:30 -0400
                  Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Thomas Boell <tboell@domain.invalid> - 2011-07-29 17:08 +0200
              Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Ali <abdulrazaq@gmail.com> - 2011-07-29 08:21 -0700
        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Kenneth Brody <kenbrody@spamcop.net> - 2011-07-22 12:24 -0400
          Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Francois Grieu <fgrieu@gmail.com> - 2011-07-25 10:34 +0200
            Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Willem <willem@toad.stack.nl> - 2011-07-25 08:54 +0000
              Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Keith Thompson <kst-u@mib.org> - 2011-07-25 09:08 -0700
                Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Willem <willem@toad.stack.nl> - 2011-07-25 16:52 +0000
                  Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Keith Thompson <kst-u@mib.org> - 2011-07-25 11:37 -0700
                    Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); cri@tiac.net (Richard Harter) - 2011-07-25 20:16 +0000
                    Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Francois Grieu <fgrieu@gmail.com> - 2011-07-26 10:23 +0200
                Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-26 00:49 -0700
                  Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); "io_x" <a@b.c.invalid> - 2011-07-26 11:16 +0200
                    Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-26 03:09 -0700
                      Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); "io_x" <a@b.c.invalid> - 2011-07-26 19:21 +0200
                        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-27 00:43 -0700
                          Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); "io_x" <a@b.c.invalid> - 2011-07-27 11:29 +0200
                            Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Keith Thompson <kst-u@mib.org> - 2011-07-27 08:30 -0700
                Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Kenneth Brody <kenbrody@spamcop.net> - 2011-07-26 10:39 -0400
        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Hallvard B Furuseth <h.b.furuseth@usit.uio.no> - 2011-07-26 12:37 +0200
          Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Francois Grieu <fgrieu@gmail.com> - 2011-07-26 12:52 +0200
            Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Hallvard B Furuseth <h.b.furuseth@usit.uio.no> - 2011-07-26 13:18 +0200
              Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Keith Thompson <kst-u@mib.org> - 2011-07-26 08:57 -0700
                Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Hallvard B Furuseth <h.b.furuseth@usit.uio.no> - 2011-07-27 10:18 +0200
    Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Ali <abdulrazaq@gmail.com> - 2011-07-23 15:38 -0700
      Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Ali <abdulrazaq@gmail.com> - 2011-07-24 09:25 -0700
        Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-07-26 01:01 -0700
      Re: do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0); gwowen <gwowen@gmail.com> - 2011-07-25 03:08 -0700

Page 1 of 4  [1] 2 3 4  Next page →

#8566 — do{switch(0)default:{/*break or continue*/;}/*cleanup*/}while(0);

I just came into a case where I could use this:

   do
   {
   // local declarations and initializations
     switch(0)default:
     {
     // bunch of if/else; within that:
     // - "break" performs cleanup;
     // - "continue" skips cleanup.
     /*..*/;
     }
   /*..*/; // cleanup
   }
   while(0);


[Notes: This is 'only' a way to avoid gotos. It places
restrictions on the use of other do/while/for/switch.
The second brace could be before default, but I find
the dummy switch idiom more recognizable that way.]


I'm looking for a classical reference on that construct,
like there is one for
<http://www.lysator.liu.se/c/duffs-device.html>


Or perhaps one for the similar:

   do
   {
   // local declarations and initializations
     switch(condition)
     {
     // leaving is done
     // - "break" performs cleanup;
     // - "continue" skips cleanup.
     case 0:
       /*..*/;
     case 1:
       /*..*/;
       ;
     }
   /*..*/; // cleanup
   }
   while(0);



TIA,

   Francois Grieu

[toc] | [next] | [standalone]

#8567

On Jul 22, 8:49 am, Francois Grieu <fgr...@gmail.com> wrote:
> I just came into a case where I could use this:
>
>    do
>    {
>    // local declarations and initializations
>      switch(0)default:
>      {
>      // bunch of if/else; within that:
>      // - "break" performs cleanup;
>      // - "continue" skips cleanup.
>      /*..*/;
>      }
>    /*..*/; // cleanup
>    }
>    while(0);
>
> [Notes: This is 'only' a way to avoid gotos. It places
> restrictions on the use of other do/while/for/switch.
> The second brace could be before default, but I find
> the dummy switch idiom more recognizable that way.]
>
> I'm looking for a classical reference on that construct,
> like there is one for
> <http://www.lysator.liu.se/c/duffs-device.html>
>
> Or perhaps one for the similar:
>
>    do
>    {
>    // local declarations and initializations
>      switch(condition)
>      {
>      // leaving is done
>      // - "break" performs cleanup;
>      // - "continue" skips cleanup.
>      case 0:
>        /*..*/;
>      case 1:
>        /*..*/;
>        ;
>      }
>    /*..*/; // cleanup
>    }
>    while(0);
>
> TIA,
>
>    Francois Grieu

I think the correct term is ''kludge'' and, frankly, i prefer gotos to
misappropriating break and continue keywords. But that's just my POV.

[toc] | [prev] | [next] | [standalone]

#8568

On Jul 22, 7:49 am, Francois Grieu <fgr...@gmail.com> wrote:

> [Notes: This is 'only' a way to avoid gotos. It places
> restrictions on the use of other do/while/for/switch.
> The second brace could be before default, but I find
> the dummy switch idiom more recognizable that way.]

If your algorithm is most naturally/clearly expressed using a 'goto',
use the 'goto' keyword.  If you bodge together something that is
LOGICALLY a 'goto' using keywords-that-aren't-goto -- simply to avoid
typing the word 'goto' because you've heard that 'goto' is bad -- then
whatever your reason was for avoiding 'goto' will still apply (only
now you've obfuscated your code for reasons you clearly don't
understand).

Half-remembered saws like "Goto considered harmful" will never beat
clear thinking.

[toc] | [prev] | [next] | [standalone]

#8574

In article <8e6cc974-51b0-48a4-8e11-2f3d7a498a00@y24g2000yqb.googlegroups.com>,
gwowen  <gwowen@gmail.com> wrote:
>On Jul 22, 7:49 am, Francois Grieu <fgr...@gmail.com> wrote:
>
>> [Notes: This is 'only' a way to avoid gotos. It places
>> restrictions on the use of other do/while/for/switch.
>> The second brace could be before default, but I find
>> the dummy switch idiom more recognizable that way.]
>
>If your algorithm is most naturally/clearly expressed using a 'goto',
>use the 'goto' keyword.  If you bodge together something that is
>LOGICALLY a 'goto' using keywords-that-aren't-goto -- simply to avoid
>typing the word 'goto' because you've heard that 'goto' is bad -- then
>whatever your reason was for avoiding 'goto' will still apply (only
>now you've obfuscated your code for reasons you clearly don't
>understand).
>
>Half-remembered saws like "Goto considered harmful" will never beat
>clear thinking.

Well, the obvious come-back to this is: What if I work in an environment
(i.e., company) where use of 'goto' is banned?  Then you are suggesting that
I get a new job?

-- 
"Remember when teachers, public employees, Planned Parenthood, NPR and PBS
crashed the stock market, wiped out half of our 401Ks, took trillions in
TARP money, spilled oil in the Gulf of Mexico, gave themselves billions in
bonuses, and paid no taxes? Yeah, me neither."

[toc] | [prev] | [next] | [standalone]

#8575

On Jul 22, 3:16 pm, gaze...@shell.xmission.com (Kenny McCormack)
wrote:
> In article <8e6cc974-51b0-48a4-8e11-2f3d7a498...@y24g2000yqb.googlegroups.com>,
>
>
>
>
>
>
>
>
>
> gwowen  <gwo...@gmail.com> wrote:
> >On Jul 22, 7:49 am, Francois Grieu <fgr...@gmail.com> wrote:
>
> >> [Notes: This is 'only' a way to avoid gotos. It places
> >> restrictions on the use of other do/while/for/switch.
> >> The second brace could be before default, but I find
> >> the dummy switch idiom more recognizable that way.]
>
> >If your algorithm is most naturally/clearly expressed using a 'goto',
> >use the 'goto' keyword.  If you bodge together something that is
> >LOGICALLY a 'goto' using keywords-that-aren't-goto -- simply to avoid
> >typing the word 'goto' because you've heard that 'goto' is bad -- then
> >whatever your reason was for avoiding 'goto' will still apply (only
> >now you've obfuscated your code for reasons you clearly don't
> >understand).
>
> >Half-remembered saws like "Goto considered harmful" will never beat
> >clear thinking.
>
> Well, the obvious come-back to this is: What if I work in an environment
> (i.e., company) where use of 'goto' is banned?  Then you are suggesting that
> I get a new job?

If you can, since obviously the management is _real_ shitty.

Otherwise heed the advice of Karlstrom, below or hide the goto's in a
bunch of macro's and sell them as innovative new approach to local
exception handing. The suits will never know the difference.

[toc] | [prev] | [next] | [standalone]

#8582

On Jul 22, 9:16 am, gaze...@shell.xmission.com (Kenny McCormack)
wrote:
> In article <8e6cc974-51b0-48a4-8e11-2f3d7a498...@y24g2000yqb.googlegroups.com>,
>
>
>
>
>
>
>
>
>
> gwowen  <gwo...@gmail.com> wrote:
> >On Jul 22, 7:49 am, Francois Grieu <fgr...@gmail.com> wrote:
>
> >> [Notes: This is 'only' a way to avoid gotos. It places
> >> restrictions on the use of other do/while/for/switch.
> >> The second brace could be before default, but I find
> >> the dummy switch idiom more recognizable that way.]
>
> >If your algorithm is most naturally/clearly expressed using a 'goto',
> >use the 'goto' keyword.  If you bodge together something that is
> >LOGICALLY a 'goto' using keywords-that-aren't-goto -- simply to avoid
> >typing the word 'goto' because you've heard that 'goto' is bad -- then
> >whatever your reason was for avoiding 'goto' will still apply (only
> >now you've obfuscated your code for reasons you clearly don't
> >understand).
>
> >Half-remembered saws like "Goto considered harmful" will never beat
> >clear thinking.
>
> Well, the obvious come-back to this is: What if I work in an environment
> (i.e., company) where use of 'goto' is banned?  Then you are suggesting that
> I get a new job?

Potentially yes [all else being weighed in] I'd start looking for a
new job.  At the point where management felt the need to micromanage
my syntax I'd consider it a hostile work environment.

As to the general theme, the only real uses for goto's are 1) cleanup
[exception handling] and 2) getting out of deeply nested loops
cleanly.  Any other use is probably a misuse [there will be other
cleaner ways to achieve the same thing].  The usual rhetoric about
"gotos are bad" is just that.  In the same way I can write

(a == 4) && somefunc();

instead of

if (a == 4) {
   somefunc();
}

While the former is less desirable it doesn't mean that && is a bad
operator, it means that you can use it in ways that aren't ideal.
Same with most other keywords and operators.

Tom

[toc] | [prev] | [next] | [standalone]

#8588

On 7/22/2011 9:16 AM, Kenny McCormack wrote:
> In article<8e6cc974-51b0-48a4-8e11-2f3d7a498a00@y24g2000yqb.googlegroups.com>,
> gwowen<gwowen@gmail.com>  wrote:
[...]
>> Half-remembered saws like "Goto considered harmful" will never beat
>> clear thinking.
>
> Well, the obvious come-back to this is: What if I work in an environment
> (i.e., company) where use of 'goto' is banned?  Then you are suggesting that
> I get a new job?

Perhaps this (tested on my compiler, but not necessarily guaranteed to work 
everywhere, nor be the most "efficient") code:

#define	PART1	got
#define	PART2(bre,ak)		bre##ak
#define	PART3(cont,inue)	PART2(cont,inue)
#define	FORBIDDEN(fruit)	PART3(PART1,o) fruit

The, simply use "FORBIDDEN(label)" where you need "goto label".

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#8580

On 2011/07/22 10:46, gwowen wrote :
> On Jul 22, 7:49 am, Francois Grieu<fgr...@gmail.com>  wrote:
>
>> [Notes: This is 'only' a way to avoid gotos. It places
>> restrictions on the use of other do/while/for/switch.
>> The second brace could be before default, but I find
>> the dummy switch idiom more recognizable that way.]
>
> If your algorithm is most naturally/clearly expressed using a 'goto',
> use the 'goto' keyword.  If you bodge together something that is
> LOGICALLY a 'goto' using keywords-that-aren't-goto -- simply to avoid
> typing the word 'goto' because you've heard that 'goto' is bad -- then
> whatever your reason was for avoiding 'goto' will still apply (only
> now you've obfuscated your code for reasons you clearly don't
> understand).
>
> Half-remembered saws like "Goto considered harmful" will never beat
> clear thinking.

I'm not the kind to *blindly* obey a coding recipe. I'm really looking 
at developing idioms that make the code clearer, without leaving the 
simplicity and portability of C for these other languages with 
try/catch. I do prefer:

   do
   {
   /*..*/
   if (errorcondition1)
      break;
   /*..*/
   if (errorcondition2)
      break;
   /*..*/
   if (errorcondition3)
      break;
   /*..*/
   }
   while(0);

to the alternatives using goto

   {
   /*..*/
   if (errorcondition1)
      goto lerr;
   /*..*/
   if (errorcondition2)

   /*..*/
   if (errorcondition3)
      goto lerr;
   /*..*/
lerr:;
   }

[one real drawback of this one is that you can't cut&paste that idiom 
twice in the same function without renaming the label, for C has no way 
to make labels local to a bloc]


or deep nesting
   {
   /*..*/
   if (!errorcondition1)
     {
     /*..*/
     if (!errorcondition2)
       {
       /*..*/
       if (!errorcondition3)
         {
         /*..*/
         }
       }
     }
   }

or a variable to remember that there has been an error, which makes the 
source code verbose and the executable perceptibly bigger and (rarely 
perceptibly) less efficient. I just can't stand that idea.


Sometime, the "dummy do break while" idiom is just not enough, so I'm 
considering "dummy do switch break continue while".


   Francois Grieu

[toc] | [prev] | [next] | [standalone]

#8587

On 7/22/2011 4:46 AM, gwowen wrote:
> On Jul 22, 7:49 am, Francois Grieu<fgr...@gmail.com>  wrote:
>
>> [Notes: This is 'only' a way to avoid gotos. It places
>> restrictions on the use of other do/while/for/switch.
>> The second brace could be before default, but I find
>> the dummy switch idiom more recognizable that way.]
>
> If your algorithm is most naturally/clearly expressed using a 'goto',
> use the 'goto' keyword.  If you bodge together something that is
> LOGICALLY a 'goto' using keywords-that-aren't-goto -- simply to avoid
> typing the word 'goto' because you've heard that 'goto' is bad -- then
> whatever your reason was for avoiding 'goto' will still apply (only
> now you've obfuscated your code for reasons you clearly don't
> understand).
>
> Half-remembered saws like "Goto considered harmful" will never beat
> clear thinking.

Perhaps he should read "'Goto Considered Harmful' Considered Harmful"?

     http://www.ecn.purdue.edu/ParaMount/papers/rubin87goto.pdf

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#8597

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Kenneth Brody <kenbrody@spamcop.net> writes:
>>Perhaps he should read "'Goto Considered Harmful' Considered Harmful"?
>
>       »Let X be an N x N matrix of integers. Write a program
>       that will print the number of the first all-zero row of
>       X, if any.«
>
>   untested:
<snip>
> static inline int is_all_zero
> ( int const * const row, int const cols )
> { result = 1;
>   for( register int col = 0; col != cols; ++col )
>   if( m[ col ]){ result = 0; col = cols; } /* I prefer »break« 
>     or »return« here, but I wanted to show that a version without
>     jumps is not that much more complicated. */
>   return result; }

You forced the use of a result variable and an assignment to the loop
control variable by insisting on a for loop.  I think this is more
natural as a while loop:

  int col = 0;
  while (col != cols && m[col]) col++;
  return col == cols;

> static inline int first_all_zero_row_number_of
> ( int const * const * const m,
>   int const rows, 
>   int const cols )
> { int result = -1;
>   for( int row = 0; row != rows; ++row )
>   if( is_all_zero( m[ row ]))
>   { result = row; row = rows; } /* I prefer »break« or »return« here,
>     but I wanted to show that a version without jumps is not that
>     much more complicated. */
>   return result; }

And I'd do the same here.

> int main( void )
> { int const first = first_all_zero_row_number_of( X, N, N );
>   if( first >= 0 )printf( "%d\n", first ); }
>

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#8623

On Jul 22, 11:10 am, Kenneth Brody <kenbr...@spamcop.net> wrote:
> On 7/22/2011 4:46 AM, gwowen wrote:
>
>
>
> > On Jul 22, 7:49 am, Francois Grieu<fgr...@gmail.com>  wrote:
>
> >> [Notes: This is 'only' a way to avoid gotos. It places
> >> restrictions on the use of other do/while/for/switch.
> >> The second brace could be before default, but I find
> >> the dummy switch idiom more recognizable that way.]
>
> > If your algorithm is most naturally/clearly expressed using a 'goto',
> > use the 'goto' keyword.  If you bodge together something that is
> > LOGICALLY a 'goto' using keywords-that-aren't-goto -- simply to avoid
> > typing the word 'goto' because you've heard that 'goto' is bad -- then
> > whatever your reason was for avoiding 'goto' will still apply (only
> > now you've obfuscated your code for reasons you clearly don't
> > understand).
>
> > Half-remembered saws like "Goto considered harmful" will never beat
> > clear thinking.
>
> Perhaps he should read "'Goto Considered Harmful' Considered Harmful"?
>
>      http://www.ecn.purdue.edu/ParaMount/papers/rubin87goto.pdf

Or Knuth's "Structured programming with go to statements", in the
collection
<<Literate Programming>>.

[toc] | [prev] | [next] | [standalone]

#8632

luser- -droog <mijoryx@yahoo.com> writes:

> On Jul 22, 11:10 am, Kenneth Brody <kenbr...@spamcop.net> wrote:
>> On 7/22/2011 4:46 AM, gwowen wrote:
>>
>> > On Jul 22, 7:49 am, Francois Grieu<fgr...@gmail.com>  wrote:
>>
>> >> [Notes: This is 'only' a way to avoid gotos. It places
>> >> restrictions on the use of other do/while/for/switch.
>> >> The second brace could be before default, but I find
>> >> the dummy switch idiom more recognizable that way.]
>>
>> > If your algorithm is most naturally/clearly expressed using a 'goto',
>> > use the 'goto' keyword.  If you bodge together something that is
>> > LOGICALLY a 'goto' using keywords-that-aren't-goto -- simply to avoid
>> > typing the word 'goto' because you've heard that 'goto' is bad -- then
>> > whatever your reason was for avoiding 'goto' will still apply (only
>> > now you've obfuscated your code for reasons you clearly don't
>> > understand).
>>
>> > Half-remembered saws like "Goto considered harmful" will never beat
>> > clear thinking.

Agreed.  Also, when you meet anyone who comes out with either "goto
considered harmful" or who dismissed the idea out of hand, ask them what
Dijkstra's argument actually *is* (i.e. ask them what it is they are
defending or rejecting).  You will be surprised by how many people have
a strong view of this paper without knowing what's in it.

>> Perhaps he should read "'Goto Considered Harmful' Considered Harmful"?
>>
>>      http://www.ecn.purdue.edu/ParaMount/papers/rubin87goto.pdf

Only if you want to see how not to counter the argument.

> Or Knuth's "Structured programming with go to statements", in the
> collection
> <<Literate Programming>>.

Which states:

  "This study focuses largely on two issues: (a) improved syntax for
  iterations and error exits, making it possible to write a larger class
  of programs clearly and efficiently without goto statements; (b)
  a methodology of program design, beginning with readable and correct,
  but possibly inefficient programs that are systematically transformed
  if necessary into efficient and correct, but possibly less readable
  code."

In other words it is not written as any sort of refutation of Dijkstra's
paper but aims to take the debate forward by finding ways to mitigate
the dangers posed by "the unbridled use of the goto" (Dijkstra's
phrase).

Later on Knuth writes:

  "some readers [...] are convinced that abolition of go to statements
  is merely a fad. and they may see this title and think, 'Aha! Knuth is
  rehabilitating the go to statement, and we can go back to our old ways
  of programming again.'"

This is crucial.  You can't understand Dijkstra's paper unless you put
it in context.  I remember the "old ways" of spaghetti code but most
recent programmers do not because, in essence, Dijkstra won the
argument; almost no one advocates the unbridled use of the goto anymore.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#8637

In article <0.33192282aeae12bc81f8.20110723132441BST.87bowlb2wm.fsf@bsb.me.uk>,
Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
...
>argument; almost no one advocates the unbridled use of the goto anymore.

Does anyone advocate the "unbridled" use of *anything*?

That was rhetorical, and the answer is, of course, no.  No one would
describe anything they do as "unbridled", so there really is no argument to
win here.

-- 
Religion is regarded by the common people as true,
	by the wise as foolish,
	and by the rulers as useful.

(Seneca the Younger, 65 AD)

[toc] | [prev] | [next] | [standalone]

#8640

"Ben Bacarisse" <ben.usenet@bsb.me.uk> ha scritto nel messaggio
news:0.33192282aeae12bc81f8.20110723132441BST.87bowlb2wm.fsf@bsb.me.uk...
> luser- -droog <mijoryx@yahoo.com> writes:

i don't know what 'unbridled' means i only know code happily jump here
and there forward and beckward without if() while() for() etc
and all is clear to me better of all your while() and for() if();
yes could be subjective, but than why all run well?

in all your theory or in my pc or in my mind, there is something wrong

[toc] | [prev] | [next] | [standalone]

#8590

gwowen <gwowen@gmail.com> writes:
> On Jul 22, 7:49 am, Francois Grieu <fgr...@gmail.com> wrote:
>> [Notes: This is 'only' a way to avoid gotos. It places
>> restrictions on the use of other do/while/for/switch.
>> The second brace could be before default, but I find
>> the dummy switch idiom more recognizable that way.]
>
> If your algorithm is most naturally/clearly expressed using a 'goto',
> use the 'goto' keyword.  If you bodge together something that is
> LOGICALLY a 'goto' using keywords-that-aren't-goto -- simply to avoid
> typing the word 'goto' because you've heard that 'goto' is bad -- then
> whatever your reason was for avoiding 'goto' will still apply (only
> now you've obfuscated your code for reasons you clearly don't
> understand).
>
> Half-remembered saws like "Goto considered harmful" will never beat
> clear thinking.

But break and continue aren't *just* disguised gotos.  They're
tightly restricted gotos.  They branch only to a specific point in
the code (the end of a certain construct), and unlike gotos they
can't branch to an earlier point in the code.

If you really want unmaintainable spaghetti code, backward gotos
are the way to do it.

I'm not saying that using a dummy "do { .. } while (0);" just to
be able to use "break" is a *great* idea (I agree it's a kludge),
but there are valid arguments in favor of it.

Another approach for the goto-phobic is to use a call-once function
so you can return from it.

Perhaps if C had a few more non-goto control structures (*named*
break and continue, and perhaps something to terminate a block),
such kludges wouldn't be needed.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#8599

Keith Thompson <kst-u@mib.org> writes:
> gwowen <gwowen@gmail.com> writes:
> > On Jul 22, 7:49 am, Francois Grieu <fgr...@gmail.com> wrote:
> >> [Notes: This is 'only' a way to avoid gotos. It places
> >> restrictions on the use of other do/while/for/switch.
> >> The second brace could be before default, but I find
> >> the dummy switch idiom more recognizable that way.]
> >
> > If your algorithm is most naturally/clearly expressed using a 'goto',
> > use the 'goto' keyword.  If you bodge together something that is
> > LOGICALLY a 'goto' using keywords-that-aren't-goto -- simply to avoid
> > typing the word 'goto' because you've heard that 'goto' is bad -- then
> > whatever your reason was for avoiding 'goto' will still apply (only
> > now you've obfuscated your code for reasons you clearly don't
> > understand).
> >
> > Half-remembered saws like "Goto considered harmful" will never beat
> > clear thinking.
> 
> But break and continue aren't *just* disguised gotos.  They're
> tightly restricted gotos.  They branch only to a specific point in
> the code (the end of a certain construct), and unlike gotos they
> can't branch to an earlier point in the code.

Continue can. And does. Always.

Phil
-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle." -- Matthew Vernon

[toc] | [prev] | [next] | [standalone]

#8602

Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> gwowen <gwowen@gmail.com> writes:
>> > On Jul 22, 7:49 am, Francois Grieu <fgr...@gmail.com> wrote:
>> >> [Notes: This is 'only' a way to avoid gotos. It places
>> >> restrictions on the use of other do/while/for/switch.
>> >> The second brace could be before default, but I find
>> >> the dummy switch idiom more recognizable that way.]
>> >
>> > If your algorithm is most naturally/clearly expressed using a 'goto',
>> > use the 'goto' keyword.  If you bodge together something that is
>> > LOGICALLY a 'goto' using keywords-that-aren't-goto -- simply to avoid
>> > typing the word 'goto' because you've heard that 'goto' is bad -- then
>> > whatever your reason was for avoiding 'goto' will still apply (only
>> > now you've obfuscated your code for reasons you clearly don't
>> > understand).
>> >
>> > Half-remembered saws like "Goto considered harmful" will never beat
>> > clear thinking.
>> 
>> But break and continue aren't *just* disguised gotos.  They're
>> tightly restricted gotos.  They branch only to a specific point in
>> the code (the end of a certain construct), and unlike gotos they
>> can't branch to an earlier point in the code.
>
> Continue can. And does. Always.

C99 6.8.6.2 (emphasis added):

    A continue statement causes a jump to the loop-continuation
    portion of the smallest enclosing iteration statement; that is,
    *to the end* of the loop body.

The (optional) subsequent branch to the top of the loop is the normal
operation of the loop itself, not a result of the continue statement.

This is particularly relevant for a continue in a do-while loop, which
causes the condition at the bottom to be re-evaluated.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#8612

Keith Thompson <kst-u@mib.org> writes:
> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
> > Keith Thompson <kst-u@mib.org> writes:
> >> gwowen <gwowen@gmail.com> writes:
> >> > On Jul 22, 7:49 am, Francois Grieu <fgr...@gmail.com> wrote:
> >> >> [Notes: This is 'only' a way to avoid gotos. It places
> >> >> restrictions on the use of other do/while/for/switch.
> >> >> The second brace could be before default, but I find
> >> >> the dummy switch idiom more recognizable that way.]
> >> >
> >> > If your algorithm is most naturally/clearly expressed using a 'goto',
> >> > use the 'goto' keyword.  If you bodge together something that is
> >> > LOGICALLY a 'goto' using keywords-that-aren't-goto -- simply to avoid
> >> > typing the word 'goto' because you've heard that 'goto' is bad -- then
> >> > whatever your reason was for avoiding 'goto' will still apply (only
> >> > now you've obfuscated your code for reasons you clearly don't
> >> > understand).
> >> >
> >> > Half-remembered saws like "Goto considered harmful" will never beat
> >> > clear thinking.
> >> 
> >> But break and continue aren't *just* disguised gotos.  They're
> >> tightly restricted gotos.  They branch only to a specific point in
> >> the code (the end of a certain construct), and unlike gotos they
> >> can't branch to an earlier point in the code.
> >
> > Continue can. And does. Always.

Yes, this is wrong. But I think only 1/3 wrong.
 
> C99 6.8.6.2 (emphasis added):
> 
>     A continue statement causes a jump to the loop-continuation
>     portion of the smallest enclosing iteration statement; that is,
>     *to the end* of the loop body.
> 
> The (optional) subsequent branch to the top of the loop is the normal
> operation of the loop itself, not a result of the continue statement.

Hmmm, I think I disagree. It is for a do {} while, certainly. However,
in the absense of a definition of "loop-continuation portion", For me
it's obviously expression_3 for a for loop (which is at the top) and
the condition for a while loop (which is at the top). Their
explication introduces more contradiction than explanation. So, to 
their "that is", I'd say "no, that isn't". It would have been better 
if they'd just used the final clause. Were I to be pedantic, I'd take 
issue with your '(optional)' is 2/3 wrong, as it's not optional in 
whiles and fors, only in dos.

> This is particularly relevant for a continue in a do-while loop, which
> causes the condition at the bottom to be re-evaluated.

Yup, you definitely got me there - good call. I dunno why, I was just 
in a 'for' train of thought, and a bit blinkered.

Phil
-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle." -- Matthew Vernon

[toc] | [prev] | [next] | [standalone]

#8634

Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote
	in <87ei1irn2s.fsf@bazspaz.fatphil.org>:
...
# Yes, this is wrong. But I think only 1/3 wrong.

The discovery of the truth quark! :-)

Regards,

	Jens
-- 
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)

[toc] | [prev] | [next] | [standalone]

#8636

Jens Schweikhardt <usenet@schweikhardt.net> writes:
> Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote
> 	in <87ei1irn2s.fsf@bazspaz.fatphil.org>:
> ...
> # Yes, this is wrong. But I think only 1/3 wrong.
> 
> The discovery of the truth quark! :-)

Don't be fooled by the simple fraction - sometimes I'm irrationally wrong!

Phil
-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle." -- Matthew Vernon

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web