From 2019126639120411562 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,6bd75668e589c3cb X-Google-Attributes: gidf78e5,public From: dawks@best.com (phil dawkins) Subject: Re: PROPOSAL: Parameterized return/break/continue for nested loops Date: 1996/10/18 Message-ID: <547a2n$r68@nntp1.best.com>#1/1 X-Deja-AN: 190339854 references: <01bbb541$57db1d60$31d8cac6@chico> <53f2vu$fd0@panix.com> <325D288D.3713@ebc.ericsson.se> <01bbb6f8$a1740320$31d8cac6@chico> <01bbbaee$5dafb680$0a2920cc@landspeeder.delta.com> x-original-date: Fri, 18 Oct 1996 07:20:55 GMT organization: Best Internet Communications x-auth: PGPMoose V1.1 PGP comp.std.c++ reply-to: dawks@best.com newsgroups: comp.std.c++ originator: austern@isolde.mti.sgi.com sean@delta.com (Sean L. Palmer) wrote: >> HOWEVER, having said all that, I agree that the goto SHOULD be removed, >and >> replaced with (a) structured equivalent(s). That is why I propose >> essentially the naming of compound statements. The compound statement's >> name can be used (including scoping rules) by breaks or continues. [snip interesting "super" stuff] >More than one 'super' modifier could be added. An alternative syntax which >I actually think would be better is that break and continue (and iterate) >could be followed by a constant positive integral count which determined >how many levels of loops outward to apply it to, and defaulted to one (the >current loop). So 'break 1;' would be equivalent to the current 'break;', >and 'break 2;' would be equivalent to the 'super break' construct above. Oh no, this would be extremely sad and a maintenance nightmare. In assembler i would never write jmp $+15 rather than jmp label. At least labels are symbolic whereas offsets and nesting levels are not. How about turning it upside down and using labels for the goto statements as well and using a "comefrom" as the target of the goto? [label1:] goto target_label; [label2:] goto target_label; [comefrom:] target_label[:(label1,label2)]; This would document the process while still permitting regular backward compatible gotos. With my lack of knowledge of compiler technology this is probably fraught with major syntactic/semantic difficulties, but it seems neat (at least imho), and far prettier than templates although that's probably the wrong thing to say. I use gotos for clarity. Exceptions are fine, but sometimes too much hassle. Also, it's often not an exception but an expected and anticipated condition. I just want to avoid the clutter from repeated netsted "(workedOK && (condition))" type jobbies, when the obvious solution is to bale (C++ is intended for use by us mortals, right?). Good examples can be found in file io where the exist/create/open/verify/read or exist/open/verify/read sequence is often best served by a judicious isopened boolean and a transfer to a point that closes the file only if it has been opened. Complex memory management also works well with a boolean/goto pair. Other techniques seem to lead to code clutter or complex conditions within which the expected sequence is not applied (typical "never really tested 'cos we could never make it happen" code). phil. -- The world is divided into two sorts of people: those that believe the world is divided into two sorts of people, and those that don't. --- [ comp.std.c++ is moderated. To submit articles: Try just posting with your newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html Comments? mailto:std-c++-request@ncar.ucar.edu ]