Page 3 of 3
Re: goto instruction
Posted: Thu Mar 10, 2011 4:24 pm
by blobmiester
Simply don't use returns everywhere in a function.
From what I can see, your primary case for a return in the middle of a function is in case of an error. Check all parameters for errors before processing anything. and maybe a:
or similar.
Or better, you can have an inline function which will process your allocated variables:
Code: Select all
void foo(...)
{
void* buffer = NULL;
buffer = malloc(1337);
process(buffer);
free(buffer);
}
Then again, I'm not much of a C guru, as I'm more used to C++ and using shared_ptr / auto_ptr to handle freeing with their destructor.
On a side note, you can remove the if (x != NULL) checks before free calling free(x). The standard dictates that free performs no operation if x is null.
The free function causes the space pointed to by ptr to be deallocated, that is, made
available for further allocation. If ptr is a null pointer, no action occurs. Otherwise, if
the argument does not match a pointer earlier returned by a memory management
function, or if the space has been deallocated by a call to free or realloc, the
behavior is undefined.
Re: goto instruction
Posted: Thu Mar 10, 2011 11:19 pm
by Solar
bewing wrote:I was speaking in a more generic sense. It's the basic attitude that "I shouldn't code for what the computer does easily, I should code for what a human can read." That's not "good programming".
And I claim the opposite - that this is the basis of good programming. Making the code
also efficient is the basis of
excellent programming.
But it's a (somewhat sad) fact that, most of the time, readability trumps efficiency, and also most of the time, code claimed to be "efficient" isn't.
I claim that you are under the misimpression that C is a structured language.
I claim that, if you cannot
make the code you're writing "structured"
no matter the language, you shouldn't call yourself a programmer.
Re: goto instruction
Posted: Fri Mar 11, 2011 12:16 am
by Solar
sancho1980 wrote:And I fervently claim it SHOULD always be used to leave a function early. I find it absolutely confusing to see functions with several returns all over the place, because whenever later you need to add cleanup code to your function, you have to look at all of these returns.
{some really braindead code following}
Sancho, from your initial post I gathered you do this for a living. I strongly suggest you get a
basic course in how-to-code-properly, ask your boss to have some senior programmer give you regular code reviews, or
please, for the love of what's holy to you, stick to VisualBasic 6, because that's what you're coding.
Then again, at this point I call "hoax" on your whole thread. No-one who's doing this professionally can write
that bad.
Then again, given things I've seen already, maybe this
is possible. In that case, make sure none of your co-workers ever find out where you live.
Seriously, this is
ridiculous. Not only your use of goto, but just about
everything in that code sample of yours is as bad as it
could get.
Re: goto instruction
Posted: Fri Mar 11, 2011 1:17 am
by gerryg400
Solar, I fear (really, actually, fear) that this may be a pointless argument.
Re: goto instruction
Posted: Fri Mar 11, 2011 1:30 am
by sancho1980
Solar wrote:Seriously, this is ridiculous. Not only your use of goto, but just about everything in that code sample of yours is as bad as it could get.
May I ask you to have a look at my small os project at
http://code.google.com/p/mycrokernel/
It's not too big, and I'm advancing slowly as I'm doing this next to my job and a lot of other things, but it's a toy OS that boots the bare wire all by itself and implements a microkernel architecture with Virtual Time Round Robin scheduling. The assembly part is written with HLA (High Level Assembly), the rest is done in C. It doesn't do too much, except provide the foundation for pocess scheduling and an interface for a few system calls. Then it hooks up a few rudimentary processes (TTY and shell). Tell me if you can get so far with Visual Basic style programming.
Re: goto instruction
Posted: Fri Mar 11, 2011 1:34 am
by Solar
You intentionally don't get the point. End of discussion.
Re: goto instruction
Posted: Fri Mar 11, 2011 1:37 am
by Chandra
gerryg400 wrote:Solar, I fear (really, actually, fear) that this may be a pointless argument.
And I fear that this thread is going to hurt someone. Please stop it before it gets wilder.
Re: goto instruction
Posted: Fri Mar 11, 2011 2:08 am
by sancho1980
blobmiester wrote:Simply don't use returns everywhere in a function.From what I can see, your primary case for a return in the middle of a function is in case of an error.
Or if I'm done early with my function.
blobmiester wrote:Check all parameters for errors before processing anything.
That's right, but not enough. Errors might also occur when calling other functions in the course of your function.
If you take the time to look at my little project, you will see that nearly all functions take also an error parameter:
Code: Select all
void function (err_t *error)
{
//some code
finish:
return;
}
then I have a macro (terror for Test Error), like so:
Code: Select all
terror(x) x; if ((*error) != 0) goto finish;
And this all combines to something like
Code: Select all
void function (err_t *error)
{
dynamic_t *myVar = NULL;
//some code
terror(otherFunction(error))
//some code
finish:
if (myVar != NULL) {
free(myVar);
}
return;
}
blobmiester wrote:On a side note, you can remove the if (x != NULL) checks before free calling free(x). The standard dictates that free performs no operation if x is null.
I know
Re: goto instruction
Posted: Fri Mar 11, 2011 2:11 am
by quok
Chandra wrote:gerryg400 wrote:Solar, I fear (really, actually, fear) that this may be a pointless argument.
And I fear that this thread is going to hurt someone. Please stop it before it gets wilder.
I agree, let's stop right now.