Is there a modern programming language which has GOTO function in it? I know basic from a millenia ago and recently learned java, and well I hated OOP, but I could live with it if I had goto.
Name:
Anonymous2007-07-17 13:19 ID:OLxRAl5o
If you want to be succesful in programing, DONT USE GOTO
It makes hard to manage spigetti code. Just learn a real language. and no, java dosnt have goto.
Name:
Anonymous2007-07-17 13:20 ID:Hlzkdp1E
You can use goto in Python. It's considered very pythonic and is a recommended best practice.
>>2
It's even harder to read deeply indented code.
Java has goto, it's called break with a label.
Name:
Anonymous2007-07-17 16:35 ID:7SUedsqK
>>9
Don't tell him. Break with a label is one of the features that are useful, but not in the cases most programmers will want to use them. I'd allow break with label and goto, but in order to use them you'd have to declare:
#define _EXPERT_PROGRAMMER_
Name:
Anonymous2007-07-17 16:45 ID:qDjd3K0y
GOTO CONSIDERED DANGEROUS
Name:
Anonymous2007-07-17 16:52 ID:jg6dahoJ
>>7 Except if you use it in the form of tail calls, exceptions, or break/continue, for example.
thats not GOTO
Name:
Anonymous2007-07-17 16:54 ID:7SUedsqK
99.9% of the times goto has been used in the last 15 years, it has been misused. As for the 0.1% of the times where it was actually a good idea, none of the programmers who like to use goto would understand why.
In the past 4 years working in this business, I found goto useful for two times.
>>13
Agree. I've only used goto about 3 times in C++, two of those were out of pure laziness and the other one was an optimisation for speed critical code. The alternative for the third one would have been much worse.
Name:
Anonymous2007-07-18 19:14 ID:FkSXquQU
common lisp is what you want. A real, flexible object system, imperative and functional programming, logic, and macros. And it has goto!
(lambda (lambda x (lambda x (lambda x x) (lambda x (lambda (lambda x x) (lambda (lambda x (lambda x x) x) ) (lambda x x) lambda x) x )))
Does the same but is EXPERT PROGRAMMATION and is O(ln(ln(ln(ln(ln(ln(x ln(x)))))))).
True EXPERT PROGRAMMERS who've read SICP know that goto is unneccesary to construct an arbitrary program.
Name:
Anonymous2007-07-19 3:19 ID:eQovlAaX
>>20
I AM A CHAMPION PROGRAMMER, I HAVE READ K&R BECAUSE SICP IS A BEGINNER BOOK
Name:
Anonymous2007-07-19 4:58 ID:UjVITlR4
Any language with an inline assembler will allow you. Just chuck in a label and a JMP instruction. Then spend your life debugging.
Name:
Anonymous2007-07-19 5:14 ID:VK3c3dVw
Lambda, the ultimate goto
Name:
Anonymous2007-07-19 7:17 ID:QBsD/4JS
>>21
NO I DON'T GET THE IDEA BECAUSE YOUR CODE IS POORLY FORMATTED AND POOL-STILL-AIDS IS NOT USED, YOU DIDN'T TEST YOUR CODE, YOU ARE NOT AN EXPERT PROGRAMMER, YOU CAN'T USE IRC WELL, YOU CAN'T TAB COMPLETE, AND YOU CAN'T GOOGLE WHICH MEANS YOU'RE PROBABLY TOO BUSY JERKING OFF OR PLAYING VIDEO GAMES, DIE WELL, KID.
Name:
Anonymous2007-07-19 11:47 ID:84V+rEu/
Problem:
You have a function that does something, and in some cases it fails to do it, and there are some actions that need to be done after it failed.
I don't want to copy/paste code many times, and writing another function that handles the situation is out of question (writing #defines, too).
Solution: gotos. And i don't see any other solutions (in c, at least, and c++'s fancy throw/catch are the same thing as >>5 said). This is used alot in linux kernel.
int a(void){
int failed=do_something();
if(failed){
do_some_shit();
do_more_shit();
}
return 0;
}
int b(void){
int failed=do_something();
if(failed){
do_some_shit();
do_more_shit();
}
return 1;
}
int b(void){
int failed=do_something();
if(failed){
do_some_shit();
do_more_shit();
}
return 2;
}
great solution, really.
Name:
Anonymous2007-07-19 14:39 ID:QBsD/4JS
goto is good for freeing things up in C on error.
int alloc_some_things()
{
T *foo = malloc(sizeof(*foo));
if (foo != NULL)
{
foo->member = malloc(sizeof(*foo->member));
if (foo->member != NULL)
{
foo->another = malloc(sizeof(*foo->another));
if (foo->another != NULL)
{
return foo;
} else goto free_member;
} else goto free_foo;
} else goto failure;
free_member: free(foo->member);
free_foo: free(foo);
failure:
return NULL;
}
Name:
Anonymous2007-07-19 14:41 ID:QBsD/4JS
>>28
Although that *does* depend on how you want to deal with it. You could of course just use assert(foo = malloc(sizeof *foo)); and that will abort() on failure, but you probably don't want to do that in a library.
int alloc_some_things() {
T* foo;
void* member;
void* another;
foo = malloc(sizeof(*foo));
member = malloc(sizeof(*foo->member));
another = malloc(sizeof(*foo->another);
if(foo && member && another)
{
foo->member = member;
foo->another = another;
}
else
{
free(foo); // free is ok on NULL
free(member); // free is ok on NULL
free(another); // free is ok on NULL
}
return NULL;
}
or, if you like some wild macro action:
#define RETURNFREE(val) freevec(autofree); return val
int alloc_some_things() {
T* foo;
void* member;
void* another;
void* autofree[] = {foo, member, another};
foo = malloc(sizeof(*foo));
member = malloc(sizeof(*foo->member));
another = malloc(sizeof(*foo->another);
if(BIG NESTED STUFF)
{
........ ok ? then return
}
else
....
{
RETURNFREE
}
another big nesst.....
RETURNFREE! AGAIN YOU DONT HAVE TO REWRITE THE CODE
return NULL;
}
NOTE: I don't guarantee compilation on these code examples.
NOTE2: you can do this better with nested procedures, which the gnu extensions to C allow.
Name:
Anonymous2007-07-19 20:07 ID:bKSfkdkf
>>32
your first codepaste is an OK idea but I personally hate this style for the obvious reasons, in particular its not semantically equivalent to the original faggot.
Name:
Anonymous2007-07-19 20:38 ID:QBsD/4JS
>>31
sometimes it is not as simple as that, which is where goto has use. clearly my example did not communicate that to you. shrug
Name:
Anonymous2007-07-19 20:43 ID:QBsD/4JS
the funny thing is I never actually use goto and write it like >>31, but goto has its use where it is the least horrible thing to use for a given problem, like everything else. that's all I have left to say
Name:
Anonymous2007-07-19 22:39 ID:bKSfkdkf
>>34
that what ALL goto using faggots say to me, none of them can EVER produce an actual example of where goto is better.
MY CONCLUSION: GOTO FUCKING SUCKS DONT USE IT.
tl;dr:
>dealing with error situations that don't happen very often, in such a way that the error handling code doesn't clutter up the main code path.
>No, you've been brainwashed by CS people who thought that Niklaus Wirth actually knew what he was talking about. He didn't. He doesn't have a frigging clue.
Name:
Anonymous2007-07-19 23:45 ID:8wGLwsNB
dealing with error situations that don't happen very often, in such a way that the error handling code doesn't clutter up the main code path.
in that case, the code reads like regular exceptions, except all in the same function:
if(error)
goto error_handle
...
error_handle:
~~~
is similar if not almost equal to
if(error)
throw exception_a
...
catch (exception_a)
Name:
Anonymous2007-07-19 23:52 ID:bKSfkdkf
>>41
its C we are talking about here
dealing with errors happens at every single fucking stdlib function call, idiot.
Name:
Anonymous2007-07-19 23:58 ID:0hO7/Wyv
>>41
lol OKAY. Call it throw if it makes you feel so much better.
Name:
Anonymous2007-07-20 1:39 ID:oyT1fTO7
why do c weenies try so hard to come up with some other way to do things that would be much simpler and cleaner if they'd just use another function?
The three statements above form two tight intertwined loops. It's left as an excercise for the reader to rewrite the loops without using gotos. But you'll find that the way it's written above is the most concise and clearest.
>>51
DO YOU FUCKING KNOW ANY C AT ALL YOU FUCKING IDIOT?
for(a; b; c) { d; }
IS
a;
while(b) {
d;
c;
}
YOU FUCKING COCKSUCKER.
>>49,52
AWFUL INDENTATION, NO NEED FOR THESE PARENTHESES STUPID CODE ETC., GTFO.
FUCKING SAGE
Name:
Anonymous2007-07-20 11:50 ID:tNjyyvLd
>>53
indentation was for >>51, i wouldn't normally put it on more than one line like that.
and there are no unnecessary parentheses. && has higher precedence than =.
>>49 and >>52
Wrong. If shift returns true - causing read to be called - the code will call reduce before calling shift again.
Also
-short circuiting and casting pointer to bool is far less transparent than the goto version
-the if statement squeeze in the for loop isn't very readable either
Wrong. If shift returns true - causing read to be called - the code will call reduce before calling shift again. for( tok=getToken() ; shiftTok(tok) ? tok=getToken() : 1 || reduceTok(tok) ; );
-short circuiting and casting pointer to bool is far less transparent than the goto version
the "casting pointer to bool" is just nonsense. a bool in c99 is just an int. and the code in >>45 uses the pointer the same way.
>>64
It is not possible to write this code readably because it has no function.
The code just does 1 2 3 4 or 5 and jumps around.
This is not somthing which can possibly ever occur in real programming because you have an actual task to solve or algorithm to implement, so things are named properly and are done for a purpose.
That can be done easily enough with a simple FSM. It isn't exactly "equally efficient" as your code, but is a great deal more readable (at least to me). Here, the process is broken up into discrete steps which are separate from each other. It is easier to think about the process in terms of how to organize the steps in relation to each other, without having to mess about with what line of code each one is on.
And here's the same FSM but slightly less verbose. I've removed the "else" statements and allowed the cases to fall through each other. This lowers the readability, but uses less code. The readability now becomes more like your original example in >>64 while still requiring no goto statements.
else b() ??? Think you mean else c(). Otherwise, c(), and therefore d() never get called, and your program never terminates if we begin at a(). Though, I think you just typo'd.
Still, ignoring the error, it is functionally equivalent to >>64 , >>66 , and >>67
It would then be a matter of how the code can be optimized when compiling. Other than that it is just a matter of style and there isn't much of an argument either way.
Name:
Anonymous2007-07-22 4:08 ID:61PMylaX
>>73 PROTIP: do1(),do2(),... in most cases are note functions, but blocks of code, using same variables. Good job doing recursion, but it's too much work to send them all to your a(),b(),...
if (err = doOne()) goto oneFail;
if (err = doTwo()) goto twoFail;
if (err = doThree()) goto threeFail;
return 0;
threeFail:
undoTwo();
twoFail:
undoOne();
oneFail:
return err;
}
Yeah, sorry but you can pry my goto from my cold, dead fingers. Exceptions + RAII are a decent substitute for this, but if you're working in plain old C (and for a lot of small to medium scale applications C++ just adds too much baggage), the above idiom works quite nicely for me, ta.
Name:
Anonymous2007-07-22 13:52 ID:AGgx7XQ2
goto makes your computer explode, don't type it. OH SHI-