for ( blah; blah && done; blah ) {
blah;
if (error) {
zomg = true;
break;
}
blah;
if (error) {
zomg = true;
break;
}
blah;
if (error) {
zomg = true;
break;
}
}
if (zomg) {
fprintf( stderr, "zomg errors!" )
}
Name:
deitarion2005-02-23 5:57
I'm 50/50 on this one. Break and Continue are rather ugly compared to some of the more elegant syntactic constructs in use but they are still useful and at least they're less vague than an equivalent goto.
Name:
Christy McJesus!DcbLlAZi7U2005-02-23 10:12
break/continue does indeed provide the user with ways to bring back the evils of goto, as do exceptions. Technically it's always possible to structure your loop so you don't need a break, but in practice it's not worth the extra wrangling just for the sake of some elegance.
One would have to make a determined effort to use breaks, continues, exceptions etc to create bad code.
Name:
deitarion2005-02-23 20:15
I beg to differ. I find it a fun exercise to avoid break/continue. In fact, I've only ever used break once and that was in this Python loop.
for name, position in queuedFiles:
if checkCriteria(name):
print name, "queued at position", position
break
In fact, I later made it into a function called findNextWhatever() and replaced the break with a return so I guess that doesn't really count.
Actually, I find breaks more elegant than if(){if(){if(){ and 500 chars wide code. I think break (common), continue (rarely necessary), and goto (extreme situations like several nexted loops) are all acceptable, as long as you Don't Suck™, i.e. everything good if not misused.
Avoiding a simple break makes code harder and more annoying to write and read, IMHO
Name:
Anonymous2005-02-27 12:32
Breaks in the context of switch statements can sometimes be fugly, but switch statements can execute faster than long lines of if-else if-else for simple values, since the variable is only evaluated once, rather than at each if or else if statement. As >>10 said, if you are good and know what you are doing, then using break/continue isn't that bad.
Name:
Anonymous2005-02-27 14:05
With goto its possible to have to flip back and forth through multiple pages of code find where you are supposed to wind up. That only happes with break/continue if your loops contain multiple pages of code which is bad practice anyway. Also, goto gives you no restrictions on where the program flows, with break/continue you always know exactly where you should go next.
Name:
Anonymous2005-03-01 0:46
>>12
Suitably smart compilers (TM) nowadays handle chained and sequential ifs which test the same term and optimize it to the head of the chain or sequence.
It's not about execution speed, it's about reading and writing programs speed (business terms: development and maintenance)
Name:
Anonymous2005-03-11 6:57
>>16
However, unless they can actually convert it into a switch-like structure, they can't use jump tables to speed up execution. Generally, ten conditional branches are more expensive than one branch that takes a value from a memory address.
Name:
Anonymous2005-03-13 20:13
I wonder if compilers fully investigate the term first to see if repeatedly evaluating it would change its value.
Name:
JoeOsborn2005-03-13 20:38
If you ever need to use break or continue or goto rather than a simple return, your functions/methods are too big and you ned to refactor. You lose the meaning of the code in the irksome details of the control structures.
Name:
Anonymous2005-03-14 2:23
>>18
refactor into clunky functions as opposed to a few breaks?
Name:
Christy McJesus!DcbLlAZi7U2005-03-14 5:44
>>19
If your functions are clunky you're using the wrong language.
Name:
vans2005-03-14 7:30
>>19 , >>20
I suggest Io. http://www.iolanguage.com
Liberate yourself from clunkitude.
"Methods" sounds cooler than "functions" anyway...
Name:
Anonymous2005-03-14 9:09
From the Io FAQ:
-----
How production stable is it?
It hasn't been terribly well tested and isn't being used in any production environments that I know of. Please help us by testing things out!
-----
So no, try again in a few years when your language has matured a bit.
Name:
JoeOsborn2005-03-14 9:55
>>22
Try using the language a bit? Maybe you'll like it. The language isn't its implementation, and the guts are a mere 10 kloc of C code.
The FAQ is also a bit out of date -- all the built-in objects now have automated unit tests run on them, and the language is several years old by now.
That said, the language does constantly improve and become more consistent and therefore better. I present it as an example of a good language that can illustrate some excellent points wrt simplicity being fundamentally equal to power.
How many languages have you seen that can express exception handling try/catch style exclusively in the language itself? No VM support for it at all. And it can do it in 14 lines.
For languages that are both pretty-good and production stable, I'd assert Smalltalk and Objective-C. There's no reason anyone should have to do high-level programming in C++ or Java.
Name:
JoeOsborn2005-03-14 10:01
>>22
Whoops, quote a bit further in the faq:
----
I generally release fixes to any bugs found in a matter of days. The up side of Io being young language (born in April 2002) is that your help and input can have a significant effect on it's future.
----
I'm fairly active on the Io mailing list, and it's true that bug fixes come out very soon after bugs are reported.
Automated unit tests eh? D has those. They seem like a neat idea. Better than those annoying toy main functions I always find myself writing to test Java classes.
Ahhhhhh I can't wait until the end of my studies when I can stop using Java... at least until I get a job. "... require 3 years commercial experience in Java, VB, VB.NET, Windows NT..."
Anyone else feel depressed when they see all the pages and pages of job adverts that look like that?
Name:
JoeOsborn2005-03-14 17:22
>>25
I do, Christy, if it's any consolation. Higher level languages are still a few years off for business purposes... the inertia of static typing and the obsession with the waterfall model of software development are really quite strong. UML is evidence of that.
As for D -- I like it if only because some really awesome shmups have been implemented in it by Kenta Cho. rRootage, Noiz2sa, Torus Trooper, &c.
"How many languages have you seen that can express exception handling try/catch style exclusively in the language itself?"
hint, it starts with "common"
I pose the following problem to a group of EXPERT PROGRAMMERS: “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.”
Name:
Anonymous2007-06-16 19:02 ID:0/5TECUP
>>30
|[ var c : bool; var i : int
; c,i := true,0
; do c ∧ i ≠ N →
|[ var d : bool; var j : int
; d, j := true,0
; do d ∧ j ≠ N → d,j := X[i,j] = 0, j+1 od
; c,i := ¬d, i+1
]|
od
; if c → skip ⌷ ¬c → print (i–1) fi
]|
private boolean allZero(int[] a) {
for(int i: a) if(i != 0) return false;
return true;
}
//elsewhere, x contains the matrix
int i = zeroRow(x);
if(i >= 0) System.out.println(i);
The reason gotos are bad is they make you look for the target; return/break/etc on the other hand jump to an easily predictable location (raise doesn't really, but the way it's meant to be used you don't need to know where control flow continues).
>>30
for (int y = 0; y < rows; ++y) {
int all_zero = 1;
for (int x = 0; x < columns; ++x) {
if (matrix[x][y] != 0) all_zero = 0;
}
if (all_zero) return y;
}
for (int y = 0; y < rows; ++y) {
for (int x = 0; x < columns; ++x) {
if (matrix[x][y] != 0) goto next_row;
}
return y;
next_row:
}
Name:
Anonymous2010-05-26 4:34
Is break considered the same as goto?
Name:
Anonymous2010-05-26 4:41
Why use goto when you can inline your entire program and not have to execute an extra jump instruction? I think this should be an optimizing feature enabled in gcc -O2 called --funroll-programs.
>>47
Every control-flow instruction is the same.
If/Else is a goto, all loops are goto's, and so on. Most control structures are implemented using jumps by the compiler. In languages where control-structures are defined using macros (see: Common Lisp for an example), you'll see that GO is frequently used to define such macros rather straightforwardly. Exceptions are ... not (just a ) GOTO's. Exceptions are more complex things, which involve stack unwinding, executing cleanup handlers, and non-local transfer of control - at the low level, the instruction pointer is always directly changed, just like jump (goto) instructions do.
Use go(to) when it makes sense, but only use it when other control-flow structures won't suffice or they look too ugly. If the language permits you to create new control-flow structures with ease and you need a more unique one, feel free to write it and use it. Go(to) is only bad when you reach for it before reaching for more suitable control-flow structures. Knowing when and how to use it is another useful programming skill. I can't remember the last time I had to write a GO in a real CL program directly - I've only used it in macros. As for C, I sometimes use it for error cleanup/handling and breaking out of multiple nested tight loops without invoking additional comparisons tests(performance reasons).
Breaking out of such loops in CL is much easier done using standard special operators and doesn't really require GO at all, as for error handling - the condition system is one of the most advanced error handling mechanisms I've ever seen and one doesn't handle errors in the same crude way one does in C, so neither common GOTO usage case happens in CL - usually leaving it relegated to macros and building manual state machines.
Name:
Anonymous2010-05-26 5:43
Bitches don't know about my multi-process OS.
Enjoy your non-gotoing CLI.. OH, wait, that uses GOTOs as well!
Oh well, seems that GOTO haters are just full of hypocrisy.
In before people say it isn't, it is. Just because it isn't called GOTO doesn't mean it isn't a GOTO.
Name:
Anonymous2010-05-26 7:01
>>50
God damn Rob is a massive faggot.
That use of GOTO isn't spaghettifying in the slightest.
It creates a logical separation of code, something that IFs make ugly when chained more than 2 levels deep.
In fact, even in the "fix" Rob made was pretty god-awful.
Just as Linus said, GOTO can be used to minimize on code as well. Not to mention cycles.
I had a program where i could launch a input box from a hotkey to go to a label or run a function.
Using a return statement of some form is just a waste of cycles and code.
GOTO is a logical jump in this case. It goes to an unrelated section of code, runs it, then ends.
If i were to have let it return to where it was originally launched from, i would have needed to write about double, maybe triple the code to deal with exiting.
Simpler, more efficient code > structured and longer code.
All those OOP people are especially bad at this, creating stupidly large structures of code for the fucking simplest of things.
>>57
Does not generalize well and depends on error codes.
If your error codes are negative, positive or whatever, the sum can be unpredictable and this could even be exploitable by a malicious user. However, your idea can work in some cases. Here's a variation on it which will always work as long as success error code is 0 and any non-zero return code is an error:
>>59
If your ``zomg'' variable is an int (signed), and one return value is -2, and two others are 1 and 1 (all errors), zomg would add up to 0 (as an example), and that fprintf would never run.
Or even if it was a unsigned int, you could have the same error codes: 0xFFFFFFFE, 1,1 on 32bit machine) and it would still add up to 0 due to integer overflow. The issue will never happen if you use OR(|).