I just used a goto!
-
I know "it's bad" and I will be shun by all good developers and rich employers for a thousands years... But I look at it.. I can't find of anything better.. mm, maybe a private inner function (i.e. function inside a method).... followed by misplaced return.... mm....
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
IMHO goto's can really offer a very clean solution when coding in C and you want to implement a sort of manual "finally" or "rollback" logic. Here is an example of code that is rolling back some state if something goes wrong. I like it because the intent is clear (there is a single label we are jumping to), I'm avoiding repeating cleanup code and I'm not introducing additional indentation levels that would be necessary with a structured approach - if we want to avoid multiple exit points.
static STATUS Android_PrepareAudioBuffers(void) {
STATUS errCode;
SLresult result;
_slBufferQueueItf = NULL;
/* Obtain interface to the AudioBufferQueue object */
result = (*_slRecorderInstance)->GetInterface(_slRecorderInstance, SL_IID_ANDROIDSIMPLEBUFFERQUEUE,
&_slBufferQueueItf);if( result != SL_RESULT_SUCCESS ) {
LOGE("%s - Error calling _slRecorderInstance->GetInterface(SL_IID_ANDROIDSIMPLEBUFFERQUEUE)", __func__);
errCode = S_ERR_OPENSLES_GET_INTERFACE;
goto fail_point;
}/* Register buffer-ready call-back */
result = (*_slBufferQueueItf)->RegisterCallback(_slBufferQueueItf, Android_RecordCallback, NULL);
if( result != SL_RESULT_SUCCESS ) {
LOGE("%s - Error calling _slBufferQueueItf->RegisterCallback()", __func__);
errCode = S_ERR_OPENSLES_REGISTER_CALLBACK;
goto fail_point;
}/* Specify an event mask to ensure the callback fires only when an audio buffer is full */
(*_slRecorderItf)->SetCallbackEventsMask(_slRecorderItf, SL_RECORDEVENT_BUFFER_FULL);_activeBuffIdx = 0;
/* Initialize buffer queue by enqueing all buffers at once.
When a buffer is filled, it is dequeued and the registered call-back is called
The buffer should be re-enqueued when processed to implement circular-buffer-list
functionality */int i;
for( i = 0; i < RECORD_BUFFER_COUNT; i++ ) {
result = (*_slBufferQueueItf)->Enqueue(_slBufferQueueItf, _buffers[i], _buffSz);
if( result != SL_RESULT_SUCCESS ) {
LOGE("%s - Error calling_slBufferQueueItf->Enqueue()", __func__);
errCode = S_ERR_OPENSLES_ENQUEUE_BUFF;
goto fail_point;
}
}
return S_OK;
fail_point:
// rollback state
if( _slBufferQueueItf ) {
(*_slBufferQueueItf)->RegisterCallback(_slBufferQueueItf, NULL, NULL);
(*_slBufferQueueItf)->Clear(_slBufferQueueItf);
_slBufferQueueItf = NULL;
}
return errCode;
} -
I know "it's bad" and I will be shun by all good developers and rich employers for a thousands years... But I look at it.. I can't find of anything better.. mm, maybe a private inner function (i.e. function inside a method).... followed by misplaced return.... mm....
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
C#
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Code sample would be nice. Because honestly, with the amount of control structures and object orientation support it provides I don't see a reason to use it. In fact. I work with C# since I was 24 years old (I am 36 now). Never had to use goto since (except from a few side projects in C). I used moro goto on imperative/structured/procedural languages like C, C++ and BASIC. So on purely objected oriented programming, whenever I thought of goto, it flashed a yellow light to me indicating I probably got some design patterns wrong. After some time I never got that yellow light again. I am not saying your use is not justified, I just can't wrap my head around a reason to use it.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
-
Code sample would be nice. Because honestly, with the amount of control structures and object orientation support it provides I don't see a reason to use it. In fact. I work with C# since I was 24 years old (I am 36 now). Never had to use goto since (except from a few side projects in C). I used moro goto on imperative/structured/procedural languages like C, C++ and BASIC. So on purely objected oriented programming, whenever I thought of goto, it flashed a yellow light to me indicating I probably got some design patterns wrong. After some time I never got that yellow light again. I am not saying your use is not justified, I just can't wrap my head around a reason to use it.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson ---- Our heads are round so our thoughts can change direction - Francis Picabia
I didn't use goto in the end.. had to write a public static function and used it instead....
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Which language? Probably a member of the "C" family. (C, C++, C#) Java killed goto with the "labeled break" which allows you to only "goto" the statement after a close curly brace.
C# used a static public function instead.. because it turned out...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I know "it's bad" and I will be shun by all good developers and rich employers for a thousands years... But I look at it.. I can't find of anything better.. mm, maybe a private inner function (i.e. function inside a method).... followed by misplaced return.... mm....
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I grew up on assembly code in the late 70's so I have no issues using goto's in my coding (C/C++ these days) when approriate. The idea that goto's are inherently bad is just bogus. There is a relatively small class of functions that are shorter and easier to understand when coded with a goto as opposed to the convoluted looping required to do the same thing. And being an old fart, shorter and easier to understand is a good thing! Especially when I have to add new features to code I wrote years ago.
-
The important thing with
gotois knowing when not to use it - which is most of the time. :laugh:Gotohas its place, but if you can use a structured loop or branch instead then your code is generally cleaner and more maintainable. But very occasionally, using agotomakes your code cleaner or much more efficient and (provided it's well documented) isn't a problem. It's a problem when it's used because they can: and teachers who introduce it early should be hung, drawn, and quartered (and I don't mean "well hung", "sketched", and "given an apartment").Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
I had a complicated set of "Insurance Premium Calculations" that was all GOTO based because of short-cut logic (If the person was < 25, skip this discount, etc) Ultimately, I used a while (1=1) { // setup initial values // instead of a goto, just a break; // insert 30 different logic checks, each with a break, after setting/adjusting rating parameters. break; } In the end, what's the difference? If there was only 1 label every goto could go to... And there was, then it is pretty much the same. (I was always hopeful nobody put a continue inside that loop!)
-
I know "it's bad" and I will be shun by all good developers and rich employers for a thousands years... But I look at it.. I can't find of anything better.. mm, maybe a private inner function (i.e. function inside a method).... followed by misplaced return.... mm....
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
As others have said, it's largely what Try Catch does. It has been pointed out though that using break and return in a method is really the same thing in a way. I've used on goto in my code, but based on that last sentence I plan to use them regularly though in the future, just always within a method. Instead of a catch -> return -> handle error, use a catch -> goto error handling at end of method -> end of method returns.
-
I know "it's bad" and I will be shun by all good developers and rich employers for a thousands years... But I look at it.. I can't find of anything better.. mm, maybe a private inner function (i.e. function inside a method).... followed by misplaced return.... mm....
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Does anyone remember when the use of gotos was first discussed? Does anyone remember the reason Dijkstra gave for their elimination? To me, I'm sorry, this thread seems somewhat juvenile
Gus Gustafson
-
I know "it's bad" and I will be shun by all good developers and rich employers for a thousands years... But I look at it.. I can't find of anything better.. mm, maybe a private inner function (i.e. function inside a method).... followed by misplaced return.... mm....
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
It's not bad, it's dangerous. But there's use cases where it's better than, let's say, 12 nested ifs. Did that myself, some COM-code which calls COM-methods in order I've placed gotos between method calls to directly jump to cleanup/deinitialization/error handling instead of a pile of if NoError=SomeMethod {if NoError=NextMethod). Way cleaner, but requires knowing what I'm doing. One wrong goto and I'm screwed.
-
also
for (;;) { break; }
do { break; } while(0);
that's just pretending. everyone knows that break is a goto. own it!
-
C#
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I know "it's bad" and I will be shun by all good developers and rich employers for a thousands years... But I look at it.. I can't find of anything better.. mm, maybe a private inner function (i.e. function inside a method).... followed by misplaced return.... mm....
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
there's nothing inherently wrong with goto, it's just another tool that works just like OP jump codes on a processor, jumping the running process to another memory location. It's quite handy too when the code structure gets nested too deep or you can't use recursion; it has it's place, and can keep the code more readable when done right. Unfortunately before structured programming came around that's all you had to move around, this was quite common in early version of BASICA or GW, where using subroutines wasn't as common. all this turned in to spaghetti code, earning procedural languages like Basic a bad rep (that stuck). the developers that grew up on these early languages unfortunately carried this forward using goto's everywhere, making it a nightmare to debug when something went wrong. My personal rules for goto's: *keep the function as short as possible so you can see the GOTO and the LABEL on the screen at the same time. *never use more than one redirection, ie multiple goto's to one label is fine if absolutely necessary, but never ever use multiple goto's and multiple labels, that just too much jumping around, and gets hard to follow. *does the code look cleaner and easier to follow with a goto or using check values with more if's? *can the process be restructured to avoid the deep nesting that caused a goto to be used in the first place. *keep the code as simple as possible. That being said, I've used goto maybe 5-10 times in my 20+ years developing, and I don't regret it.
