goto

Quote:

---

Originally posted by Axter
I have not run into any condition in which I thought, “Wow! …. A goto statement would work so much better here!”

The use of goto’s too often results in spaghetti code, that is hard to read, and hard to maintain.
My advice is NEVER, NEVER, NEVER use a goto statement….. There always a better non-goto method to accomplish the same thing or better.

It’s not required for C/C++ programming, and your code will be easier to follow and easier to maintain without it.

---

Absolutely agree.

(Slightly OT, but...) Was there ever a greater abomination in a coding language than VB's "On Error GoTo"? On those occasions when I have to debug VB code, I break out into a cold sweat whenever I see that, because I just know that I'm going to find myself suddenly warping to a different place in the source with only a vague idea of where I came from.

Can any one dispute the legitimate use where you use a GOTO to break out of several nested loops. It is definitely more concise and more readable than using multiple "break"s to achieve the goal.

In principle, there is nothing that must be accomplished using goto and can't have an alternative solution. In practice, in some situations, goto is more concise, more readable, and one would be more attempted to use goto than an alternative solution.

Using good judgements and try to avoid goto where possible, but use it where it seems to be better, is one thing. Observe the abstence of goto like the eleventh commandment and swear to never ever use it, that's another thing. That's not rational. That's religious.

It's like alcohol. There are much more bad things than good things in alcohol. Drunken drivers being one, amoung other things. In principle, one can live without alcohol. In practice, it is good to try to avoid aocohol as much as possible, but DO drink it when the occasion is appropriate. If you observe the absolute abstence of alcohol, then you have become religious.

You can try to convince me in each and every specific situations, it's better NOT to drink alcohol rather than drink it. But if you are trying to convince people to observe the absolute abstence of alcohol under all situations, then that is just too much.

I never use goto and actually never use break or continue. But then again, I can see advantages of using it. Maybe Antony's example isn't compelling, although it's not easier or harder to read than Axter's change IMHO.

Programmers who write a lot of C-style code mixed with assembler code might prefer to use gotos. This would lend itself to situations where you have a few asm blocks inside a function, but don't want to code the whole function in asm. I can see nothing majorly wrong there, since using asm usually involves jumps anyways.

On a side note, the VB On Error Goto statement can be helpful for automatically debugging your application. It is also essential for working with COM objects since VB just throws an error if the HRESULT is not S_OK. But well, VB isn't the nicest programming language anyways ;)

Code:

---


        for (int x = 0;x < 100;++x)
        {
                bool BreakOutOf_X_loop = false;
                for(int y = 0;y < 10;++y)
                {
                        if (y == 5 && x == 10)
                        {
                                BreakOutOf_X_loop = true;
                                break;
                        }
                }
                if (BreakOutOf_X_loop) break;
        }

---

IMHO, the above code reads and functions much better using an extra well defined bool variable then using a goto statement.
It's easier to maintain and the logic is easy to follow.

As I stated before, a goto statement is never needed.
If you or any one else which to use it in your code, that is your choice.
Just as it is my choice to call it as I see it. And as I see it, a goto is never, never, never needed.

Well, I prefer using while loops when execution can break inside a loop. This makes it clear that the loop is not always executed a fixed number of times (that's what a for loop means to me).

But then again I programmed in Pascal for a long time before coming to C/C++ ;)

Code:

---

bool BreakLoop = false;
x = 0;
while ((x < 100) && !BreakLoop)
{
  y = 0;
  while ((y < 10) && !BreakLoop)
  {
    if (y == 5 && x == 10)
    {
      BreakLoop = true;
    }
    ++y;
  }
  ++x;
}

---

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. So I give both of them paychecks and we all go home happy. Now my challenge. Is there ANY coding issue with the goto that is being missed? I don't want to know if it can be done differently, since I can think of hundreds of ways. What I am asking is: is there any development issues, actual problems that could come down the line, that can be fixed up with the if but REQUIRES removal of the goto or more work with the goto. Because I have this sneaky suspicion that the only reason people dislike the goto is because "someone greater then thee" has shown disdain at its use, and for no real coding issue.

Really, the while keyword can be looked at as unnecessary. Since I can always do a while with an if/goto combination. Does this really mean I should never, never, never use a while? Or are we really so c++ illiterate that we cannot understand looking at a goto what it does but we can understand a while and some of the more "common folk" tongue. I have no problems with readability, etc.

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?

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

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;

        // 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;
                        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]);

DoTime:
        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;
}

---

The danger of goto is simply that it can be easily abused, and in the past was often abused. This past abuse was largely corrected with an attitude change

It's partly because of the current attitude towards goto that you won't find it abused as it once was. Since goto does not solve any problems that cannot be solved otherwise, I'd rather maintain this attitude.

The logical flow of a method is more easily be muddled with goto. It's non-continuous. It jumps.

Used prudently, with care, goto will not cause a serious maintenance problem. But, because of the ease with which it can be abused, I still feel it is best to not use.

Jeff

Pointers can be easily abused. And as I said above, while doesn't solve any problems that can't be solved otherwise. And there are MANY keywords that jump. If your reasons apply to other keywords besides goto, I see them as invalid. Give me REAL reasons.

** galathaea gives that cheese-western squint **
"Come on space cowboys..."

Quote:

---

Originally posted by galathaea
Pointers can be easily abused. And as I said above, while doesn't solve any problems that can't be solved otherwise. And there are MANY keywords that jump. If your reasons apply to other keywords besides goto, I see them as invalid. Give me REAL reasons.

** galathaea gives that cheese-western squint **
"Come on space cowboys..."

---

What keywords jump? The only I can think of off the top of my
head would be the switch/case constructs, break, and continue.
continue and break do jump, but their jumping is a lot more
limited. Even so, plenty of people have made the mistake where
they forget to put a break in one of their case: areas of a
switch statement. The jumping statements can be misused or
create problems down the road. The thing is that continue/break/
switch/case all are a lot more limited with respect to where they
can jump. Their jumping is a lot more structured than goto's
jump. It's because of goto's flexibility that it can be misused.

So ... yeah, the same problem can exist with all jumping
keywords, but goto is significantly different than these other
keywords so in my opinion, the problem is exacerbated.

--Paul

Real reasons what? There's no reason you can't use goto. It can lead to bad code when used incorrectly. So can other things. The thing with goto was that it was often used incorrectly, leading to remarkably difficult code to maintain.

This misuse was so common that a now well-known paper was written by Dijkstra as to why it was harmful. You've probably heard his name before.

This paper had a tremendous effect on the programming community. This paper is now considered by some to be a little extreme, but coming from the standpoint of 1968, I think his disdain is well placed.

This paper is largely responsible for current attitudes toward goto. Here is a link: http://www.acm.org/classics/oct95/

He sums up my standpoint entirely in "it is too much an invitation to make a mess of one's program".

Jeff

Ifs don't jump? While's don't jump? For's don't jump? I think your definition of jump is not valid since all the things I just mentioned compile to different jumps. Is the problem that you don't know where a goto jumps to but the others you can figure out? Then that sounds like a problem understanding the language. Is the problem that goto is flexible? Is that really a minus? Yes, keywords can be abused to unrecognizability. Just check out the International Obfuscated C Code contest. Mains can be arrays instead of functions. I still think this may be a problem with timid programmers folllowing unsubstantiated "guru" advice instead of independent thinking, and not a REAL issue...

** galathaea gives that cheese-western squint **
"Come on space cowboys..."

Quote:

---

previously posted by galathaea

Code:

---

// inside somewhere

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

// some more code

here:
// some more code

---

---

hmmmmmmm ... try to compile ...

Code:

---

// inside somewhere

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

// some more code
std::vector<int> v(1000000);
int i = 10;

here:
// some more code

---

Forget some brackets ? Easy to do using goto when they were not
needed originally, but something is added later that requires
putting them in.

There is a design principle that I follow that goes like this: always declare local variables at the head of their locality. If you need to create a new locality with new variable declarations, that is simple in c++. Yes, not following good design is a problem. But such a mistake is not a goto problem. It is a design problem. If you have bad design, you have bad design with or without the goto.

** galathaeapistolero blows smoke from the barrel **
"Next space cowboy?"

Quote:

---

Originally posted by galathaea
Ifs don't jump? While's don't jump? For's don't jump? I think your definition of jump is not valid since all the things I just mentioned compile to different jumps. Is the problem that you don't know where a goto jumps to but the others you can figure out? Then that sounds like a problem understanding the language. Is the problem that goto is flexible? Is that really a minus? Yes, keywords can be abused to unrecognizability. Just check out the International Obfuscated C Code contest. Mains can be arrays instead of functions. I still think this may be a problem with timid programmers folllowing unsubstantiated "guru" advice instead of independent thinking, and not a REAL issue...

** galathaea gives that cheese-western squint **
"Come on space cowboys..."

---

I don't have the fundamental misunderstandings that you are
implying. I can't give you a 1-to-1 correlation between C++
keywords and assembly statements, but I realize that if's are
broken down to low-level assembly routines that, of course, jump.
The thing is that an if is very structured; a while is very
structured. A goto ... well it's a lot more low-level. I am not
saying that that low-leveledness is a bad thing, either. I can
think of some times where I'd prefer to use a goto even though
there are other alternatives [like nested loops]. Like jfaust was
saying earlier, the thing with goto is that everyone has their
own opinion with respect to what "proper" usage of the goto
keyword is. Since goto is so low-level, its use should be
considered carefully. Because it's so flexible, I choose to be
careful with it. I, for one, never advocated NOT using it. I don't
use it often, however, and I tend to find the benefits of using it
minor compared to the potential headaches that can arise
through its use.

--Paul