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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#8683

On 2011/22/07 18:24, Kenneth Brody wrote:
> On 7/22/2011 10:11 AM, Francois Grieu wrote:
>> On 2011/22/07 12:15, August Karlstrom wrote:
>>> On 2011-07-22 08:49, Francois Grieu wrote:
>>>> I just came into a case where I could use this:
>>>>
>>>> do
> [... convoluted code that looks like "avoid goto at all costs" ...]
>>>> while(0);
>>>
>>> I must be missing something. Why can't you just do something like this?
>>>
>>> cleanup = 0;
> [... snip less-convoluted code ...]
>>
>> I *CAN*. But I'd rather not. I know that most if not all the compilers
>> I use
>> will not notice that the "cleanup" variable can be suppressed, and
>> knowing
>> that an extra variable exists and code is here to set and test it is
>> causing
>> me brain pain. I'd rather use two gotos (or a single goto and a deep
>> nesting
>> of ifs, which often will do the job), and get basically the "right"
>> executable.
>>
>> If I rationalize: on low-end platforms (PIC..) that I often use, RAM
>> size is
>> a few hundred bytes and program space a few kbytes, so every byte counts.
>
> Then I ask you, what's more important, avoiding "goto" or more efficient
> code?

There is no general answer. And I don't need one, as my technique
avoids goto without any extra variable. Best of both worlds :-)

>
>> Even on relatively powerful CPUs (Arm, x86) and when memory is not an
>> issue,
>> using one more register may force the shift of something into memory
>> rather
>> than in a register, or/and a little extra code could abruptly reduce
>> cache
>> efficiency, and in turn slow down things considerably. I bet I could
>> construct an articial demo where the suggested change increases execution
>> time/power draw quite perceptibly, say by 30%.
>
> I repeat my question above.

Same argument.

   Francois Grieu

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

#8684

Francois Grieu wrote:
) On 2011/22/07 18:24, Kenneth Brody wrote:
)> Then I ask you, what's more important, avoiding "goto" or more efficient
)> code?
)
) There is no general answer. And I don't need one, as my technique
) avoids goto without any extra variable. Best of both worlds :-)

Except that your code doesn't avoid "goto", it just writes in a more
convoluted way that avoids the use of the literal string g-o-t-o.

Also, your technique is a lot less clear than just using goto.

So, the advice is to just use goto in this case instead of trying
to adhere to 'never use goto' by the letter but not in spirit.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

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

#8697

Willem <willem@toad.stack.nl> writes:
> Francois Grieu wrote:
> ) On 2011/22/07 18:24, Kenneth Brody wrote:
> )> Then I ask you, what's more important, avoiding "goto" or more efficient
> )> code?
> )
> ) There is no general answer. And I don't need one, as my technique
> ) avoids goto without any extra variable. Best of both worlds :-)
>
> Except that your code doesn't avoid "goto", it just writes in a more
> convoluted way that avoids the use of the literal string g-o-t-o.

By that argument, all control structures are really gotos that
don't use the literal string g-o-t-o.

Obviously people differ on how far they're willing to go to avoid
"goto", but there are valid reasons to do so -- otherwise we'd be
using backward gotos instead of loops.

Somebody, I don't remember who it was, argued that the label, not
the "goto" statement", is the real problem.  When you see a goto
statement, you know what it does; just look for the correponding
label and you know where the control is going to flow.  If you see
a label, you don't easily know how you got there; you have to find
*all* goto statements with that label.

It's not what "disguised gotos" like "break" and "continue" do
that's important, it's what they *don't* do.  They don't branch to
arbitrary points in the code, and they don't branch backwards.

> Also, your technique is a lot less clear than just using goto.

That's (obviously) a matter of opinion.  If it's an accepted idiom
(and I think it is in some circles), then it's perfectly clear.

> So, the advice is to just use goto in this case instead of trying
> to adhere to 'never use goto' by the letter but not in spirit.

By "the advice", you mean "your advice", right?

-- 
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]

#8698

Keith Thompson wrote:
) Willem <willem@toad.stack.nl> writes:
)> Francois Grieu wrote:
)> ) On 2011/22/07 18:24, Kenneth Brody wrote:
)> )> Then I ask you, what's more important, avoiding "goto" or more efficient
)> )> code?
)> )
)> ) There is no general answer. And I don't need one, as my technique
)> ) avoids goto without any extra variable. Best of both worlds :-)
)>
)> Except that your code doesn't avoid "goto", it just writes in a more
)> convoluted way that avoids the use of the literal string g-o-t-o.
)
) By that argument, all control structures are really gotos that
) don't use the literal string g-o-t-o.

I disagree.  The technique the OP was using was nothing more than
disguising the goto as a continue or break, and disguising the jump
label as the closing brace on a do or switch block.

See below.

) Obviously people differ on how far they're willing to go to avoid
) "goto", but there are valid reasons to do so -- otherwise we'd be
) using backward gotos instead of loops.

What I'm arguing is that the OP is going way too far to avoid goto.

) Somebody, I don't remember who it was, argued that the label, not
) the "goto" statement", is the real problem.  When you see a goto
) statement, you know what it does; just look for the correponding
) label and you know where the control is going to flow.  If you see
) a label, you don't easily know how you got there; you have to find
) *all* goto statements with that label.

I agree.  And in the case of the technique the OP used, it is even worse.
He is not only using a label, he is using a label that looks like a closing
brace.

) It's not what "disguised gotos" like "break" and "continue" do
) that's important, it's what they *don't* do.  They don't branch to
) arbitrary points in the code, and they don't branch backwards.
)
)> Also, your technique is a lot less clear than just using goto.
)
) That's (obviously) a matter of opinion.  If it's an accepted idiom
) (and I think it is in some circles), then it's perfectly clear.

I don't think anyone in this group recognized the technique, much less
found it an accepted idiom.  This is the first mention of it being so,
and I wonder which circles it would be accepted in.

)> So, the advice is to just use goto in this case instead of trying
)> to adhere to 'never use goto' by the letter but not in spirit.
)
) By "the advice", you mean "your advice", right?

I used 'the advice' because others in this thread have been giving
the same advice, and therefore 'my advice' would be incorrect.

Apparently you take issue with this usage, but you don't explain why.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

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

#8699

Willem <willem@toad.stack.nl> writes:
> Keith Thompson wrote:
> ) Willem <willem@toad.stack.nl> writes:
> )> Francois Grieu wrote:
> )> ) On 2011/22/07 18:24, Kenneth Brody wrote:
> )> )> Then I ask you, what's more important, avoiding "goto" or more efficient
> )> )> code?
> )> )
> )> ) There is no general answer. And I don't need one, as my technique
> )> ) avoids goto without any extra variable. Best of both worlds :-)
> )>
> )> Except that your code doesn't avoid "goto", it just writes in a more
> )> convoluted way that avoids the use of the literal string g-o-t-o.
> )
> ) By that argument, all control structures are really gotos that
> ) don't use the literal string g-o-t-o.
>
> I disagree.  The technique the OP was using was nothing more than
> disguising the goto as a continue or break, and disguising the jump
> label as the closing brace on a do or switch block.
>
> See below.

The OP was emulating a feature that the language doesn't support
directly: defining an arbitrary block of code with a simple command
to bail out of it at any point.

C has built-in statements to terminate the execution of a loop
or of a switch statement.  It has no such statements for blocks.
The "do ... while (0)" trick is a way of emulating this nonexistent
statement.  I'm not saying it's not a bit ugly, or even that I'd
use it myself, but I can see the logic of it.

> ) Obviously people differ on how far they're willing to go to avoid
> ) "goto", but there are valid reasons to do so -- otherwise we'd be
> ) using backward gotos instead of loops.
>
> What I'm arguing is that the OP is going way too far to avoid goto.

Which is a perfectly valid opinion.  I'm not even sure I disagree.

> ) Somebody, I don't remember who it was, argued that the label, not
> ) the "goto" statement", is the real problem.  When you see a goto
> ) statement, you know what it does; just look for the correponding
> ) label and you know where the control is going to flow.  If you see
> ) a label, you don't easily know how you got there; you have to find
> ) *all* goto statements with that label.
>
> I agree.  And in the case of the technique the OP used, it is even worse.
> He is not only using a label, he is using a label that looks like a closing
> brace.

That's one way of looking at it.  Another is that he's creating
a well-defined lexical scope and using "break" or "continue" to
terminate execution of code in that scope.  We do the same thing
for loops; why not for simple blocks?

> ) It's not what "disguised gotos" like "break" and "continue" do
> ) that's important, it's what they *don't* do.  They don't branch to
> ) arbitrary points in the code, and they don't branch backwards.
> )
> )> Also, your technique is a lot less clear than just using goto.
> )
> ) That's (obviously) a matter of opinion.  If it's an accepted idiom
> ) (and I think it is in some circles), then it's perfectly clear.
>
> I don't think anyone in this group recognized the technique, much less
> found it an accepted idiom.  This is the first mention of it being so,
> and I wonder which circles it would be accepted in.

I've seen it in existing code.  I'm probably not at liberty to say
where.  Sorry.

> )> So, the advice is to just use goto in this case instead of trying
> )> to adhere to 'never use goto' by the letter but not in spirit.
> )
> ) By "the advice", you mean "your advice", right?
>
> I used 'the advice' because others in this thread have been giving
> the same advice, and therefore 'my advice' would be incorrect.
>
> Apparently you take issue with this usage, but you don't explain why.

Perhaps "our advice" would have been better?  Not a big deal.

-- 
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]

#8700

On Mon, 25 Jul 2011 11:37:21 -0700, Keith Thompson <kst-u@mib.org>
wrote:

>Willem <willem@toad.stack.nl> writes:
>> Keith Thompson wrote:
>> ) Willem <willem@toad.stack.nl> writes:
>> )> Francois Grieu wrote:
>> )> ) On 2011/22/07 18:24, Kenneth Brody wrote:
>> )> )> Then I ask you, what's more important, avoiding "goto" or more efficient
>> )> )> code?
>> )> )
>> )> ) There is no general answer. And I don't need one, as my technique
>> )> ) avoids goto without any extra variable. Best of both worlds :-)
>> )>
>> )> Except that your code doesn't avoid "goto", it just writes in a more
>> )> convoluted way that avoids the use of the literal string g-o-t-o.
>> )
>> ) By that argument, all control structures are really gotos that
>> ) don't use the literal string g-o-t-o.
>>
>> I disagree.  The technique the OP was using was nothing more than
>> disguising the goto as a continue or break, and disguising the jump
>> label as the closing brace on a do or switch block.
>>
>> See below.
>
>The OP was emulating a feature that the language doesn't support
>directly: defining an arbitrary block of code with a simple command
>to bail out of it at any point.
>
>C has built-in statements to terminate the execution of a loop
>or of a switch statement.  It has no such statements for blocks.
>The "do ... while (0)" trick is a way of emulating this nonexistent
>statement.  I'm not saying it's not a bit ugly, or even that I'd
>use it myself, but I can see the logic of it.
>
>> ) Obviously people differ on how far they're willing to go to avoid
>> ) "goto", but there are valid reasons to do so -- otherwise we'd be
>> ) using backward gotos instead of loops.
>>
>> What I'm arguing is that the OP is going way too far to avoid goto.
>
>Which is a perfectly valid opinion.  I'm not even sure I disagree.
>
>> ) Somebody, I don't remember who it was, argued that the label, not
>> ) the "goto" statement", is the real problem.  When you see a goto
>> ) statement, you know what it does; just look for the correponding
>> ) label and you know where the control is going to flow.  If you see
>> ) a label, you don't easily know how you got there; you have to find
>> ) *all* goto statements with that label.
>>
>> I agree.  And in the case of the technique the OP used, it is even worse.
>> He is not only using a label, he is using a label that looks like a closing
>> brace.
>
>That's one way of looking at it.  Another is that he's creating
>a well-defined lexical scope and using "break" or "continue" to
>terminate execution of code in that scope.  We do the same thing
>for loops; why not for simple blocks?
>
>> ) It's not what "disguised gotos" like "break" and "continue" do
>> ) that's important, it's what they *don't* do.  They don't branch to
>> ) arbitrary points in the code, and they don't branch backwards.
>> )
>> )> Also, your technique is a lot less clear than just using goto.
>> )
>> ) That's (obviously) a matter of opinion.  If it's an accepted idiom
>> ) (and I think it is in some circles), then it's perfectly clear.
>>
>> I don't think anyone in this group recognized the technique, much less
>> found it an accepted idiom.  This is the first mention of it being so,
>> and I wonder which circles it would be accepted in.
>
>I've seen it in existing code.  I'm probably not at liberty to say
>where.  Sorry.

I will admit to using the do {...break...} while 0 trick albeit
rarely.  The block and exitblock construct comes into play when there
is a filter situation, i.e., when a series of tests must be applied
and there is intervening code between tests.  (If there isn't any
intervening code one can use short circuit conditionals.)

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

#8721

On 2011/07/25 20:37, Keith Thompson wrote:
> The OP was emulating a feature that the language doesn't support
> directly: defining an arbitrary block of code with a simple command
> to bail out of it at any point.
>
> C has built-in statements to terminate the execution of a loop
> or of a switch statement.  It has no such statements for blocks.
> The "do ... while (0)" trick is a way of emulating this nonexistent
> statement.  I'm not saying it's not a bit ugly, or even that I'd
> use it myself, but I can see the logic of it.


I'm the OP, and I second Keith's nice wording of the intend.
This is an idiom to cleanly leave the appropriate of two nested
blocks.

It is often necessary, and the alternatives are
- goto + label;
- an extra variable determining if the code between the end of
   the two blocks shall be executed;
- duplicating the code between the end of the two blocks.

I think code duplication should be ruled out in most cases, for
maintainability reasons (as for object code compactness, many
compilers are good at catching that).

I viscerally hate extra variables, for their typical impact on code
size and in some occasions on speed; and because my ability to grasp
the working of a code section reduces quickly with the number of
variables. They eat scarce space in my short-term code-grasping memory.

To a lesser degree, a label's name has the same effect. And more
importantly it raise fear that some other code not immediately
visible could reach the label and invalidate my understanding of
the code's working.

Another benefit of not having a label is that it solves the issue of
the label's name. This is a benefit if the construct is reused,
especially in the same function, and for generated code (macro, or
use of C as an intermediary language).


   Francois Grieu

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

#8716

On Jul 25, 5:08 pm, Keith Thompson <ks...@mib.org> wrote:
> Willem <wil...@toad.stack.nl> writes:
> > Francois Grieu wrote:
> > ) On 2011/22/07 18:24, Kenneth Brody wrote:

> > )> Then I ask you, what's more important, avoiding "goto" or more efficient
> > )> code?

lawn-mowing or madrigal singing?


> > ) There is no general answer. And I don't need one, as my technique
> > ) avoids goto without any extra variable. Best of both worlds :-)

at the expense of really ugly and obscure code...

> > Except that your code doesn't avoid "goto", it just writes in a more
> > convoluted way that avoids the use of the literal string g-o-t-o.
>
> By that argument, all control structures are really gotos that
> don't use the literal string g-o-t-o.
>
> Obviously people differ on how far they're willing to go to avoid
> "goto", but there are valid reasons to do so -- otherwise we'd be
> using backward gotos instead of loops.
>
> Somebody, I don't remember who it was, argued that the label, not
> the "goto" statement", is the real problem.  When you see a goto
> statement, you know what it does; just look for the correponding
> label and you know where the control is going to flow.  If you see
> a label, you don't easily know how you got there; you have to find
> *all* goto statements with that label.
>
> It's not what "disguised gotos" like "break" and "continue" do
> that's important, it's what they *don't* do.  They don't branch to
> arbitrary points in the code, and they don't branch backwards.

it wasn't just the backwards jumps that were the problem. It was the
tangle's

For instance this is reasonably clear:-

loop:
   if (!finished)
   {
       do_more_stuff();
       goto loop;
   }

This less so

loop1:
   if (!finished)
   {
       do_first_stuff();
       if (reloop())
           goto loop1;
loop2:
       do_second_stuff();
       if (sudden_death())
           goto end;
       do_third_stuff()
       goto loop1;
    }

end:
    skip_many_pages();
    if (reprocess_event())
        goto loop2;

The full horror is jumping into a loop. A simple loop can be recoded
as a for or while. the second example needs a lot more analysis. The
above is much *more* structured than the typical code-de-jour. There
could be a dozen pages between the top and bottom of (maybe) a loop.
And those dozen pages whould be nested ten deep (unless the coder
thought indentation was for wimps).

When gotos are discussed people don't always realise the full horror
of old code.


> > Also, your technique is a lot less clear than just using goto.
>
> That's (obviously) a matter of opinion.  If it's an accepted idiom
> (and I think it is in some circles), then it's perfectly clear.

glad I'm not in those circles!


<snip>

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

#8723

"Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
For instance this is reasonably clear:-

loop:
   if (!finished)
   {
       do_more_stuff();
       goto loop;
   }

This less so

loop1:
   if (!finished)
   {
       do_first_stuff();
       if (reloop())
           goto loop1;
loop2:
       do_second_stuff();
       if (sudden_death())
           goto end;
       do_third_stuff()
       goto loop1;
    }

end:
    skip_many_pages();
    if (reprocess_event())
        goto loop2;

#i not have all your fears
#this "goto loop2;" seem to me a problem [i never wrote something as that]
#i there will write

# {renewVaribleLoop1and2(); goto loop1}
#or but with some problem
# {renewVaribleLoop1and2(); goto loop2}

#and write a end condition that exit function
#or program
#but i woudl write it in this way
----------
loop1:
          if(finished)  goto end;
          do_first_stuff();
          if (reloop()) goto loop1;
loop2:
       do_second_stuff();
       if(sudden_death()) goto   end;
       do_third_stuff()   goto loop1;
end:
...
finished=0;
...
goto loop1;
or
{inizilizesudden_death(); goto loop2}
---------

The full horror is jumping into a loop.

#yes, if one excluse the case the loop start in the middle as
#     i=0; goto  .b;
# .a: printf("%d\n", i);
#     ++i;
# .b: if(i<=someVar) goto .a;

A simple loop can be recoded
as a for or while. the second example needs a lot more analysis. The
above is much *more* structured than the typical code-de-jour. There
could be a dozen pages between the top and bottom of (maybe) a loop.
And those dozen pages whould be nested ten deep (unless the coder
thought indentation was for wimps).

When gotos are discussed people don't always realise the full horror
of old code.

#olds not used indentation and multi instruction for line with goto
#for reduce size of function and see all function
#with the right indentation...

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

#8724

On Jul 26, 10:16 am, "io_x" <a...@b.c.invalid> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel messaggio


> For instance this is reasonably clear:-
>
> loop:
>    if (!finished)
>    {
>        do_more_stuff();
>        goto loop;
>    }
>
> This less so
>
> loop1:
>    if (!finished)
>    {
>        do_first_stuff();
>        if (reloop())
>            goto loop1;
> loop2:
>        do_second_stuff();
>        if (sudden_death())
>            goto end;
>        do_third_stuff()
>        goto loop1;
>     }
>
> end:
>     skip_many_pages();
>     if (reprocess_event())
>         goto loop2;
>
> #i not have all your fears
> #this "goto loop2;" seem to me a problem [i never wrote something as that]

trust me I've seen stuff like this. If you restrict your gotos to
structures isomorphic to structured programs then they aren't too hard
to analyse. But they *do* need to be analysed and this is why a goto-
ful program is harder than a goto-less program (everything else being
equal!)


> #i there will write
>
> # {renewVaribleLoop1and2(); goto loop1}
> #or but with some problem
> # {renewVaribleLoop1and2(); goto loop2}
>
> #and write a end condition that exit function
> #or program

I don't know how you can be sure the two programs are equivalent.
Which is my point.


> #but i woudl write it in this way
> ----------
> loop1:
>           if(finished)  goto end;
>           do_first_stuff();
>           if (reloop()) goto loop1;
> loop2:
>        do_second_stuff();
>        if(sudden_death()) goto   end;
>        do_third_stuff()   goto loop1;
> end:
> ...
> finished=0;
> ...
> goto loop1;
> or
> {inizilizesudden_death(); goto loop2}
> ---------

I refer the honourable memeber to my response to his previous
question.



> The full horror is jumping into a loop.
>
> #yes, if one excluse the case the loop start in the middle as
> #     i=0; goto  .b;
> # .a: printf("%d\n", i);
> #     ++i;
> # .b: if(i<=someVar) goto .a;
>
> A simple loop can be recoded
> as a for or while. the second example needs a lot more analysis. The
> above is much *more* structured than the typical code-de-jour. There
> could be a dozen pages between the top and bottom of (maybe) a loop.
> And those dozen pages whould be nested ten deep (unless the coder
> thought indentation was for wimps).
>
> When gotos are discussed people don't always realise the full horror
> of old code.
>
> #olds not used indentation and multi instruction for line with goto
> #for reduce size of function and see all function
> #with the right indentation...

trust twelve page functions don't squish down onto one page no matter
how many statements you put on a line. The great advantage of gotos is
taht you dispense with the indentation. Hence enabling you to compress
the code even more.


loop1: if (!finished) goto end
do_first_stuff();
if (reloop())goto loop1;
loop2: do_second_stuff();
if (sudden_death()) goto end;
do_third_stuff()
goto loop1;
end: skip_many_pages();
if (reprocess_event()) goto loop2;

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

#8750

"Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
news:1baa3f01-091a-4fff-8242-2b2b7ee0d0d4@f20g2000yqm.googlegroups.com...
On Jul 26, 10:16 am, "io_x" <a...@b.c.invalid> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel messaggio


> For instance this is reasonably clear:-
>
> loop:
> if (!finished)
> {
> do_more_stuff();
> goto loop;
> }
>
> This less so
>
> loop1:
> if (!finished)
> {
> do_first_stuff();
> if (reloop())
> goto loop1;
> loop2:
> do_second_stuff();
> if (sudden_death())
> goto end;
> do_third_stuff()
> goto loop1;
> }
>
> end:
> skip_many_pages();
> if (reprocess_event())
> goto loop2;
>
> #i not have all your fears
> #this "goto loop2;" seem to me a problem [i never wrote something as that]

trust me I've seen stuff like this. If you restrict your gotos to
structures isomorphic to structured programs then they aren't too hard
to analyse. But they *do* need to be analysed and this is why a goto-
ful program is harder than a goto-less program (everything else being
equal!)

#are you saing that *not* goto programming has not need to be analysed
#where is the difference? with goto it is possible one know better
#of while() etc when and if code is execute

> #i there will write
>
> # {renewVaribleLoop1and2(); goto loop1}
> #or but with some problem
> # {renewVaribleLoop1and2(); goto loop2}
>
> #and write a end condition that exit function
> #or program

I don't know how you can be sure the two programs are equivalent.
Which is my point.

#i don't know if they are equivalent because functions has to be defined

> #but i woudl write it in this way
> ----------
> loop1:
> if(finished) goto end;
> do_first_stuff();
> if (reloop()) goto loop1;
> loop2:
> do_second_stuff();
> if(sudden_death()) goto end;
> do_third_stuff() goto loop1;
> end:
> ...
> finished=0;
> ...
> goto loop1;
> or
> {inizilizesudden_death(); goto loop2}
> ---------

I refer the honourable memeber to my response to his previous
question.

#what question? who is the "honourable memeber"?

> The full horror is jumping into a loop.
>
> #yes, if one excluse the case the loop start in the middle as
> # i=0; goto .b;
> # .a: printf("%d\n", i);
> # ++i;
> # .b: if(i<=someVar) goto .a;
>
> A simple loop can be recoded
> as a for or while. the second example needs a lot more analysis. The
> above is much *more* structured than the typical code-de-jour. There
> could be a dozen pages between the top and bottom of (maybe) a loop.
> And those dozen pages whould be nested ten deep (unless the coder
> thought indentation was for wimps).
>
> When gotos are discussed people don't always realise the full horror
> of old code.
>
> #olds not used indentation and multi instruction for line with goto
> #for reduce size of function and see all function
> #with the right indentation...

trust twelve page functions don't squish down onto one page no matter
how many statements you put on a line. The great advantage of gotos is
taht you dispense with the indentation. Hence enabling you to compress
the code even more.

#20 page of function for me are very rare
#99% function are long < my screen

loop1: if (!finished) goto end
do_first_stuff();
if (reloop())goto loop1;
loop2: do_second_stuff();
if (sudden_death()) goto end;
do_third_stuff()
goto loop1;
end: skip_many_pages();
if (reprocess_event()) goto loop2;

################################
loop1: if(finished) goto end;
       do_first_stuff();
       if (reloop())goto loop1;

loop2: do_second_stuff();
       if(sudden_death()) goto end;
       do_third_stuff()
       goto loop1;

end:   skip_many_pages();
       if(reprocess_event()) goto loop2;
/*
 this mean nothing;
 i would argue that first of "goto loop2" event just above:
 "finished" has to be set to "0"
 reloop() has to be reinezializated as the start of loop1
 sudden_death() has to be reinezializated as the start of loop1
 but it is only how i image can be
 because if is not so, i would rewrite the loop2 so

loop1: if(finished) goto here;
       do_first_stuff();
       if (reloop())goto loop1;
loop2: do_second_stuff();
       if(sudden_death()) goto here;
       do_third_stuff()
       goto loop1;

Loop2: do_second_stuff();
       if(sudden_death()) goto end;
       do_third_stuff()
here:  skip_many_pages();
       if(reprocess_event()) goto Loop2;
end:

*/
#################################

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

#8767

you couldn't switch to a more standard way of marking other people's
posts could you?

On Jul 26, 6:21 pm, "io_x" <a...@b.c.invalid> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel messaggionews:1baa3f01-091a-4fff-8242-2b2b7ee0d0d4@f20g2000yqm.googlegroups.com...
> On Jul 26, 10:16 am, "io_x" <a...@b.c.invalid> wrote:
> > "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel messaggio


> > For instance this is reasonably clear:-
>
> > loop:
> > if (!finished)
> > {
> > do_more_stuff();
> > goto loop;
> > }
>
> > This less so
>
> > loop1:
> > if (!finished)
> > {
> > do_first_stuff();
> > if (reloop())
> > goto loop1;
> > loop2:
> > do_second_stuff();
> > if (sudden_death())
> > goto end;
> > do_third_stuff()
> > goto loop1;
> > }
>
> > end:
> > skip_many_pages();
> > if (reprocess_event())
> > goto loop2;
>
> > #i not have all your fears
> > #this "goto loop2;" seem to me a problem [i never wrote something as that]

<snip>

> > #i there will write
>
> > # {renewVaribleLoop1and2(); goto loop1}
> > #or but with some problem
> > # {renewVaribleLoop1and2(); goto loop2}
>
> > #and write a end condition that exit function
> > #or program
>
> I don't know how you can be sure the two programs are equivalent.
> Which is my point.
>
> #i don't know if they are equivalent because functions has to be defined

exactly my point. To remove goto tangles you have to do quite deep
analysis of the code.



> > #but i woudl write it in this way
> > ----------
> > loop1:
> > if(finished) goto end;
> > do_first_stuff();
> > if (reloop()) goto loop1;
> > loop2:
> > do_second_stuff();
> > if(sudden_death()) goto end;
> > do_third_stuff() goto loop1;
> > end:
> > ...
> > finished=0;
> > ...
> > goto loop1;
> > or
> > {inizilizesudden_death(); goto loop2}
> > ---------
>
> I refer the honourable memeber to my response to his previous
> question.
>
> #what question? who is the "honourable memeber"?

It's a standard formula used in the UK Parliament. If a government
minister is being harried by repetitions (or variations) on the same
question he may respond in the manner above.

What I meant is that I have already addressed your point when I said
"how you can be sure the two programs are equivalent?"

<snip>

> > When gotos are discussed people don't always realise the full horror
> > of old code.
>
> > #olds not used indentation and multi instruction for line with goto
> > #for reduce size of function and see all function
> > #with the right indentation...
>
> trust [me] twelve page functions don't squish down onto one page no matter
> how many statements you put on a line. The great advantage of gotos is
> taht you dispense with the indentation. Hence enabling you to compress
> the code even more.

this was sarcasm.

This gets boring. If your gotos follow structured programming then
they are easy to follow. So why not use for, while, if etc?

Tangled goto-ful programs are hard to understand.

<snip tedious illustration of what I said>

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

#8771

"Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
news:67f1c7a5-97c0-41be-8500-1c6d7955680a@v7g2000vbk.googlegroups.com...
>you couldn't switch to a more standard way of marking other people's

>> I don't know how you can be sure the two programs are equivalent.
>> Which is my point.
>>
>> #i don't know if they are equivalent because functions has to be defined

>exactly my point. To remove goto tangles you have to do quite deep
>analysis of the code.

#if you change some function too, you have to do quite deep analysis too;
#if you change even a bit in a variable you have to do some analysis on that

#i remain in what i think
#yes compiler tricks prototipes, type sys, while() if() lint etc etc
#could help in find errors and can make fast who write;
#but one easy language scale complexity well and can outperform the
#compilers out, in structure programming;
#outperform the time to write something too [at end]
#
#not take all that very seriously i not have enough experience
#in programming area

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

#8782

"io_x" <a@b.c.invalid> writes:
> "Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
> news:67f1c7a5-97c0-41be-8500-1c6d7955680a@v7g2000vbk.googlegroups.com...
>>you couldn't switch to a more standard way of marking other people's
>
>>> I don't know how you can be sure the two programs are equivalent.
>>> Which is my point.
>>>
>>> #i don't know if they are equivalent because functions has to be defined
>
>>exactly my point. To remove goto tangles you have to do quite deep
>>analysis of the code.
>
> #if you change some function too, you have to do quite deep analysis too;
> #if you change even a bit in a variable you have to do some analysis on that
>
> #i remain in what i think
> #yes compiler tricks prototipes, type sys, while() if() lint etc etc
> #could help in find errors and can make fast who write;
> #but one easy language scale complexity well and can outperform the
> #compilers out, in structure programming;
> #outperform the time to write something too [at end]
> #
> #not take all that very seriously i not have enough experience
> #in programming area

"io_x": Quoted text is normally prefixed with "> ", and new text is
*not* normally prefixed with "#", or with anything else.  Whatever
news client you're using should do this for you automatically.
If yours doesn't, please find one that does.  Your headers indicate
that you're using Microsoft Outlook Express; either use a different
newsreader (strongly recommended), or look up something called
"OE-Quotefix".

Your articles are difficult enough to read without having to figure
out who wrote what.

-- 
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]

#8736

On 7/25/2011 12:08 PM, Keith Thompson wrote:
[...]
> Somebody, I don't remember who it was, argued that the label, not
> the "goto" statement", is the real problem.  When you see a goto
> statement, you know what it does; just look for the correponding
> label and you know where the control is going to flow.  If you see
> a label, you don't easily know how you got there; you have to find
> *all* goto statements with that label.
[...]

Which is why "comefrom" is much better, as there can be only one per label.

-- 
Kenneth Brody

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

#8727

Francois Grieu writes:
> On 2011/22/07 12:15, August Karlstrom wrote:
>> On 2011-07-22 08:49, Francois Grieu 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);

To my mind this is too clever and loses as much in clarity as avoiding
goto/label gains.  For a block/exit construct it overloads continue and
break arbitrarily: If you'd merely said you had a block construct where
continue and break exit with/without cleanup, I'd expect "continue" to
be the soft exit with cleanup, "break" to be the hard one without.

OTOH I've sometimes written

    switch (0) default: {
        ... if (...) break; ... 
    }

but I don't mind a few labels instead, with clear purposes like 'done:'
and 'abort:'.  With lots of jumps due to error checking, I tend to
structure C code as it would be without error checking, and then put the
error handling label(s) at the end.  Just avoid gotos when convenient
and keep the remaining ones readable.  E.g. don't goto both up and down
in the same function, which makes it hard to see if there is a hidden
loop.  Labels in the middle of a function make program flow harder to
see than those near the beginning/end.  Except an occasional end_loop:.

>> I must be missing something. Why can't you just do something like this?
>>
>> cleanup = 0;
>> if (c1) {
>> ...
>> cleanup = 1;
>> } else if (c2) {
>>
>> }...
>>
>> }
>> if (cleanup) {
>>
>> }
>
> I *CAN*. But I'd rather not. I know that most if not all the compilers I
> use will not notice that the "cleanup" variable can be suppressed,

Have you looked at the assembly output to check this?  You might be
right if you were talking about code like this:

int f(int a) {
    int c = 0;
    if (a < 0) {
	c = 1;
	a *= a;
    }
    g();
    if (c) {
	h();
    }
    return a;
}

because c might be either set or reset after executing g().  But actually
gcc -Os (optimize for space) handles even that fine, and treats it as

int f(int a) {
    if (a < 0) {
	a *= a;
	g();
	h();
    } else
	g();
    return a;
}

> and
> knowing that an extra variable exists and code is here to set and test
> it is causing me brain pain. I'd rather use two gotos (or a single goto
> and a deep nesting of ifs, which often will do the job), and get
> basically the "right" executable.

Up to here, this sounds like the itch for premature optimization.  In
those cases, just Get Over It.  Really.

> If I rationalize: on low-end platforms (PIC..) that I often use, RAM
> size is a few hundred bytes and program space a few kbytes, so every
> byte counts. Even on relatively powerful CPUs (Arm, x86) and when memory
> is not an issue, using one more register may force the shift of
> something into memory rather than in a register, or/and a little extra
> code could abruptly reduce cache efficiency, and in turn slow down
> things considerably. I bet I could construct an articial demo where the
> suggested change increases execution time/power draw quite perceptibly,
> say by 30%.

OK, that makes sense.

However, when you do decide to help the compiler, take care to check
that it actually was helpful or at least that it did no harm.  Probably
not a problem in his case, but it's not unusual for such "help" to be a
pessimization, if the code becomes harder to analyze for the compiler
than more natural code would be.  A classic example is code which walks
an array, a common operation which good compilers recognize and have
lots of tricks to deal with.  But if you instead helpfully start doing
pointer arithmetic on the array base/end, the compiler may give up
on trying those tricks and instead just compile your code step by step.

-- 
Hallvard

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

#8728

On 2011/07/26 12:37, Hallvard B Furuseth wrote:
> Francois Grieu writes:
>> On 2011/22/07 12:15, August Karlstrom wrote:
>>> On 2011-07-22 08:49, Francois Grieu 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);
>
> To my mind this is too clever and loses as much in clarity as avoiding
> goto/label gains.  For a block/exit construct it overloads continue and
> break arbitrarily: If you'd merely said you had a block construct where
> continue and break exit with/without cleanup, I'd expect "continue" to
> be the soft exit with cleanup, "break" to be the hard one without.
>
> OTOH I've sometimes written
>
>      switch (0) default: {
>          ... if (...) break; ...
>      }
>
> but I don't mind a few labels instead, with clear purposes like 'done:'
> and 'abort:'.  With lots of jumps due to error checking, I tend to
> structure C code as it would be without error checking, and then put the
> error handling label(s) at the end.  Just avoid gotos when convenient
> and keep the remaining ones readable.  E.g. don't goto both up and down
> in the same function, which makes it hard to see if there is a hidden
> loop.  Labels in the middle of a function make program flow harder to
> see than those near the beginning/end.  Except an occasional end_loop:.
>
>>> I must be missing something. Why can't you just do something like this?
>>>
>>> cleanup = 0;
>>> if (c1) {
>>> ...
>>> cleanup = 1;
>>> } else if (c2) {
>>>
>>> }...
>>>
>>> }
>>> if (cleanup) {
>>>
>>> }
>>
>> I *CAN*. But I'd rather not. I know that most if not all the compilers I
>> use will not notice that the "cleanup" variable can be suppressed,
>
> Have you looked at the assembly output to check this?

Yes, repeatedly on PIC18, 8051, ST7, ST7M; and recently on ARM,
though not with all optimizations, since they break the
vendor-supplied code frameword :-(
Not with x86/Amd64 compilers since Turbo C. I take your word
that gcc knows that trick. My "most if not all" was to account
for gcc, LLVM, and other leading edge compilers.

   Francois Grieu

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

#8729

Francois Grieu <fgrieu@gmail.com> writes:
>On 2011/07/26 12:37, Hallvard B Furuseth wrote:
>>Francois Grieu writes:
>>>On 2011/22/07 12:15, August Karlstrom wrote:
>>>> I must be missing something. Why can't you just do something like this?
>>>>
>>>> cleanup = 0;
>>>> if (c1) {
>>>> ...
>>>> cleanup = 1;
>>>> } else if (c2) {
>>>>
>>>> }...
>>>>
>>>> }
>>>> if (cleanup) {
>>>>
>>>> }
>>>
>>> I *CAN*. But I'd rather not. I know that most if not all the compilers I
>>> use will not notice that the "cleanup" variable can be suppressed,
>>
>> Have you looked at the assembly output to check this?
>
> Yes, repeatedly on PIC18, 8051, ST7, ST7M; and recently on ARM,
> though not with all optimizations, since they break the
> vendor-supplied code frameword :-(

Oh, yuck.  gcc without optimization also keeps the cleanup variable.

> Not with x86/Amd64 compilers since Turbo C. I take your word
> that gcc knows that trick. My "most if not all" was to account
> for gcc, LLVM, and other leading edge compilers.

-- 
Hallvard

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

#8742

Hallvard B Furuseth <h.b.furuseth@usit.uio.no> writes:
> Francois Grieu <fgrieu@gmail.com> writes:
>>On 2011/07/26 12:37, Hallvard B Furuseth wrote:
[...]
>>> Have you looked at the assembly output to check this?
>>
>> Yes, repeatedly on PIC18, 8051, ST7, ST7M; and recently on ARM,
>> though not with all optimizations, since they break the
>> vendor-supplied code frameword :-(
>
> Oh, yuck.  gcc without optimization also keeps the cleanup variable.

If you're running gcc without optimization, you're pretty much
telling the compiler that you don't care much about code quality.
There's not much point in complaining that unoptimized code is
unoptimized.

[...]

-- 
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]

#8769

Keith Thompson writes:
>Hallvard B Furuseth <h.b.furuseth@usit.uio.no> writes:
>>Francois Grieu <fgrieu@gmail.com> writes:
>>>On 2011/07/26 12:37, Hallvard B Furuseth wrote:
>>>> Have you looked at the assembly output to check this?
>>>
>>> Yes, repeatedly on PIC18, 8051, ST7, ST7M; and recently on ARM,
>>> though not with all optimizations, since they break the
>>> vendor-supplied code frameword :-(
>>
>> Oh, yuck.  gcc without optimization also keeps the cleanup variable.
>
> If you're running gcc without optimization, you're pretty much
> telling the compiler that you don't care much about code quality.
> There's not much point in complaining that unoptimized code is
> unoptimized.

Yeah.  The yuck was addressed to the vendor requirements, not to gcc.

-- 
Hallvard

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web