goto [modified]
-
I am talking about those situations where goto is used for error handling and clean up. In fact that is the most common use I have seen in c++ code aka MFC and ATL.
void FunctionWithGoTo()
{
if (!(OpenFile()) GoTo Cleanup;if (!FileFormatIsValid()) GoTo CleanUp;
if (!RecordExists()) GoTo CleanUp;
....
CleanUp://Do some clean up work like closing the file
}You can rewrite it
void FunctionWithGoTo()
{
try
{
OpenFile();
ValidateFileFormat();
ValidateRecordExists();
.... other stuff
}
catch(//appropriate exceptions)
{}
finally
{
///Cleanup
}}
If you use RAII you can simplify the code further. So I guess it is difficult to come up with situations in modern languages like C++, C# Java etc. to use GoTo.
Co-Author ASP.NET AJAX in Action CP Quote of the Day: It is the same Friday that blooms as a new enriching day with novelty and innovation for us every week. - Vasudevan Deepak Kumar
In your examples, I prefer the version with the gotos. I can't tell which of OpenFile() or ValidateFileFormat() or ValidateRecordExists() might throw an exception.
-
Win32 APIs are meant for C.
Hope is the negation of reality - Raistlin Majere
They're still often the only option even from C++ or VB or any other language. Or C# for that matter, though luckily P/Invoke wraps those return values in exceptions.
-
Okay, so this isn't 100% a lounge question, but I'm asking this to stir controversy for the sake of entertainment, so I'll post here. Is goto really that bad? I'm beginning to wonder if it's just peer pressure and scariness that's making people avoid it. There are undeniably occasions in which goto enables the most readable code. Making private methods just for the sake of avoiding goto seems more spaghetti to me, as does using more local booleans and if/elses for flagging. If I were a teacher, I might not teach students to use goto, because they'll likely abuse it. But if I was evaluating a student's code and they use goto appropriately, I'd probably give them bonus marks for being bold. So, is it only because you've been taught not to use goto that you don't use it? -- modified at 22:22 Friday 23rd November, 2007 Or... http://xkcd.com/292/[^] By the way, let me restate the question: I know goto isn't necessary, but are there cases in which it's more appropriate?
I've only used goto once, it was to add a resume function. It struck me as simpler to impliment then to re factor the function into several smaller functions.
-
They're still often the only option even from C++ or VB or any other language. Or C# for that matter, though luckily P/Invoke wraps those return values in exceptions.
Yep, but Rama's point was that "it is difficult to come up with situations in modern languages like C++, C# Java etc. to use GoTo." What I meant is that since Win32 API was written for C, if you want to use them you'll have to do it the C way, and perhaps mix it with C++ exceptions, such as:
HANDLE h = FindFirstFile(_T("AVeryImportantFile.txt"), &WIN32_FIND_DATA());
if (h == INVALID_HANDLE_VALUE)
throw CException(_T("A very important file is missing."));
Hope is the negation of reality - Raistlin Majere
-
reinux wrote:
Something about that extra bool and if/else really bugs me.
Me too. I think your example doesn't make much difference, one way or another. But if the loops are nested, you have to have break out of multiple levels.
Oops, I knew that. Yeah. Uh huh. Yup. Totally knew that. Yup. Yup... :~
-
Okay, so this isn't 100% a lounge question, but I'm asking this to stir controversy for the sake of entertainment, so I'll post here. Is goto really that bad? I'm beginning to wonder if it's just peer pressure and scariness that's making people avoid it. There are undeniably occasions in which goto enables the most readable code. Making private methods just for the sake of avoiding goto seems more spaghetti to me, as does using more local booleans and if/elses for flagging. If I were a teacher, I might not teach students to use goto, because they'll likely abuse it. But if I was evaluating a student's code and they use goto appropriately, I'd probably give them bonus marks for being bold. So, is it only because you've been taught not to use goto that you don't use it? -- modified at 22:22 Friday 23rd November, 2007 Or... http://xkcd.com/292/[^] By the way, let me restate the question: I know goto isn't necessary, but are there cases in which it's more appropriate?
reinux wrote:
So, is it only because you've been taught not to use goto that you don't use it?
No, it's because i don't need it. In fact, i was reminded by a co-worker just last week of the last instance where i used goto. Seems i had to fix a bug in a monstrous piece of legacy code, a method many hundreds of lines long with plenty of twisted internal control structures and cleanup needs. After spending the better part of an evening figuring out how the thing worked, i fixed the problem and threw in a goto as part of the cleanup, commenting that it couldn't really make the damn thing any worse. The routine was divided up and re-written during the past month. Needless to say, my goto is no longer a part of it. ;)
reinux wrote:
Making private methods just for the sake of avoiding goto seems more spaghetti to me, as does using more local booleans and if/elses for flagging.
Actually, i'd argue that a sufficient quantity of properly-chosen (and named...) private methods not only makes the code more readable, but also effectively eliminates most scenarios where internal booleans, long conditionals, or gotos might otherwise be used. And that's a good thing. ;)
----
...the wind blows over it and it is gone, and its place remembers it no more...
-
Yep, but Rama's point was that "it is difficult to come up with situations in modern languages like C++, C# Java etc. to use GoTo." What I meant is that since Win32 API was written for C, if you want to use them you'll have to do it the C way, and perhaps mix it with C++ exceptions, such as:
HANDLE h = FindFirstFile(_T("AVeryImportantFile.txt"), &WIN32_FIND_DATA());
if (h == INVALID_HANDLE_VALUE)
throw CException(_T("A very important file is missing."));
Hope is the negation of reality - Raistlin Majere
Well if we were discussing the pure theory behind the languages, yeah, goto is less useful in C++. But in practice C calls inevitably become necessary, unless you're using BeOS or something, which has a purely C++ API. And yeah, in this case you could use an exception instead of a goto. But if you're planning to catch the exception within the same caller function, you might as well use a goto, no? My question isn't so much whether goto is necessary, but whether there are cases in which it's more appropriate.
-
reinux wrote:
So, is it only because you've been taught not to use goto that you don't use it?
No, it's because i don't need it. In fact, i was reminded by a co-worker just last week of the last instance where i used goto. Seems i had to fix a bug in a monstrous piece of legacy code, a method many hundreds of lines long with plenty of twisted internal control structures and cleanup needs. After spending the better part of an evening figuring out how the thing worked, i fixed the problem and threw in a goto as part of the cleanup, commenting that it couldn't really make the damn thing any worse. The routine was divided up and re-written during the past month. Needless to say, my goto is no longer a part of it. ;)
reinux wrote:
Making private methods just for the sake of avoiding goto seems more spaghetti to me, as does using more local booleans and if/elses for flagging.
Actually, i'd argue that a sufficient quantity of properly-chosen (and named...) private methods not only makes the code more readable, but also effectively eliminates most scenarios where internal booleans, long conditionals, or gotos might otherwise be used. And that's a good thing. ;)
----
...the wind blows over it and it is gone, and its place remembers it no more...
Shog9 wrote:
No, it's because i don't need it.
It's not ever necessary, no, but my question is, can it make things more readable sometimes? Is it being unnecessarily demonized?
Shog9 wrote:
Actually, i'd argue that a sufficient quantity of properly-chosen (and named...) private methods not only makes the code more readable, but also effectively eliminates most scenarios where internal booleans, long conditionals, or gotos might otherwise be used. And that's a good thing.
That means several things though: -I have to scroll up and down to jump between methods -I have to choose the locals that I want to use (not so bad with Refractor) -If I ever want to change those locals, I have to change the code in two locations: the call arguments and the method parameters -I have to sit down and think of a name. And I spend a lot of time coming up with good names, because if I don't, it affects my reasoning later on.
Shog9 wrote:
or gotos might otherwise be used. And that's a good thing.
Sure, but why?
-
Christian Graus wrote:
Not sure what you mean by 'making private methods for the sake of avoiding goto', if you have code that needs to be pointed to only sometimes, refactoring it to a new method just makes sense.
Eh, now that you ask, I can't think of any examples. Maybe you have a point. So what makes it bad if you know not to use it in a bad way?
There is no circumstance in which it doesn't create code that's less readable than if you use a method to call, or try/catch. I've simply never looked at code I wrote and thought 'if only I could use goto'.
Christian Graus - Microsoft MVP - C++ "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
-
Christian Graus wrote:
The closest I would get is to regard goto as another way to handle code that is at least as well handled by try/catch.
A first chance exception of type 'System.NullReferenceException' occurred in mscorlib.dll
A first chance exception of type 'System.NullReferenceException' occurred in mscorlib.dll
A first chance exception of type 'System.NullReferenceException' occurred in mscorlib.dll
A first chance exception of type 'System.NullReferenceException' occurred in mscorlib.dll
A first chance exception of type 'System.NullReferenceException' occurred in mscorlib.dll
A first chance exception of type 'System.NullReferenceException' occurred in mscorlib.dllxacc.ide
IronScheme a R5RS-compliant Scheme on the DLR
The rule of three: "The first time you notice something that might repeat, don't generalize it. The second time the situation occurs, develop in a similar fashion -- possibly even copy/paste -- but don't generalize yet. On the third time, look to generalize the approach."I'm sure your point is obvious to you, but it escapes me
Christian Graus - Microsoft MVP - C++ "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
-
Shog9 wrote:
No, it's because i don't need it.
It's not ever necessary, no, but my question is, can it make things more readable sometimes? Is it being unnecessarily demonized?
Shog9 wrote:
Actually, i'd argue that a sufficient quantity of properly-chosen (and named...) private methods not only makes the code more readable, but also effectively eliminates most scenarios where internal booleans, long conditionals, or gotos might otherwise be used. And that's a good thing.
That means several things though: -I have to scroll up and down to jump between methods -I have to choose the locals that I want to use (not so bad with Refractor) -If I ever want to change those locals, I have to change the code in two locations: the call arguments and the method parameters -I have to sit down and think of a name. And I spend a lot of time coming up with good names, because if I don't, it affects my reasoning later on.
Shog9 wrote:
or gotos might otherwise be used. And that's a good thing.
Sure, but why?
I find that private methods help me read and understand code better. Compare
void ProcessResults(Data d)
{
if (d.cond1 && (d.cond2 || d.cond3)
{
...
}
}with
void ProcessResult(Data d)
{
if (IsType1(data)
{
...
}
}private bool IsType1(data)
{
return data.cond1 && (data.cond2 || data.cond3);
}When reading ProcessResult, I don't need to figure what the boolean logic is trying to do (another layer of abstraction, if you will). This keeps the focus on ProcessResult's code flow
Regards Senthil [MVP - Visual C#] _____________________________ My Blog | My Articles | My Flickr | WinMacro
-
I find that private methods help me read and understand code better. Compare
void ProcessResults(Data d)
{
if (d.cond1 && (d.cond2 || d.cond3)
{
...
}
}with
void ProcessResult(Data d)
{
if (IsType1(data)
{
...
}
}private bool IsType1(data)
{
return data.cond1 && (data.cond2 || data.cond3);
}When reading ProcessResult, I don't need to figure what the boolean logic is trying to do (another layer of abstraction, if you will). This keeps the focus on ProcessResult's code flow
Regards Senthil [MVP - Visual C#] _____________________________ My Blog | My Articles | My Flickr | WinMacro
I don't think I'd ever name a method ProcessResults. Well, maybe I have in the past. If it's an override or interface implementation or something and I have no option but to use that name, and the logic isn't straightforward, I'd just comment it. Especially if it involves any sort of math.
-
Shog9 wrote:
No, it's because i don't need it.
It's not ever necessary, no, but my question is, can it make things more readable sometimes? Is it being unnecessarily demonized?
Shog9 wrote:
Actually, i'd argue that a sufficient quantity of properly-chosen (and named...) private methods not only makes the code more readable, but also effectively eliminates most scenarios where internal booleans, long conditionals, or gotos might otherwise be used. And that's a good thing.
That means several things though: -I have to scroll up and down to jump between methods -I have to choose the locals that I want to use (not so bad with Refractor) -If I ever want to change those locals, I have to change the code in two locations: the call arguments and the method parameters -I have to sit down and think of a name. And I spend a lot of time coming up with good names, because if I don't, it affects my reasoning later on.
Shog9 wrote:
or gotos might otherwise be used. And that's a good thing.
Sure, but why?
reinux wrote:
It's not ever necessary, no, but my question is, can it make things more readable sometimes? Is it being unnecessarily demonized?
No. Well, yeah, probably - i mean, why bother to demonize a keyword, even if it is generally misused by people who don't know what they're doing. But i'd say it's use is discouraged and rightly so. Look, goto is primitive, a very simple building-block. Unconditional transfer. Right? But the thing is, you always want conditional transfer. Think about it - you'll always use some sort of conditional to control whether or not the goto is ever reached. This is old stuff, bordering on the
je | _ne stuff |_ jmpassembler pattern or similar. It's tedious, hard to read, and error-prone, which is why we've spent decades building wrappers into the languages themselves. The other unconditionals have very strict limits on them -break,continue,return... all transfer control, but in very specific ways. You see a return, you know you're done with the current method. You see a break, you know you're leaving the current loop (or switch...), etc. You read them and, provided you're keeping your methods and loops fairly short, can know immediately what's going to happen.gotois more of a wildcard... you can't read it without wondering what sort of odd thing is happening such that more limited control structures couldn't be used in place. I mean, heck - you can simulate subroutines withlongjmp()too, but why would you want to? ;) And yeah, it can make things more readable sometimes. Usually when things are next-to-unreadable already, and your only other hope of avoiding complete disaster is to re-write the whole mess. Which is fine, but not a good reason to start looking for excuses to work them into brand-new code.reinux wrote:
That means several things though: -I have to scroll up and down to jump between methods
If you want to read or trace through every single line of code, you'll be scrolling and jumping around anyway. If you're just trying to get a clear high-level picture of the logic or to find one particular area, now you'll have a ready index to help you.
reinux wrote:
-I have to choose the locals that I want to use
Well... duh. How is this relevant? Do you normally work off of a big fa
-
I don't think I'd ever name a method ProcessResults. Well, maybe I have in the past. If it's an override or interface implementation or something and I have no option but to use that name, and the logic isn't straightforward, I'd just comment it. Especially if it involves any sort of math.
You are missing the point. I was trying to point out that reading a method is simpler when it is written so that it calls out to other methods for any logic unrelated to it. The method then can be read like pseudocode, with the internals hidden inside other methods.
Regards Senthil [MVP - Visual C#] _____________________________ My Blog | My Articles | My Flickr | WinMacro
-
Okay, so this isn't 100% a lounge question, but I'm asking this to stir controversy for the sake of entertainment, so I'll post here. Is goto really that bad? I'm beginning to wonder if it's just peer pressure and scariness that's making people avoid it. There are undeniably occasions in which goto enables the most readable code. Making private methods just for the sake of avoiding goto seems more spaghetti to me, as does using more local booleans and if/elses for flagging. If I were a teacher, I might not teach students to use goto, because they'll likely abuse it. But if I was evaluating a student's code and they use goto appropriately, I'd probably give them bonus marks for being bold. So, is it only because you've been taught not to use goto that you don't use it? -- modified at 22:22 Friday 23rd November, 2007 Or... http://xkcd.com/292/[^] By the way, let me restate the question: I know goto isn't necessary, but are there cases in which it's more appropriate?
Yes there are good uses for goto. I had never used a goto before the program I am writing now but I have used maybe 8 gotos in about 5000 lines of code and I think they are all good uses for it. The reason I used it is because I have a number of functions that have to make all or nothing evaluations of arrays of objects where for instance if any 2 items in 2 different arrays are the same then the function returns true regardless of anything else. Or the opposite where if anything test false then the answer is false(I'm oversimplifying a bit but you get the idea). In these situations you might know the answer after only the first comparison. I use the gotos to escape the nested loops so I don't do a ton of unnecisary comparisons. I also used it inside an inside loop in a heavily used function to avoid having to reevaluate something. Most of the examples of the never use a goto people are unrealistic examples IMHO. This is alot like the people who claim recursion should never be used, who then trot out some silly example like calculating factorials where a simple loop would work fine.
-
Okay, so this isn't 100% a lounge question, but I'm asking this to stir controversy for the sake of entertainment, so I'll post here. Is goto really that bad? I'm beginning to wonder if it's just peer pressure and scariness that's making people avoid it. There are undeniably occasions in which goto enables the most readable code. Making private methods just for the sake of avoiding goto seems more spaghetti to me, as does using more local booleans and if/elses for flagging. If I were a teacher, I might not teach students to use goto, because they'll likely abuse it. But if I was evaluating a student's code and they use goto appropriately, I'd probably give them bonus marks for being bold. So, is it only because you've been taught not to use goto that you don't use it? -- modified at 22:22 Friday 23rd November, 2007 Or... http://xkcd.com/292/[^] By the way, let me restate the question: I know goto isn't necessary, but are there cases in which it's more appropriate?
Anything used incorrectly is bad. I think the argument about goto is that it simply gives developers an easy-out rather than making them think up better constructs. As with anything there are good and bad ways to use it. Goto just seems to have way more bad ways than good ways... ...and this is coming from a die-hard VBer :)
-
reinux wrote:
It's not ever necessary, no, but my question is, can it make things more readable sometimes? Is it being unnecessarily demonized?
No. Well, yeah, probably - i mean, why bother to demonize a keyword, even if it is generally misused by people who don't know what they're doing. But i'd say it's use is discouraged and rightly so. Look, goto is primitive, a very simple building-block. Unconditional transfer. Right? But the thing is, you always want conditional transfer. Think about it - you'll always use some sort of conditional to control whether or not the goto is ever reached. This is old stuff, bordering on the
je | _ne stuff |_ jmpassembler pattern or similar. It's tedious, hard to read, and error-prone, which is why we've spent decades building wrappers into the languages themselves. The other unconditionals have very strict limits on them -break,continue,return... all transfer control, but in very specific ways. You see a return, you know you're done with the current method. You see a break, you know you're leaving the current loop (or switch...), etc. You read them and, provided you're keeping your methods and loops fairly short, can know immediately what's going to happen.gotois more of a wildcard... you can't read it without wondering what sort of odd thing is happening such that more limited control structures couldn't be used in place. I mean, heck - you can simulate subroutines withlongjmp()too, but why would you want to? ;) And yeah, it can make things more readable sometimes. Usually when things are next-to-unreadable already, and your only other hope of avoiding complete disaster is to re-write the whole mess. Which is fine, but not a good reason to start looking for excuses to work them into brand-new code.reinux wrote:
That means several things though: -I have to scroll up and down to jump between methods
If you want to read or trace through every single line of code, you'll be scrolling and jumping around anyway. If you're just trying to get a clear high-level picture of the logic or to find one particular area, now you'll have a ready index to help you.
reinux wrote:
-I have to choose the locals that I want to use
Well... duh. How is this relevant? Do you normally work off of a big fa
Shog9 wrote:
It's tedious, hard to read, and error-prone, which is why we've spent decades building wrappers into the languages themselves.
Yeah, but structured languages aren't exempt from leaky abstraction[^] of code flow. It's been decades since C and we still haven't come up with a good be all end all solution for breaking out of nested switches or loops. We're also still using Win32API a lot, which means we don't always have the luxury of using exception handling. Obviously I'm thankful that I don't have to use goto all the time, but that doesn't mean I'll never want to use it.
Shog9 wrote:
Which is fine, but not a good reason to start looking for excuses to work them into brand-new code.
Never would do that. Which is why I said that if I were a teacher, I wouldn't encourage students to use it, but if someone did use it well, I'd applaud them.
Shog9 wrote:
If you want to read or trace through every single line of code, you'll be scrolling and jumping around anyway.
Exactly, which is why I like to keep that at a minimum. Just because it happens doesn't mean I don't care if it happens more often.
Shog9 wrote:
If you're just trying to get a clear high-level picture of the logic or to find one particular area, now you'll have a ready index to help you.
That's what indentation is for. Heck, I often add scope brackets just to indicate logical blocks of code. I can remember code as mental symbols that mean exactly what they do, rather than having to come up with English names that might potentially have slightly different nuances from what I'm doing. I write my code in a way that you can infer the purpose and execution flow from the shape of the code. Everything executes in a general top-to-bottom order (unless the same code happens twice or more, in which case I'll refractor), and the indentations indicate sub-routines. Which is why I don't like having processing code in the middle of search code like this[
-
Okay, so this isn't 100% a lounge question, but I'm asking this to stir controversy for the sake of entertainment, so I'll post here. Is goto really that bad? I'm beginning to wonder if it's just peer pressure and scariness that's making people avoid it. There are undeniably occasions in which goto enables the most readable code. Making private methods just for the sake of avoiding goto seems more spaghetti to me, as does using more local booleans and if/elses for flagging. If I were a teacher, I might not teach students to use goto, because they'll likely abuse it. But if I was evaluating a student's code and they use goto appropriately, I'd probably give them bonus marks for being bold. So, is it only because you've been taught not to use goto that you don't use it? -- modified at 22:22 Friday 23rd November, 2007 Or... http://xkcd.com/292/[^] By the way, let me restate the question: I know goto isn't necessary, but are there cases in which it's more appropriate?
Yes, the goto is really that bad. I've found that once you tolerate any use of goto, some developers will abuse it severely. Not only does it create difficult to understand code, it causes scope problems and, worse of all, results in poor algorithms. I have learned this by experience. I have maintained a lot of code chock full of gotos, but I have chosen to use one precisely once in nineteen years of C/C++ programming. (When doing assembly programming, I use the equivalent, but you really have no choice. However, even there, if I'm jmp'ing more than a page of code, I'd take a very close look at my algorithm.) Personally, I would fail any student using a goto (I won't hire anyone who uses them more than extremely sparingly.) Later, if this person encounters a situation where a goto appears to be the best solution, it will make them think long and hard and examine their code carefully before making a deliberate decision. And they'd better document why. (BTW, I rarely have problems with memory leaks in C/C++. The developers I've dealt with that use gotos tend to have memory leaks. It don't think it's coincidental.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
You are missing the point. I was trying to point out that reading a method is simpler when it is written so that it calls out to other methods for any logic unrelated to it. The method then can be read like pseudocode, with the internals hidden inside other methods.
Regards Senthil [MVP - Visual C#] _____________________________ My Blog | My Articles | My Flickr | WinMacro
That's what indentation is for. Heck, I often add scope brackets just to indicate logical blocks of code. I can remember code as mental symbols that mean exactly what they do, rather than having to come up with English names that might potentially have slightly different nuances from what I'm doing. I write my code in a way that you can infer the purpose and execution flow from the shape of the code. Everything executes in a general top-to-bottom order (unless the same code happens twice or more, in which case I'll refractor), and the indentations indicate sub-routines. Which is why I don't like having processing code in the middle of search code like this[^]. Makes it a lot easier to remember code too, because you get a one-to-one association between the visual shape of your code and its function.
I suppose refractoring a lot gives you the pseudocode-ish-ness advantage, but it's a pain when you're debugging, and once you forget what all those esoteric function names mean, you're going to end up having to peek inside anyway. So in a sense both ways of thinking have their advantages at different stages of development. The question would then be, which is simpler in the big picture? And honestly, I don't know, but you could argue for both.
-
Yes, the goto is really that bad. I've found that once you tolerate any use of goto, some developers will abuse it severely. Not only does it create difficult to understand code, it causes scope problems and, worse of all, results in poor algorithms. I have learned this by experience. I have maintained a lot of code chock full of gotos, but I have chosen to use one precisely once in nineteen years of C/C++ programming. (When doing assembly programming, I use the equivalent, but you really have no choice. However, even there, if I'm jmp'ing more than a page of code, I'd take a very close look at my algorithm.) Personally, I would fail any student using a goto (I won't hire anyone who uses them more than extremely sparingly.) Later, if this person encounters a situation where a goto appears to be the best solution, it will make them think long and hard and examine their code carefully before making a deliberate decision. And they'd better document why. (BTW, I rarely have problems with memory leaks in C/C++. The developers I've dealt with that use gotos tend to have memory leaks. It don't think it's coincidental.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
Joe Woodbury wrote:
I've found that once you tolerate any use of goto, some developers will abuse it severely.
That might be a good point as an employer. What if you're the one using goto, and you trust yourself with it?
Joe Woodbury wrote:
Not only does it create difficult to understand code, it causes scope problems and, worse of all, results in poor algorithms.
Yeah, all these things can happen if you misuse it, but unreadable code and poor algorithms happen for a lot of reasons. What I'm suggesting is that, perhaps, the lack of goto can also result in such.
Joe Woodbury wrote:
(BTW, I rarely have problems with memory leaks in C/C++. The developers I've dealt with that use gotos tend to have memory leaks. It don't think it's coincidental.)
Yeah, I'd say. If their code is "chock full" of gotos, there's obviously a problem. Also I don't remember if C/C++ lets you goto out of a function (I never used it back then), but if it does, and people do that, well, there's your memory leak potential. I wouldn't goto over more than a few lines of code myself either.