«

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

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.

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.

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);

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) {

}


August

--
The competent programmer is fully aware of the limited size of his own
skull. He therefore approaches his task with full humility, and avoids
clever tricks like the plague. --Edsger Dijkstra

In article <8e6cc974-51b0-48a4-8e11->,
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.

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."

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 suggestingthat
> 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.

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);
>
> 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, 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. 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%.

Francois Grieu

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

On Jul 22, 4:11*pm, Francois Grieu <fgr...@gmail.com> 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
> >> {
> >> // local declarations and initializations
> >> switch(0)default:
> >> {
> >> // bunch of if/else; within that:
> >> // - "break" performs cleanup;
> >> // - "continue" skips cleanup.
> >> /*..*/;
> >> }
> >> /*..*/; // cleanup
> >> }
> >> while(0);
>
> > 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, 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. 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%.
>
> * *Francois Grieu

If such finegrained control is needed, wouldn't you be better off
using assembly? Most uC targeted compilers i know of mix the two quite
well.

From what i read portability isn't a great concern, since you're quite
specific on the platform, so that can't be the issue.

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