goto

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.

Quote:

---

We could start a new thread if anyone wants to discuss this more and enlighten me.

---

I'd like a discussion about the stuff I quoted from your post in my previous one.

I don't think I could contribute much to this, though I would like to. The few things I know are just from stuff that I read, nothing I experienced myself.

If you could point me to (web-)resources on the subject, i'd really appreciate it.

Quote:

---

Here is a real-life example from MFC COleDateTime class. Note that it would be extremly difficult to code this without the goto.

---

Oh come on..... You have to be kidding me......

That example is so easy to do without a goto. It doesn't take much effort at all to modify that example to do the exact same thing without the goto.

Example:

Code:

---

static BOOL _TmFromOleDate(DATE dtSrc, struct tm& tmDest)
{
        // The legal range does not actually span year 0 to 9999.
        if (dtSrc > MAX_DATE || dtSrc < MIN_DATE) // about year 100 to about 9999
                return FALSE;

        long nDays;            // Number of days since Dec. 30, 1899
        long nDaysAbsolute;    // Number of days since 1/1/0
        long nSecsInDay;        // Time in seconds since midnight
        long nMinutesInDay;    // Minutes in day

        long n400Years;        // Number of 400 year increments since 1/1/0
        long n400Century;      // Century within 400 year block (0,1,2 or 3)
        long n4Years;          // Number of 4 year increments since 1/1/0
        long n4Day;            // Day within 4 year block
                                                        //  (0 is 1/1/yr1, 1460 is 12/31/yr4)
        long n4Yr;              // Year within 4 year block (0,1,2 or 3)
        BOOL bLeap4 = TRUE;    // TRUE if 4 year block includes leap year

        double dblDate = dtSrc; // tempory serial date

        // If a valid date, then this conversion should not overflow
        nDays = (long)dblDate;

        // Round to the second
//        dblDate += ((dtSrc > 0.0) ? HALF_SECOND : -HALF_SECOND);

        nDaysAbsolute = (long)dblDate + 693959L; // Add days from 1/1/0 to 12/30/1899

        dblDate = fabs(dblDate);
        double dblTimePart = dblDate - floor(dblDate);
        double dblSecsInDay = dblTimePart * 86400.0F;
        nSecsInDay = (long)(dblSecsInDay);

        double deltaSecs = dblSecsInDay - (double)nSecsInDay; // milliseconds
        if(deltaSecs > 0.999000F)
                nSecsInDay++;

        // Calculate the day of week (sun=1, mon=2...)
        //  -1 because 1/1/0 is Sat.  +1 because we want 1-based
        tmDest.tm_wday = (int)((nDaysAbsolute - 1) % 7L) + 1;

        // Leap years every 4 yrs except centuries not multiples of 400.
        n400Years = (long)(nDaysAbsolute / 146097L);

        // Set nDaysAbsolute to day within 400-year block
        nDaysAbsolute %= 146097L;

        // -1 because first century has extra day
        n400Century = (long)((nDaysAbsolute - 1) / 36524L);

        // Non-leap century
        if (n400Century != 0)
        {
                // Set nDaysAbsolute to day within century
                nDaysAbsolute = (nDaysAbsolute - 1) % 36524L;

                // +1 because 1st 4 year increment has 1460 days
                n4Years = (long)((nDaysAbsolute + 1) / 1461L);

                if (n4Years != 0)
                        n4Day = (long)((nDaysAbsolute + 1) % 1461L);
                else
                {
                        bLeap4 = FALSE;
                        n4Day = (long)nDaysAbsolute;
                }
        }
        else
        {
                // Leap century - not special case!
                n4Years = (long)(nDaysAbsolute / 1461L);
                n4Day = (long)(nDaysAbsolute % 1461L);
        }

        if (bLeap4)
        {
                // -1 because first year has 366 days
                n4Yr = (n4Day - 1) / 365;

                if (n4Yr != 0)
                        n4Day = (n4Day - 1) % 365;
        }
        else
        {
                n4Yr = n4Day / 365;
                n4Day %= 365;
        }

        // n4Day is now 0-based day of year. Save 1-based day of year, year number
        tmDest.tm_yday = (int)n4Day + 1;
        tmDest.tm_year = n400Years * 400 + n400Century * 100 + n4Years * 4 + n4Yr;

        for(;;)//end less loop
        {
                // Handle leap year: before, on, and after Feb. 29.
                if (n4Yr == 0 && bLeap4)
                {
                        // Leap Year
                        if (n4Day == 59)
                        {
                                /* Feb. 29 */
                                tmDest.tm_mon = 2;
                                tmDest.tm_mday = 29;
                                break; //goto DoTime;
                        }

                        // Pretend it's not a leap year for month/day comp.
                        if (n4Day >= 60)
                                --n4Day;
                }

                // Make n4DaY a 1-based day of non-leap year and compute
                //  month/day for everything but Feb. 29.
                ++n4Day;

                // Month number always >= n/32, so save some loop time */
                for (tmDest.tm_mon = (n4Day >> 5) + 1;
                        n4Day > _afxMonthDays[tmDest.tm_mon]; tmDest.tm_mon++);

                tmDest.tm_mday = (int)(n4Day - _afxMonthDays[tmDest.tm_mon-1]);
                break;
        }

//DoTime: Not needed
        if (nSecsInDay == 0)
                tmDest.tm_hour = tmDest.tm_min = tmDest.tm_sec = 0;
        else
        {
                tmDest.tm_sec = (int)nSecsInDay % 60L;
                nMinutesInDay = nSecsInDay / 60L;
                tmDest.tm_min = (int)nMinutesInDay % 60;
                tmDest.tm_hour = (int)nMinutesInDay / 60;
        }

        return TRUE;
}

---

For those who say they need goto for the purpose of a clean-up section, you can easily use the above method instead of a goto.

Second Example:

Code:

---

std::string foofoo(void)
{
        std::string ReturnValue;
        for(;;)//end less loop
        {
                //Put your main function code here
                //Use break to exit and get to your cleanup section
                //End of your main function code
                break;
        }
//Do clean up here
        return ReturnValue;
}

---

Yet another execuse for goto put to rest.

There's absolutely no need for a goto.
For every example you can post for a need for a goto, any moderate C++ expert can post a replacement method that can do the same without the goto.

Ok, that last post didn't come out right. Let me see if I can repost without the stupid smily face.

Code:

---

std::string foofoo(void)
{
        std::string ReturnValue;
        for(  ;  ;  )//end less loop
        {
                //Put your main function code here
                //Use break to exit and get to your cleanup section
                //End of your main function code
                break;
        }
//Do clean up here
        return ReturnValue;
}

---

You have missed the point. Anything that can be done with a while, switch, if, for can be done with a goto. Just because a keyword is unnecessary does not mean it should leave the language.

Quote:

---

Originally posted by galathaea
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. ...

---

Unless there is ONLY one person (and that person is NEVER going to change) who will ever maintain the code, I disagree.

I would think you would strongly encourge your programmers to agree on a standard, and whatever they did agree on, I would guess it wouldn't be what you posted in your example.

Regards,
John Flegert

As an addition, look in this forum. There is currently a topic asking for comments about if, then, else. I don't see anyone suggesting using goto.

I am trying to show that all of the fears of goto are fears of bad design principles. If you agree on a particular set of design principles, then you can use any keywords you feel comfortable with and not confuse any future development. I still don't feel that any of the comments against the use of goto have had anything to do with the problems goto may present to a development cycle. They have all seemed to me to be bad design principles in general. It is my position that the ONLY thing that a development group should have to agree on is their design principles. This is the classic linguistic argument against word-related syntax being the focus of a linguistic debate and the argument for a complete grammar related debate on form.

Quote:

---

I am trying to show that all of the fears of goto are fears of bad design principles.

---

Again, goto has nothing to do with design. Absolutely nothing. It is an implementation detail and a maintenance nightmare, but in no way is it a design issue.

History has shown goto to be bad. If you so happen to think we're smarter now than in the past, go ahead and use it. Please, use it. It may very well be the only way to prove us right.

There is no implementation reason not to use it. It directly causes no runtime problems. All the problems it causes are maintenance related. You ask for implementation reasons not to use it. Well, there are none. That does not mean it should be used.

Jeff

Quote:

---

Again, goto has nothing to do with design. Absolutely nothing. It is an implementation detail and a maintenance nightmare, but in no way is it a design issue.

---

But all of the reasons against using goto seem to be based on the use of bad design. What I have been saying is that the implementation of a branching structure is never a problem if one is following good design principles. I do understand the difference between design and implementation. It is precisely the linguistic differentiation that I have been making! If you are using a good set of design principles, I have been arguing that the implementation is immaterial to "goodness" or "badness" of maintainability. This was the reason for the shift of computer language theory from keyword-based syntax of the 50s and 60s to a form-based analysis of grammars in the Object Oriented generation.

Quote:

---

the implementation is immaterial to "goodness" or "badness" of maintainability.

---

Implementation is crucial to maintainability. Software changes. Not matter how well it's designed, there is always a bit of evolution involved. It grows and changes. Bugs are fixed, features are added. That method you wrote 10 years ago, the one with the goto in it, may have gone through many modifications. Software is not something you write well once and leave sit. That's a nice thought, but it doesn't work that way. If it was so, then the use of goto would hardly be an issue. But it's is not so, and it is an issue.

Jeff

Are there any problems with maintainability of a goto statement when the code is updated in a manner that follows good design principles? The design principles that I think are most relevant are:

• Variables (in any language) should be declared/initialized at the start of the code block in which they are used (a "Declared Use" idiom).
• Code blocks (in any language) should be as atomic as possible (an "Encapsulation" idiom).
• A naming convention for all identifier types should be agreed upon by the developers before production (a "Namespace Maintenance" idiom).
• The execution flow of a code block should follow in its reading the originally designed flow for the functionality desired (a "Flow Maintenance" idiom).

The point is that I do understand that the implementation will change as development progresses over the products lifetime. But, as long as design principles are followed, the implementation should never affect maintainability. This was the reason for the switch in linguistic research to form in the first place, ie. to provide for keyword independent rules that allow the creation of useable and maintainable code. If goto is an exception, then it is important to find out why because this would invalidate the current state of this line of research.

I am glad this thread is pursuing these issues, because it is very important to the entire field of general design principles, and I hope there will be more posting from all of those who have an interest in expanding this field.

So I will repeat my question. Are there any problems with maintainability of a goto statement when the code is updated in a manner that follows good design principles?

galathaea,

You mentioned 4 design principles above.

Let's look at your "if (...) goto here; ... here:" vs
the standard "if(...){}" syntax.

using if (...) goto here; ... here:"

• you can not even declare std::vector to be used inside the block.
  
• you can not do a "int i=0" , inside a block
  
• you can do the following inside of the block:
  
  
  Code:

  ---

  int i;
i=0;

  ---

  but the i remains in scope after the block.
  

doesn't the above violate the first 2 rules you gave ?

This is why you should either declare the variable at the head of the block, or create a new block inside. This was the point of my switch example earlier. The design principles are not followed, and goto had nothing to do with these problems. I am wondering if, by FOLLOWING the design principles, one can do anything mischeivous with goto.

So if you declare a new block inside, what
exactly is the point of the goto and the label ?

Code:

---

if (...) goto here;
{
...
}
here:

---

Removing what is in bold above leaves the standard "if() {}".

Then later you need to add an "else" block - it really starts
to get to be a mess. Sorry, but this use of goto of your is
definitely bad.

(You'll notice I am saying this particular use of goto is
bad, not all uses. But it is uses like this that have
caused people to want to never use them.)

Quote:

---

am wondering if, by FOLLOWING the design principles, one can do anything mischeivous with goto.

---

That's a big 'if'. That's not something that is easily guaranteed, no matter how many code reviews you do. I would guess that most products don't and won't follow these principles.

Theoretically, you may have a point. In practice, I believe the use of goto will degrade the maintainability of a product because when not following the principles you mentioned, goto will be a more serious problem than other flow of control structures.

Jeff

What exactly about the goto is bad but the if good? What I am getting at is that this is just a code fashion preference. Some might say to use a switch, some if, some goto. The reason I picked this as an example is that it precisely relates to these issues and does not give goto an unfair advantage (such as stepping out of nested blocks, which allows one to exit without the need to pollute variable namespace and does not make the original logic more complex with variable tests to exit). I understood completely that the fragment I posted was possible in many other ways. What I desire, though, is a reason why it is worse than the alternatives. Each alternative has its own blocking structure that may or may not be useful. I personally would use an if on the occasion that I needed to declare more variables, because it provides the proper block structure I desire. Remember, I didn't put any variable declarations in my original code. But I still would not have a problem if one of my developers submitted something like that.

So, why is goto bad but the if good?

goto is an unconditional branch that is separated from the reason for the branch. Other control structures have the reason built in.

Jeff

One thing is also that goto has no programming logic built into it. When you see a for loop you know what it is. When you see an if () statement you know what it is and how it behaves. When you see a goto, it could mean pretty much anything.

The goto statement doesn't hold any information about what the semantics of the code are. This is a loss when you could use a statement that has in-built semantics.

This does not mean I'm entirely against goto in all cases, but most of the time it's clearer to use a more appropriate statement. Of course this hasn't been said before :D

jfaust, I concede to your superior debate move. Absolutely! It makes absolute sense. Because it should be a design principle that one should keep a branch connected to the logic of the branch. And so, this design principle invalidates the use of goto ever. Of course, I could argue that one could still use goto if the branch condition is connected to the goto in a complete statement group (if, goto) but then you have maintainability issues. Brilliant!

** galathaea spins melodramatically at the fatal shot to the heart **

Whispered, last gasp: "I have been fell by the greater rhetorics of jfaust. All should follow his advice. Never use goto."

galathaea,

You must be the most fun person to debate with. ;)

Thanks for pressing the issues--made me think more about it than I have before. It's always good to revisit 'beliefs', and see if there's any sense to them.

Jeff

Quote:

---

One thing is also that goto has no programming logic built into it. When you see a for loop you know what it is. When you see an if () statement you know what it is and how it behaves. When you see a goto, it could mean pretty much anything.

---

Some times less information is better information. I do not think goto mean "pretty much anything". It has only one unambiguious meaning: Jump to where label specifies.

Your boss may tell you: step outside the office door, make a left, go downstairs, make a right, exit the building, left turn into a place where a lot of cars are parked, get in your car, exit the parking lot and get on the highway, etc. etc. All these are very specific and very detailed information but the more specific it is, the more confused you will be. You boss might just tell you to "go home and come back tomorrow". It's a much less specific instruction but it is much less confusing.

goto is pretty useful and helps readability where there are multiple opening and closing curly brackets ({}'s) between the goto statement and where the goto label is. It is more so when the code is badly formatted and it is hard to match opening and closing {'s and }'s.

See this code:

Code:

---


    //...
    break;
    }}}}}}
    //..
    {
    //..
    // A couple hundred code lines.
    }}

here_we_go:

---

So by reading the above code, how is it clear to you that when it hit the break statement, it will break all the way out of all the {'s and }'s and lead you next to here_we_go?

To reach that conclusion, you would have to look at each { and }, find its matching partner, and look at whether it is a for loop, a if/else or a while, and decide whether you should break out of that scope. If there are a dozen of them, and the opening and closing {}'s are several hundred lines apart from each other, plus they are not formatted to be aligned with each other, you will have a VERY DIFFICULT TIME figuring out where you go, after the break statement.

Where as if I used goto, it's going to be a no-brainer where I go next.

Well, if I would take that point further, I would never use break in any program since that statement also doesn't hold any semantics. You pointed this out quite successfully in your example.

But, the point I was trying to make about goto is that if there is an option with semantics, prefer that one.

As to my statement that goto can mean anything... It depends on how the programmer uses it, but as you know assembly, you know what you can do with unconditional jumps. So well, let's say pretty much anything ;)

Code:

---

  if (i == 5) goto label_true
  result = 16;
  goto label_end
label_true:
  result = 25
label_end:

---

if-then-else loop for example

Code:

---

  i = 0;
label_loop:
  if (i >= 5) goto label_end
  result = result * i
  goto label_loop
label_end:

---

for loop...

Code:

---

  for (i = 0; i < 5; i++) {
    if (i == 3) goto label_break
  }
label_break:

---

the break example...

etc...

P.S. I actually never use break in any program ;) There is nothing evangelical about it but I just don't find the need for it.

Hi, all. Here one reason to use "goto":

Say you have long sequence of system calls.
Each system call you have to check return value.
If system call failed, the rest of sequence is useless,
but you have to clean-up some handlers.

With ussage of goto, the code is like this:

if (sys_call1(param) == -1)
goto cleanup;

if (sys_call2(param) == -1)
goto cleanup;

if (sys_call3(param) == -1)
goto cleanup;

if (sys_call4(param) == -1)
goto cleanup;

cleanup:
free_param(param);

Now, with C++ you have alternative - throw exception.
Or you can split it to set of subfunctions and do cleanup
in other function at all.
Both alternative solutions that I see are longer and harder.

Do you have better solution ?

Hi, all. Here one reason to use "goto":

Say you have long sequence of system calls.
Each system call you have to check return value.
If system call failed, the rest of sequence is useless,
but you have to clean-up some handlers.

With ussage of goto, the code is like this:

if (sys_call1(param) == -1)
goto cleanup;

if (sys_call2(param) == -1)
goto cleanup;

if (sys_call3(param) == -1)
goto cleanup;

if (sys_call4(param) == -1)
goto cleanup;

cleanup:
free_param(param);

Now, with C++ you have alternative - throw exception.
Or you can split it to set of subfunctions and do cleanup
in other function at all.
Both alternative solutions that I see are longer and harder.

Do you have better solution ?

Quote:

---

Originally posted by arkadi
Do you have better solution ?

---

Yes. You are trying to do too much in one method. Break it up. Have one simple well-defined purpose per method. If you have system calls that allocate memory, wrap that logic in a simple class that handles the deallocation in the destructor. There are several things you can do to clean this up, even if you ignore the use of goto.

Besides, I don't think your contrived example is valid. You are allocating memory several times and only freeing it once.

Jeff

Quote:

---

Besides, I don't think your contrived example is valid. You are allocating memory several times and only freeing it once.

---

You know, it`s pseudo code :)

param = malloc(size_param);

if (sys_call1(param) == -1)
goto cleanup;

if (sys_call2(param) == -1)
goto cleanup;

if (sys_call3(param) == -1)
goto cleanup;

if (sys_call4(param) == -1)
goto cleanup;

cleanup:
free(param);

Quote:

---

Break it up. Have one simple well-defined purpose per method. If you have system calls that allocate memory, wrap that logic in a simple class that handles the deallocation in the destructor

---

Yes, it is solution. But:
Does it make code cleaner ?
Does it make writing code faster ?
When you come to somebody`s old code, what do you prefer:
10 strokes that uses "goto"
or 50 that implements work-around ?

Quote:

---

Originally posted by arkadi
Does it make code cleaner ?

---

Yes.

Quote:

---

Does it make writing code faster ?

---

Almost always not an issue. And if it is, inlining can solve it.

Quote:

---

When you come to somebody`s old code, what do you prefer:
10 strokes that uses "goto"
or 50 that implements work-around ?

---

I'm not talking about implementing a work-around. "Not using goto" is not a work-around. It's a good coding practice for all the reasons brought up previously. Wrapping resource in objects that free the memory on destruction is also a good practice--look up RAII for more information.

When all of this is done, your example could be less than 10 lines, and certainly not 50.

Jeff

I've worked on systems where error handling needed to be done like that. Actually, rather than using gotos, the following code was used:

Code:

---

int aFunction()
{
    int res;

/* Some enter function trace statements */

    res = fn1();

    if (res == 0)
    {
        res = fn2();
    }

    if (res == 0)
    {
        res = fn3();
    }

    if (res == 0)
    {
        res = fn4();
    }

    /* ... */

    /* Some cleanup */

    /* Some exit function trace statements */

    return res;
}

---

The need here was to maintain a single exit point for the functions so that traceing would work -- and the functions WERE split up appropriately with good structure. Personally, I think that goto's would have performed better when an error did occur. However, the argument against this was "we only care about performance when things are working as they should." This seemed to be valid for the application in question.

- Kevin

Quote:

---

When all of this is done, your example could be less than 10 lines, and certainly not 50.

---

While other reasons are matter of taste, this can be shown.
Please, submit your solution.

Quote:

---

Originally posted by arkadi
While other reasons are matter of taste, this can be shown.
Please, submit your solution.

---

More than a matter of taste. We've tried to show the dangers of using goto. But anyway, here's my solution. The code provided above was not a real-world example, so neither will this be a real-world solution. Most importantly, the names will not be meaningful.

Code:

---

// should use a more meaninful name
class ResourceAquirer
{
public:
    ResourceAquirer()
      : m_param(0)
    {
    }

    ~ResourceAquirer()
    {
          if( m_param )
              free(m_param);
    }

    // this would be a more meaningful method, perhaps returning
    // the string from the registry.
    res_type getResource() const
    {
          // The logic goes here to allocate the resource if it has not
          // been already, aka lazy evaluation/initialization.
          if( m_param )
          {
              return m_param;
          }

          m_param = malloc(param_size);

          // Now get the resource.  Note there's no need for a
          // cleanup section since the memory is freed in the
          // destructor, hence no desire to use goto.
    }

private:
    res_type  m_param
};

int aFunction()
{
    ResourceAquirer r;
    if( res_type res = r.getResource() )
    {
          // use resource or better yet, put the logic into
          // the ResourceAquirer class to use the resource.
    }
}

---

Now we have a reusable class that maintains the logic and the memory of aquiring a certain resource. This can be safely reused where needed. Note the user does not have to ever worry about freeing up any resource. It will be freed for him, even in the face of a thrown exception.

Jeff

Ok, it`s not 50 lines, it`s 47 :)

My sample was not about resource management.
It was about error handling.
Do you have ideas about error handling ?

Quote:

---

Originally posted by arkadi
Ok, it`s not 50 lines, it`s 47 :)

---

Sure, if you count the reusable code with that. If you are looking at it from the method level, we've got 3 lines that does everything your original logic did. This is an important distinction. When you are debugging, after you know ResourceAquirer works, you can ignore it wherever it is used. You can ignore all that code and more quickly zero in on the real problem.

Quote:

---

My sample was not about resource management.
It was about error handling.
Do you have ideas about error handling ?

---

Your example was about resource management and error handling. And so was my answer. If you encounter an error in my example, you can simply return. Any allocated memory will be freed via the destructor call. Same goes for a thrown exception.

Jeff

Quote:

---

Sure, if you count the reusable code with that.

---

Yes, your code could be reused and some libraries implements that.
But it is not part of standard libraries yet.

What could you do if resource is file or socket handle ?
I quess you will improve your "ResourceAquirer".

What you do if clean-up is: close handlers and
after that remove one of temporary files or directories ?
Could your code be yet universal ?
Yes, you can do it universal.

All that end-up with pretty complex library that do everything.

The kind of my code is frequent case for test programs.
Do you think to add your library on each your test ?

Do you think the code using some monstrous library wroten
by unknown author is simplier than 10 strokes of simple code
that uses "goto" ?

Quote:

---

Originally posted by arkadi
Yes, your code could be reused and some libraries implements that.
But it is not part of standard libraries yet.

---

I'm not talking about writing a standard library. I'm talking about using well-understood and accepted techniques to manage memory and handle errors. Avoiding goto is just a nice side-effect.

Quote:

---

What could you do if resource is file or socket handle ?
I quess you will improve your "ResourceAquirer".

---

I would write a Socket class. I would write a File class. These classes would control the allocation and deallocation of system resources.

Quote:

---

What you do if clean-up is: close handlers and
after that remove one of temporary files or directories ?
Could your code be yet universal ?
Yes, you can do it universal.

---

Correct, however I don't like the idea of doing too much in destructors. You have to be very careful that destructors never ever throw exceptions or cause exceptions to escape.

Quote:

---

All that end-up with pretty complex library that do everything.

---

Not complex. It does not have to do everything. As your software needs more functionality, it can be added.

Quote:

---

The kind of my code is frequent case for test programs.
Do you think to add your library on each your test ?

---

I think it would make perfect sense to reuse this for test programs.

Quote:

---

Do you think the code using some monstrous library wroten
by unknown author is simplier than 10 strokes of simple code
that uses "goto" ?

---

I don't know where you get "monstrous" from, or where you get "unknown author" from. Software projects have source control with history. Good code has comments and follow accepted idioms (in this case, RAII).

Yes, I think a Socket class that wraps calls specific to the application you are working on is "simpler" than doing it by hand each time.

Your code is not exceptions safe. The memory will not be freed if an exception occurs. Your code cannot be reused (aside from copy and paste). Your code is not self-documenting. If it was in a class called "Socket" in a method called "open", you know what it's trying to accomplish even before you examine the code. But the best part is, you may never even have to look at the code! If this class is used elsewhere correctly, you can feel pretty confident that it works correctly.

Yes! It's simpler!

Jeff

The use of more than one statement with any of the "good" keywords require braces, which mark the code section affected by the keyword. goto has no such requirement, and in fact it might be impossible to place such braces if there is more than one goto.



There are a few gotos in the MS CRT implementation of printf (actually output, which lies at the heart of all the *printf functions) btw.

Quote:

---

There are a few gotos in the MS CRT implementation of printf

---

Nice argument.
In g++ implementation you have it even more
( see "iovprintf.c"::_IO_vfprintf ).

But lets get back to theoretical issues.

Quote:

---

I don't know where you get "monstrous" from, or where you get "unknown author" from.

---

If author of code is not hired few years, its name in documentation is almost meaningless.
Hence I stand on "unknown author".

About "monstorous" ... well, at it start it must not be.
It could be rather big.
With few iterations it can become monstour, but if you do
some hard administrative effort, you can avoid that for few years.

About RAII. Here is a quote from http://www.hackcraft.net/raii site (I hope you trust that site while talking of RAII):

Quote:

---

However once the class is tested, trusted, and well known these can be stepped over and the task of stepping through code is simplified.

---

There are some other drawbacks if class is not "tested, trusted, and well known".

The problem appear when none of that prerequirements are valid.
If you prepear basis for some application that will be in OO design, you will be able to prepear "tested and trusted" library.
But even you switch to other project I have a suspect if you
could be able to use the same code.

Finally:
1. You have to create library.
2. You perform non-trivial administrative effort to keep it consistent in all projects.

Question is what you get back ?
1. Less code is for sure not - your library is code too, even if it is standard for you.
2. Argues with other developers that don`t like your implementation.
For example thay don`t like your naming convention :)
3. Hence library is not trusted and not sure if tested,
you get trobles in debugging logic code for other developers.
Your peace of troubles you get while implementing the library :)

#2 is invalid - I'm sure you get a lot more arguments with other developers if you use goto.
#1 is not so sure. If it's something very common (like smart pointers), you get a lot more back than you put in.
#3 isn't so sure either. A simple RAII class is very easy to implement.

Quote:

---

I'm sure you get a lot more arguments with other developers if you use goto.

---

If they don`t have to bother with your code at all, they have nothing to argue about.

Quote:

---

If it's something very common (like smart pointers), you get a lot more back than you put in.

---

The difference form smart pointers (like ATL) is that smart pointer classes are tested by vendor and trusted by each developer after it`s own positive expirience with it.

Quote:

---

A simple RAII class is very easy to implement.

---

Usually yes, but you have to do it.
And as any code it can be buggy :)
Again it`s matter of testing and trust.

i think if you write a function with many goto
1.you will not be able to understand your function when you saw the function you writed many days ago.
2.ussually lead to fault

I now in high school but my C++ book says so many goto not good, i think iit not be good to use,

Sincerely

Jeff