|
|
03-15-2010, 03:59 AM
|
|
Re: So, I've gotta learn C ...
Quote:
Originally Posted by seebs
The point, NA, is that as always, you're demonstrating a complete inability to comprehend abstractions.
The example was a representation of real code -- everyone but you immediately saw the intent.
Here's a slightly more realistic example.
Code:
int
read_stuff_from_file(char *s, size_t avail, int *store) {
FILE *f;
int row_count, col_count, i, rc;
if (!s)
return 0;
f = fopen(s, "r");
if (!f)
return 0;
rc = fscanf(f, "%d", &row_count);
if (rc != 1) {
fprintf(stderr, "error: couldn't read row count.n");
goto fail;
}
rc = fscanf(f, "%d", &col_count);
if (rc != 1) {
fprintf(stderr, "error: couldn't read row count.n");
goto fail;
}
if (row_count < 1 || col_count < 1) {
fprintf(stderr, "Error: Row and column count must be >0.n");
goto fail;
}
if (row_count * col_count > avail) {
fprintf(stderr, "Only %d slots available, requested %dx%d matrix.n",
(int) avail, row_count, col_count);
goto fail;
}
for (i = 0; i < row_count * col_count; ++i) {
rc = fscanf(f, "%d", &store[i]);
if (rc != 1) {
fprintf(stderr, "Error trying to read item %d.n", i);
goto fail;
}
}
return i;
fail:
fclose(f);
return 0;
}
This case is the kind of code that was being implied -- code where there is work to do between each of the tests.
In general, yes, you can always remove gotos, but it costs storage, time, or both. I don't object to cases like the above, but I very rarely use them. My moderately large (for a one-person project) current project has a total of zero.
|
Seebs, never said that using functions didn't have a cost. Simply pointing out that the particular example cited could be restructured to eliminate the goto. Because certainly each of your tests after the fopen could be placed in a function.
Unless you are writing code for an embedded system (and even then it usually doesn't matter) the resources available are so plentiful that writing code for clarity and maintainability is far more important than saving a few cycles. There are exceptions to this but the vast majority of code written today could benefit far more from coding for clarity than coding for performance. Most machines these days spend most of their time idling which is why virtualization has become so popular.
I find it interesting that you still are so hungup on any post that comes from me that you just loose it and make it about the person and not the topic.
I must have had a huge impact on you.
|
03-15-2010, 04:13 AM
|
|
Forum Killer
|
|
|
|
Re: So, I've gotta learn C ...
Quote:
Originally Posted by naturalist.atheist
Unless you are writing code for an embedded system (and even then it usually doesn't matter) the resources available are so plentiful that writing code for clarity and maintainability is far more important than saving a few cycles.
|
Good thing the goto wasn't just more efficient but also simpler, more maintainable, and more readable, which was my point in displaying its utility for that situation.
Besides, you're ignoring your own previous point now.
|
03-15-2010, 04:28 AM
|
|
Re: So, I've gotta learn C ...
Quote:
Originally Posted by Corona688
Quote:
Originally Posted by naturalist.atheist
Unless you are writing code for an embedded system (and even then it usually doesn't matter) the resources available are so plentiful that writing code for clarity and maintainability is far more important than saving a few cycles.
|
Good thing the goto wasn't just more efficient but also simpler, more maintainable, and more readable, which was my point in displaying its utility for that situation.
Besides, you're ignoring your own previous point now.
|
I was responding to a seebs personality tick. Originally all I did was point out that the example code could be written without the goto. If you want to code with goto's then code with them. Certainly if you are used to coding that way then it will be easier. But simpler I am not sure. I think structured programming is the better way to go. If you code that way you will seldom ever find the need of a goto. I prefer top down structured programming. I've written hundreds of thousands of lines of code (maybe millions) in several flavors of curly bracket languages and can remember only a few instances for the need of a goto.
I personally think that using goto's leads to sloppy thinking. That it is usually just a hack to get around poorly thought out logic flow. There is a reason why it was so soundly condemned in the 70's and 80's. However most of the programmers working today do not remember how common it was to maintain snarled spaghetti code. Sometimes it was so bad that the only thing that could be done was to scrap it and start over. It was one of the reasons that software development had such a bad rap in the 80's and set the stage for the adoption of object oriented programming.
|
03-15-2010, 04:33 AM
|
|
The King of America
|
|
Join Date: Nov 2004
Location: The Devil's Kilometer
|
|
Re: So, I've gotta learn C ...
Uh oh.
Somebody else thinks they can win a fight with seebs about C.
Give it up now. Not only is seebs better than you, he's way fucking crazier than you.
__________________
Holy shit I need a federal grant to tag disaffected atheists and track them as they migrate around the net.
|
03-15-2010, 04:36 AM
|
|
Re: So, I've gotta learn C ...
Quote:
Originally Posted by rigorist
Uh oh.
Somebody else thinks they can win a fight with seebs about C.
Give it up now. Not only is seebs better than you, he's way fucking crazier than you.
|
Especially when seebs is fighting with himself. Because all I am saying is that it can be written without the goto. Apparently seebs has wet his pants over this.
|
03-15-2010, 04:39 AM
|
God Made Me A Skeptic
|
|
Join Date: Jul 2004
Location: Minnesota
|
|
Re: So, I've gotta learn C ...
It's not "about" the person, except that knowing the person explains the post.
The question came up of whether it was ever reasonable to use gotos. Corona688 gave an example of the structure of a function which would often be implemented using gotos, as illustrated. You missed the point completely, and instead of understanding the structure of the example, looked at the specific details -- and didn't understand what they were there for and what they meant.
Of course all those things could be implemented as functions. However, for them to be functions which return a success-or-failure value, they'd need to be passed pointers to the objects they were to modify, or those objects would need to be globals, and then you'd end up with something MUCH harder to maintain.
Use of goto as every control structure in a program certainly leads to sloppy thinking. Use of it when it's the right way to express a hunk of cleanup code does not, and refusal to use it in those circumstances, rather than leading to sloppy thinking, is lead to from sloppy thinking.
It's a tool. Use it when it works.
That said... Unless you someday develop the capacity for meaningful abstraction, I strongly recommend that you personally don't use goto. I don't need more spaghetti code in the world.
__________________
Hear me / and if I close my mind in fear / please pry it open
See me / and if my face becomes sincere / beware
Hold me / and when I start to come undone / stitch me together
Save me / and when you see me strut / remind me of what left this outlaw torn
|
03-15-2010, 04:41 AM
|
|
Re: So, I've gotta learn C ...
Quote:
Originally Posted by seebs
It's not "about" the person, except that knowing the person explains the post.
|
Man I had a big impact on you.
|
03-15-2010, 04:43 AM
|
|
Re: So, I've gotta learn C ...
Quote:
Originally Posted by seebs
Use of goto as every control structure in a program certainly leads to sloppy thinking. Use of it when it's the right way to express a hunk of cleanup code does not, and refusal to use it in those circumstances, rather than leading to sloppy thinking, is lead to from sloppy thinking.
It's a tool. Use it when it works.
That said... Unless you someday develop the capacity for meaningful abstraction, I strongly recommend that you personally don't use goto. I don't need more spaghetti code in the world.
|
seebs, I don't disagree. You are responding to some demon in your head and not what I posted. For you it appears it will always be about the person even though you don't actually know me at all.
|
03-15-2010, 04:43 AM
|
|
Sane (but only just)
|
|
Join Date: Oct 2007
Location: Somewhere to the left of sanity
Gender: Male
|
|
Re: So, I've gotta learn C ...
Quote:
Originally Posted by naturalist.atheist
Quote:
Originally Posted by seebs
The point, NA, is that as always, you're demonstrating a complete inability to comprehend abstractions.
The example was a representation of real code -- everyone but you immediately saw the intent.
Here's a slightly more realistic example.
Code:
int
read_stuff_from_file(char *s, size_t avail, int *store) {
FILE *f;
int row_count, col_count, i, rc;
if (!s)
return 0;
f = fopen(s, "r");
if (!f)
return 0;
rc = fscanf(f, "%d", &row_count);
if (rc != 1) {
fprintf(stderr, "error: couldn't read row count.n");
goto fail;
}
rc = fscanf(f, "%d", &col_count);
if (rc != 1) {
fprintf(stderr, "error: couldn't read row count.n");
goto fail;
}
if (row_count < 1 || col_count < 1) {
fprintf(stderr, "Error: Row and column count must be >0.n");
goto fail;
}
if (row_count * col_count > avail) {
fprintf(stderr, "Only %d slots available, requested %dx%d matrix.n",
(int) avail, row_count, col_count);
goto fail;
}
for (i = 0; i < row_count * col_count; ++i) {
rc = fscanf(f, "%d", &store[i]);
if (rc != 1) {
fprintf(stderr, "Error trying to read item %d.n", i);
goto fail;
}
}
return i;
fail:
fclose(f);
return 0;
}
This case is the kind of code that was being implied -- code where there is work to do between each of the tests.
In general, yes, you can always remove gotos, but it costs storage, time, or both. I don't object to cases like the above, but I very rarely use them. My moderately large (for a one-person project) current project has a total of zero.
|
Seebs, never said that using functions didn't have a cost. Simply pointing out that the particular example cited could be restructured to eliminate the goto. Because certainly each of your tests after the fopen could be placed in a function.
Unless you are writing code for an embedded system (and even then it usually doesn't matter) the resources available are so plentiful that writing code for clarity and maintainability is far more important than saving a few cycles. There are exceptions to this but the vast majority of code written today could benefit far more from coding for clarity than coding for performance. Most machines these days spend most of their time idling which is why virtualization has become so popular.
I find it interesting that you still are so hungup on any post that comes from me that you just loose it and make it about the person and not the topic.
I must have had a huge impact on you.
|
The point of seebs' example was to save duplicating code, not to save machine cycles. You should read Donald E Knuth's article "Structured Programming Using gotos" (reprinted in Literate Programming) to see what seebs is getting at. The article is old, but still worth reading.
Of course, one has to be careful when using goto to not skip essential initialisation or freeing of resources, and it doesn't work at all well in the presence of exceptions (which isn't a problem in C). If this were C++, using goto in this fashion would likely lead to disaster.
__________________
There you go with them negative waves ... Why can't you say something righteous and beautiful for a change?
|
03-15-2010, 04:50 AM
|
|
Re: So, I've gotta learn C ...
Quote:
Originally Posted by JamesBannon
Quote:
Originally Posted by naturalist.atheist
Quote:
Originally Posted by seebs
The point, NA, is that as always, you're demonstrating a complete inability to comprehend abstractions.
The example was a representation of real code -- everyone but you immediately saw the intent.
Here's a slightly more realistic example.
Code:
int
read_stuff_from_file(char *s, size_t avail, int *store) {
FILE *f;
int row_count, col_count, i, rc;
if (!s)
return 0;
f = fopen(s, "r");
if (!f)
return 0;
rc = fscanf(f, "%d", &row_count);
if (rc != 1) {
fprintf(stderr, "error: couldn't read row count.n");
goto fail;
}
rc = fscanf(f, "%d", &col_count);
if (rc != 1) {
fprintf(stderr, "error: couldn't read row count.n");
goto fail;
}
if (row_count < 1 || col_count < 1) {
fprintf(stderr, "Error: Row and column count must be >0.n");
goto fail;
}
if (row_count * col_count > avail) {
fprintf(stderr, "Only %d slots available, requested %dx%d matrix.n",
(int) avail, row_count, col_count);
goto fail;
}
for (i = 0; i < row_count * col_count; ++i) {
rc = fscanf(f, "%d", &store[i]);
if (rc != 1) {
fprintf(stderr, "Error trying to read item %d.n", i);
goto fail;
}
}
return i;
fail:
fclose(f);
return 0;
}
This case is the kind of code that was being implied -- code where there is work to do between each of the tests.
In general, yes, you can always remove gotos, but it costs storage, time, or both. I don't object to cases like the above, but I very rarely use them. My moderately large (for a one-person project) current project has a total of zero.
|
Seebs, never said that using functions didn't have a cost. Simply pointing out that the particular example cited could be restructured to eliminate the goto. Because certainly each of your tests after the fopen could be placed in a function.
Unless you are writing code for an embedded system (and even then it usually doesn't matter) the resources available are so plentiful that writing code for clarity and maintainability is far more important than saving a few cycles. There are exceptions to this but the vast majority of code written today could benefit far more from coding for clarity than coding for performance. Most machines these days spend most of their time idling which is why virtualization has become so popular.
I find it interesting that you still are so hungup on any post that comes from me that you just loose it and make it about the person and not the topic.
I must have had a huge impact on you.
|
The point of seebs' example was to save duplicating code, not to save machine cycles. You should read Donald E Knuth's article "Structured Programming Using gotos" (reprinted in Literate Programming) to see what seebs is getting at. The article is old, but still worth reading.
Of course, one has to be careful when using goto to not skip essential initialisation or freeing of resources, and it doesn't work at all well in the presence of exceptions (which isn't a problem in C). If this were C++, using goto in this fashion would likely lead to disaster.
|
In the example I fail to see how it would save duplicate code. Could you point it out?
Also I am aware that SP doesn't forbid goto's but if you actually practice SP they become superfluous for the most part. You very, very, very seldom ever need them. (This of course does depend on the language. In assembler it would be impossible to code a program of any size without the goto equivalent, jmp.)
If you want to use goto's then do it. I really don't care. Use as many as you like.
|
03-15-2010, 05:02 AM
|
|
Forum Killer
|
|
|
|
Re: So, I've gotta learn C ...
Quote:
Originally Posted by naturalist.atheist
I was responding to a seebs personality tick. Originally all I did was point out that the example code could be written without the goto.
|
...and in doing so, completely missed the point of the exercise. If the code was even marginally more complex you couldn't do it your way at all, and doing it without gotos would make it a great deal more complex, redundant, and error-prone while also being less readable. The only remotely similar structure is the fundamentally messier try/catch, which will allow you to leap from your code into places you didn't define at all and is unavailable in C anyway.
|
03-15-2010, 05:14 AM
|
|
Re: So, I've gotta learn C ...
Quote:
Originally Posted by Corona688
Quote:
Originally Posted by naturalist.atheist
I was responding to a seebs personality tick. Originally all I did was point out that the example code could be written without the goto.
|
...and in doing so, completely missed the point of the exercise. If the code was even marginally more complex you couldn't do it your way at all, and doing it without gotos would make it a great deal more complex and less readable.
|
What I saw was someone positing an example of the use of goto's to somehow make code easier to understand. I looked at that code and saw that eliminating the goto's made it easier to see what the code was doing in terms of logic flow. The goto's made it look more complicated than it actually was.
That is not to say that there do not exist some good examples of the use of goto's to simplify code, but none have been presented here. Even so, I have written a line of code or two and can tell you from personal experience that you will very seldom encounter a situation where the use or non-use of a goto was not more a matter of personal taste than something that made a critical difference in simplifying the code. It just doesn't happen that often. It happens so infrequently that going by the general rule of avoiding goto's is good advice. Because when the time does comes when goto is needed it will be obvious and you will have a good reason to use it.
|
03-15-2010, 05:23 AM
|
|
Forum Killer
|
|
|
|
Re: So, I've gotta learn C ...
Quote:
Originally Posted by naturalist.atheist
What I saw was someone positing an example of the use of goto's to somehow make code easier to understand. I looked at that code and saw that eliminating the goto's made it easier to see what the code was doing in terms of logic flow. The goto's made it look more complicated than it actually was.
|
Good thing we've corrected that impression, then. Your method's been explained to be impractical. I'd also add that lumping an entire code block in one gigantic if makes it very unreadable, too -- imagine trying to read that were it a large amount of actual useful logic instead of the pointless boilerplate I wrote, or debugging the inevitable precedence issues.
|
03-15-2010, 05:28 AM
|
|
Re: So, I've gotta learn C ...
Quote:
Originally Posted by Corona688
Quote:
Originally Posted by naturalist.atheist
What I saw was someone positing an example of the use of goto's to somehow make code easier to understand. I looked at that code and saw that eliminating the goto's made it easier to see what the code was doing in terms of logic flow. The goto's made it look more complicated than it actually was.
|
Good thing we've corrected that impression, then. Your method's been explained to be impractical. I'd also add that lumping an entire code block in one gigantic if makes it very unreadable, too -- imagine trying to read that were it actual useful logic instead of the pointless boilerplate I wrote, or debugging the inevitable precedence issues.
|
I agree about the precedence issues. But the assumption here was that C was being used. And if there is a question in C as to precedence you can always clarify with (). So that was not an issue. But in other languages like VB it can be a problem.
As for clarifying logic flow, it is hard for me to see how anybody would think 5 if's that go to the same place is simpler than 1. In fact the more if's you pile on, the more likely you will be thrown off by an if that doesn't actually go to the same place. But if you simplify the code as presented it will be obvious.
|
03-15-2010, 05:29 AM
|
God Made Me A Skeptic
|
|
Join Date: Jul 2004
Location: Minnesota
|
|
Re: So, I've gotta learn C ...
Again, failure to understand the abstraction. The code Corona688 posted was a simplified representation of a category of problems where careful use of goto can dramatically improve readability.
There's a more general form, which looks roughly like:
Code:
allocate_resource_1();
if (failed)
return;
allocate_resource_2();
if (failed)
goto free_1;
allocate_resource_3();
if (failed)
goto free_2;
do_stuff_with_all_three();
if (failed)
goto free_3;
do_more_stuff();
do_other_stuff();
free_3:
free_resource_3();
free_2:
free_resource_2();
free_1:
free_resource_1();
return;
You might end up with several points which goto each of these targets... This idiom is expressive and has a definite place.
You can't really do it well with deeply-nested conditionals, because people don't process those very effectively. The various elaborate hijinx people invent to avoid doing this are nearly all harder to read than the idiom itself.
__________________
Hear me / and if I close my mind in fear / please pry it open
See me / and if my face becomes sincere / beware
Hold me / and when I start to come undone / stitch me together
Save me / and when you see me strut / remind me of what left this outlaw torn
|
03-15-2010, 05:30 AM
|
God Made Me A Skeptic
|
|
Join Date: Jul 2004
Location: Minnesota
|
|
Re: So, I've gotta learn C ...
I should point out, BTW:
While C doesn't have try/catch, it does have setjmp/longjmp, which could in theory solve a very small number of the same problems.
That said, my advice on setjmp/longjmp is that you shouldn't use them.
__________________
Hear me / and if I close my mind in fear / please pry it open
See me / and if my face becomes sincere / beware
Hold me / and when I start to come undone / stitch me together
Save me / and when you see me strut / remind me of what left this outlaw torn
|
03-15-2010, 05:42 AM
|
|
Forum Killer
|
|
|
|
Re: So, I've gotta learn C ...
Quote:
Originally Posted by naturalist.atheist
As for clarifying logic flow, it is hard for me to see how anybody would think 5 if's that go to the same place is simpler than 1. In fact the more if's you pile on, the more likely you will be thrown off by an if that doesn't actually go to the same place.
|
That's true, a homogenous one-page LISP-oid logical expression that has to be understood in its entirety to understand any of it might be considered easier to read than one page of code with actual structure, termination points, and bits you can understand separately. Wait, no.
Quote:
But if you simplify the code as presented it will be obvious.
|
That's been explained to be impractical. If you still don't understand why, I can't help you.
|
03-15-2010, 05:49 AM
|
|
Re: So, I've gotta learn C ...
Quote:
Originally Posted by seebs
Again, failure to understand the abstraction. The code Corona688 posted was a simplified representation of a category of problems where careful use of goto can dramatically improve readability.
There's a more general form, which looks roughly like:
Code:
allocate_resource_1();
if (failed)
return;
allocate_resource_2();
if (failed)
goto free_1;
allocate_resource_3();
if (failed)
goto free_2;
do_stuff_with_all_three();
if (failed)
goto free_3;
do_more_stuff();
do_other_stuff();
free_3:
free_resource_3();
free_2:
free_resource_2();
free_1:
free_resource_1();
return;
You might end up with several points which goto each of these targets... This idiom is expressive and has a definite place.
You can't really do it well with deeply-nested conditionals, because people don't process those very effectively. The various elaborate hijinx people invent to avoid doing this are nearly all harder to read than the idiom itself.
|
So what is wrong with this?
Code:
allocate_resource_1();
if (!failed)
{
allocate_resource_2();
if (!failed)
{
allocate_resource_3();
if(!failed)
{
do_stuff_with_all_three();
if (!fail)
{
do_more_stuff();
do_other_stuff();
}
free_resource3();
}
free_resource2();
}
free_resource1();
}
return;
The logic flow is clearly visible.
|
03-15-2010, 05:49 AM
|
God Made Me A Skeptic
|
|
Join Date: Jul 2004
Location: Minnesota
|
|
Re: So, I've gotta learn C ...
The general form is that you may have many points, some at different levels of nesting within different conditionals, all of which want the same cleanup code.
Your options are:
1. Very elaborate control structures with a ton of nesting, setting extra condition variables, and the like.
2. Duplicate that cleanup code in all those places.
3. Use gotos.
Once you have three things which need to be deallocated in reverse order from their allocation (pretty common), there is no really nice way to express this without using gotos or something comparable -- especially if the deallocations themselves are non-trivial.
__________________
Hear me / and if I close my mind in fear / please pry it open
See me / and if my face becomes sincere / beware
Hold me / and when I start to come undone / stitch me together
Save me / and when you see me strut / remind me of what left this outlaw torn
|
03-15-2010, 05:53 AM
|
|
Forum Killer
|
|
|
|
Re: So, I've gotta learn C ...
He doesn't get it, seebs. He'll continue to argue with someone who's sat on C specification committees all night if you let him, but I at least am done with this conversation.
|
03-15-2010, 05:55 AM
|
|
Re: So, I've gotta learn C ...
Quote:
Originally Posted by seebs
The general form is that you may have many points, some at different levels of nesting within different conditionals, all of which want the same cleanup code.
Your options are:
1. Very elaborate control structures with a ton of nesting, setting extra condition variables, and the like.
2. Duplicate that cleanup code in all those places.
3. Use gotos.
Once you have three things which need to be deallocated in reverse order from their allocation (pretty common), there is no really nice way to express this without using gotos or something comparable -- especially if the deallocations themselves are non-trivial.
|
Goto is just another way to nest that is not as visible. An if statement turns into a set of jmp's which is the same as goto. These very specific logic control structures have been created in languages like C to illustrate logic control. You loose it when you use goto's
My point is that not having goto's usually enhances clarity of logic flow. I look at the nest and it is obvious where the guts of the routine are. With goto's as shown that is usually not as obvious.
And what extra condition variables did I set?
|
03-15-2010, 05:58 AM
|
God Made Me A Skeptic
|
|
Join Date: Jul 2004
Location: Minnesota
|
|
Re: So, I've gotta learn C ...
Quote:
Originally Posted by Corona688
He doesn't get it, seebs. He'll continue to argue with someone who's sat on C specification committees all night if you let him, but I at least am done with this conversation.
|
I don't think it quite rises to the level of "arguing with". That's just contradiction.
And yeah, I think at this point wer're done. So, useful tip to Shake: Do not necessarily trust everyone here to know much about programming, even the ones who can sorta write stuff that looks almost like code. Test stuff out, sanity-check, and so on.
__________________
Hear me / and if I close my mind in fear / please pry it open
See me / and if my face becomes sincere / beware
Hold me / and when I start to come undone / stitch me together
Save me / and when you see me strut / remind me of what left this outlaw torn
|
03-15-2010, 06:00 AM
|
|
Re: So, I've gotta learn C ...
Quote:
Originally Posted by Corona688
He doesn't get it, seebs. He'll continue to argue with someone who's sat on C specification committees all night if you let him, but I at least am done with this conversation.
|
This has been a discussion that has gone on for decades with bigger guns than any body here taking both sides.
I am not saying anything that has not been said before.
|
03-15-2010, 06:10 AM
|
|
Sane (but only just)
|
|
Join Date: Oct 2007
Location: Somewhere to the left of sanity
Gender: Male
|
|
Re: So, I've gotta learn C ...
Quote:
Originally Posted by naturalist.atheist
Quote:
Originally Posted by seebs
Again, failure to understand the abstraction. The code Corona688 posted was a simplified representation of a category of problems where careful use of goto can dramatically improve readability.
There's a more general form, which looks roughly like:
Code:
allocate_resource_1();
if (failed)
return;
allocate_resource_2();
if (failed)
goto free_1;
allocate_resource_3();
if (failed)
goto free_2;
do_stuff_with_all_three();
if (failed)
goto free_3;
do_more_stuff();
do_other_stuff();
free_3:
free_resource_3();
free_2:
free_resource_2();
free_1:
free_resource_1();
return;
You might end up with several points which goto each of these targets... This idiom is expressive and has a definite place.
You can't really do it well with deeply-nested conditionals, because people don't process those very effectively. The various elaborate hijinx people invent to avoid doing this are nearly all harder to read than the idiom itself.
|
So what is wrong with this?
Code:
allocate_resource_1();
if (!failed)
{
allocate_resource_2();
if (!failed)
{
allocate_resource_3();
if(!failed)
{
do_stuff_with_all_three();
if (!fail)
{
do_more_stuff();
do_other_stuff();
}
free_resource3();
}
free_resource2();
}
free_resource1();
}
return;
The logic flow is clearly visible.
|
It's harder to read because of the nesting and will still require code duplication to handle corner cases.
Aside: With regards to try / catch, Sutter has a good maxim: "Try, catch or get the hell out of the way". Good exception handling isn't about writing try / catch, but about not writing them.
__________________
There you go with them negative waves ... Why can't you say something righteous and beautiful for a change?
|
03-15-2010, 06:14 AM
|
|
Re: So, I've gotta learn C ...
Quote:
Originally Posted by JamesBannon
Quote:
So what is wrong with this?
Code:
allocate_resource_1();
if (!failed)
{
allocate_resource_2();
if (!failed)
{
allocate_resource_3();
if(!failed)
{
do_stuff_with_all_three();
if (!fail)
{
do_more_stuff();
do_other_stuff();
}
free_resource3();
}
free_resource2();
}
free_resource1();
}
return;
The logic flow is clearly visible.
|
It's harder to read because of the nesting and will still require code duplication to handle corner cases.
Aside: With regards to try / catch, Sutter has a good maxim: "Try, catch or get the hell out of the way". Good exception handling isn't about writing try / catch, but about not writing them.
|
If you actually practice SP then it is easier to read. If you are not as structured in your construction of logic then I expect you will find whatever style of goto usage you are accustomed to the easiest to read.
In the example code please show the corner cases that are not handled.
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
|
|
Thread Tools |
|
Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT +1. The time now is 10:31 PM.
|
|
|
|