goto

Quote:

---

It is a design problem.

---

As correctly stated by Anthony Mai, it is not a design problem. It is an implementation detail. As correctly demonstrated by Philip Nicoletti, goto can be more error prone.

Jeff

Code:

---

switch (//some switch variable)
{
case //case1:
std::vector<int> v(1000000);
int i = 10;
break;
// next cases
}

---

forget some brackets?

Quote:

---

previously posted by galathaea ...

switch (//some switch variable)
{
case //case1:
std::vector<int> v(1000000);
int i = 10;
break;
// next cases
}
--------------------------------------------------------------------------------


forget some brackets?

---

Nope ... I did not post that code.

Plus you were asking why

Code:

---

if (something) goto here
//
//
here:

---

is not as good as

Code:

---

if (something)
{
//
//
}

---

re: Phillip Nicolleti

No, but that same wiley programmer who didn't follow a good design suggestion added those variables to a switch statement like they did to my goto. You have to see how this invalidates your argument against goto being the culprit? Don't you?

Re: jfaust

Don't you?

not at all, I edited my previous post, but you
replied to fast for me ...

You were comparing the merits of two particular
constructs. That's what I did.

Sorry for the multiple posts here, I probably should
think of everything I want to say and put it all in one
post, but ...

By the way, if you look, I never said that I was against
the use of goto in all circumstances. I said I was against
it in the case that galathaea mentioned.

For the record : I started programming in Fortran 66,
where you HAD to use goto, computed gotos,
arithmetic if, and the like. With Fortran 77, and then
Fortran 9x, the need for these constructs is minimal.
Although I have no "religious type" of belief against
the use of goto, I probably have not used one in
over 10 years - simply because I never saw the need.
(and I still do 75 percent of my programming in Fortran).


Also, Stroustrup mentions that one valid use of goto
is to break out of inner-loops in nested loops.

I do understand your point Phillip, and I'm not assuming that you ever said goto's were bad. But there are still people who would never, never, never use goto and feel some kind of animosity towards its use, and I am just trying to defend this lonely keyword. It has been abused and neglected for too long, and it wasn't born evil. It can't defend itself.

The code I posted first comparing goto and a block statement I still defend. Its a perfectly legitimate use. My example with the switch was to show that the reason you do not like the use of goto in that place is due to someone creating a problem because of bad design. It does not exist because of the goto. Design principles are created precisely because a consistent design should not allow unexpected errors such as the one you posted. Note how the design principle I stated was general to the problem of variable locality and had nothing to do with an exceptional situation that arises because of goto.

The Stroustrup example you give is a good use of goto as well, but it has the advantage of being a simpler solution than variable testing in each loop. This is the exemplar of goto programming, but I did not want to give goto an advantage. I'm trying to show how even casual use of goto is not something to check over your shoulder for, as long as you are still respecting good design principles. Any good, consistent design principles that follows the good design principles = avoids potential errors in coding equation should allow even the use of gotos in proper circumstances.

So I still believe that the previous comparison post of goto v. blocks is valid and that the "problem" that Phillip mentions is not a problem that should be given to goto. Remember, I didn't post the code with variables either.

Quote:

---

Re: jfaust
Don't you?

---

goto is a flow of control language feature. No other flow of control keyword has caused so much problems as goto. I've debugged code written in the 60s. I still have nightmares.

When I look at any problem I first look at it from a maintenance standpoint. Just because you know the issues well enough and are intelligent enough doesn't mean the next guy modifying your code will be.

goto is a simple concept that can lead to complex bugs. This discrepency is the heart of why it can be dangerous.

I quoted Dijkstra previously, "it is too much an invitation to make a mess of one's program". Maybe you won't make a mess of it, but the next guy very well could.

Jeff

Quote:

---

Side note: exception handling is DEFINITELY necessary in some places. Say I am writing an API interception and am performing my interception in some process in a galaxy far away. I get a list of currently loaded modules and begin patching their IAT. But that process is doing its own thing, and one of the modules I am patching is unloaded while writing the thunks. Do I let my interception crash the process, or do I catch the memory exception that is going to occur and use it to have my program realize that that module is no longer there and I should move on to the next?

---

Wasn't the subject 'C++ exceptions' ?

Sounds more like SEH to me.

My senior project in college was to update some code written in Fortran77 to simulate the recombination of antiprotons and positrons in the formation of AntiHydrogen. I needed to update the recombination algorithms to reflect current theory and optimize performance. It was horrible. I basically had to rewrite the entire program, and some of the problems were goto related. But I never blamed goto. I blamed the design principles (or lack of) of the original coder. The goto type statements were easy targets early on, because solid design principles were not formulated early on in programming language theory. And in place of general design principles, earlier principles tended to focus on linguistic characteristics of specific keywords. But we have evolved since then. Now design principles concentrate on logic flow, type principles, and general development consistency issues focused on the entire product path. I do not think it is legitamate or even good practice to substitue archaic practices for modern design principles. As our knowledge increases, we should replace old prejudices which, as I had surmised above, come from "gurus" of the past. I try not to hire those who lack understanding of good design principles, so that these wiley programmers won't be able to "maintain" my code in horrendous ways. Ways, I should add, that my previous posts show are not in any way to blame on goto.

Quote:

---

Originally posted by galathaea
Here is the real issue. So, someone working for me submits the following code flow:

Code:

---

// inside somewhere

// some code
if (//some condition) goto here;

// some more code

here:
// some more code

---

and someone else working for me submits:

Code:

---

// inside somewhere

// some code
if (//not some condition)
{
// some more code
}

// some more code here

---

I look at both of them. I understand both of them. I can maintain both of them.
...

---

I don't think you can use such a simple example. When maintaining code, I would hate to see a goto used instead of a "then" block as a "standard" coding practice. If there were ten if statements in a block of code, you would have to make sure that each goto matched up with its appropriate tag (and come up with ten tag names). This sounds like a headache and a likely cause of errors.

Also what would you propose if there was an "else" block?

For "if" statements, bracketed "then" blocks appears to be the defacto standard for coding. Why does one person need to use the goto? I think you should enforce some standards. :)

Regards,
John Flegert

I was not using the goto as a generic then block, but I have little qualms over its use in this way. The main problem would be pollution of label name space, but even that is little concern these days if you have a good naming convention. I was mainly using goto as a general program flow redirector, which could be done with while, if, switch, and others. I was trying to show that flow decisions can be accomplished with goto without there being anything scary going on. All of the multiple if/else problems you mention could be coded with switches just as easily, but I don't want to enforce if/else or switch unless there are optimization concerns. (Yes I do understand the compiled ML differences of these as well).

Quote:

---

I think you should enforce some standards.

---

I have no problems with any linguistic styles a coder uses if they follow good design principles. This includes placement of {}, indentation styles, and yes, even the choice of goto v. other flow control. Consistency is as much an issue here as it is with reading novels. You get "into" them by becoming familiar with an author's style and understanding their intent. I do not want to become a code fashion police officer in my company, as that has always seemed to me tantamount to release of my duty to be able to read code. Reading code, in any style, is the first thing one should learn how to do.

Quote:

---

This sounds like a headache and a likely cause of errors.

---

What errors that are not design related (as opposed to the implied goto related)? This was my question. All the errors people keep referring apply to the switch case and others as well, and I have tried to show that this is a design problem unrelated to poor goto. I enforce design, not fashion.

Quote:

---

Side note: exception handling is DEFINITELY necessary in some places. Say I am writing an API interception and am performing my interception in some process in a galaxy far away. I get a list of currently loaded modules and begin patching their IAT. But that process is doing its own thing, and one of the modules I am patching is unloaded while writing the thunks. Do I let my interception crash the process, or do I catch the memory exception that is going to occur and use it to have my program realize that that module is no longer there and I should move on to the next?

---

I am talking about C++ exception (those created by a "throw" C++ statement), and you are talking about OS exceptions (Generated by the OS because you are accessing invalid memory or try to divide by zero, or executing a none-exist CPU instruction)

These are totally different things. OS exceptions are completely unpredictable and your code can do very little about it, nor can you prevent it from happening. But for C++ exception, you are in total control, you have the option to NOT to throw an exception and instead return an error code.

By throwing a C++ exception, you are basically placing a wild "goto" statement, with the whereabout it may end up totally unpredictable and unmanageable. Nothing can be worse.

There are things in a program's life that it simply can not predict and can not handle, like the power cord is suddenly pulled out. But for those things predictable and manageable, it should try to handle things in a nice way and recover from error in a graceful way. Simply throwing an exception and hope some god speed piece of code may catch it is just irresponsible.

Back to your presumed situation, if a process is using a module, then the module should not be unloaded. If it is unloaded, then it is either the OS or some one else's bug, and it is not something you can handle, and so handle it not you should.

Quick off topic: the c++ catch(...) will catch access violations. Which exception is thrown I do not fully understand, since it is a machine dependent exception, and I don't think that there is an ANSI standard exception type for it. But it will be caught (I had to test this once, because I did not know). When I code something like I mentioned, though, I use SEH, because it is the only way I know of to get better information. We could start a new thread if anyone wants to discuss this more and enlighten me.

Still off topic: No. FreeLibrary is not a programming error. Remember, in API interception, these are other peoples processes.