Discussion: goto

[Skute]

Hi,

I know the pitfalls of using the goto statement, and have just this second read a comment from Ion saying he would fail his students if they used the goto statement.

However, surely there are times when it may be useful? For instance, MS use it extensively in their MFC code. I wrote a program the other day in which i experimented with the goto statement, i used it in the following way:

int MyFunction(char* Param)
{
int iReturn = 0;
HANDLE hFile = NULL;

if (!OpenFile())
goto EndFunc;

if (!GetFileSize())
goto EndFunc;

if (!ReadFile())
goto EndFunc;

if (!WriteFile())
goto EndFunc;

EndFunc:

// Close file handles in one generic place
CloseHandle();
hFile = NULL;
return iReturn; // Only 1 exit point in this function, easy to debug
}


Instead of having 5 exit points and 5 close handles in that function, the use of the goto statement meant that i only had 1 exit point, which means it is quite alot easier tracking values that get returned from the function.

MS use it in exactly the same way with their MFC code.


So what do you think?

 

[Cagliostro]

is enough to have CloseHandle(); in a class destructor.
when something if (!goesFine())throw "xxxx";
The only reason you can use goto is what it is fast, and you can use it in timecritical functions.

but about
>he would fail his students
I do not fail them. I just give them the posssibility to try again to pass the exams for several times.
by the way, in many software oriented organizations using of goto is prohibited by theirs policy and if you do it you will be fired.


Ion Filipski

ICQ: 95034075
AIM: IonFilipski
filipski@excite.com

 

[Skute]

ah ok, sorry for mis-interpretation.

What happens if you arent using a class? ie, you are using CreateFile(), GetFileSize(), ReadFile() and WriteFile() of the windows API?

 

[Cagliostro]

it means you should create a wrapper the class by yourself.

Ion Filipski

ICQ: 95034075
AIM: IonFilipski
filipski@excite.com

 

[uolj]

Wrapper class like this:

class SmartHandle
{
public:
    SmartHandle(HANDLE h) : m_Handle(h) { }
    ~SmartHandle() { if (ValidHandle()) CloseHandle(m_Handle); }
    operator HANDLE() { return m_Handle; }
    BOOL ValidHandle() { return m_Handle != NULL; }
private:
    SmartHandle(const SmartHandle& h);
    SmartHandle& operator=(const SmartHandle& h);
    HANDLE m_Handle;
};

int MyFunction(char* Param)
{
    SmartHandle hFile(OpenFile(Param));

    if (!hFile.ValidHandle())
        return -1;

    if (!GetFileSize(hFile))
        return -2;

    if (!ReadFile(hFile))
        return -3;

    if (!WriteFile(hFile))
        return -4;

    return 0;
}

Note that you might need some extra code to make this a good solution, but that is the idea. This seems so much better than goto in my opinion.

 

[LyMc]

As the miscreant in this case, I'd like to point out a little history. Back in my early days (read FORTRAN II) GOTOs were a way of life, and absolutely necessary to coding (anyone remember &quot;IF (<condition>) <stno-less>, <stno-equal>, <stno-more>&quot;?). Algol was known, but not available to most programmers.

Later on, structured programming became the in-thing, with &quot;Gotos Considered Harmful&quot;, Pascal, PL1, and finally C. There was a lot of talk about banishing goto from all the languages completely, but there were also many who could point out cases in which goto's saved code (time and space) and read better (more maintainable) than the equivalent structured code.

Later still comes the current generation of coding techniques in Java and C++. The advent of the throw/catch, the faster machines wherein subroutine calls are not prohibitively expensive in time and so on, have reduced the possible cases of needing to use gotos to nearly nothing. The goto-wars have died away, but it should be noted that the goto itself has not; it's still in Java and the other latest languages. Perhaps there's a reason; I don't know, personally.

My reason for doing it in the place where I did was to bring together the window destruction threads. I have too many times changed code in one place and should have changed it in several, so I tend to group identical actions together in one place. That's weak; it could as well be done with a function call, even an old (pre-class) function. I'd chalk it up to laziness on my part as the major reason, so I stand corrected (with a smile!).

 

[chipperMDW]

A lot of people misconstrue Dijksra's article to mean that goto is so harmful it should be forbidden outright. That's not what he meant; he wrote the article at a time when people's minds were poisoned with BASIC and goto was the only &quot;control structure&quot; anyone ever used. This, of course, made code horrible. He needed to get people off that habit.

Before damning goto, remember that in some cases, even if unnecessary, it can be clearer to use a goto than some other convolution of the other control structures. Remember that &quot;if&quot; and &quot;while&quot; are, underneath everything, forms of goto. All the different variations of selection and iteration statements are simply for convenience in common usages. If a usage comes up such that would be awkward to implement using just the common control structures, it can be more readable to just go ahead and use the goto; &quot;break&quot; and &quot;continue&quot; are just controlled gotos that are used in the common situation of having to quit or restart a loop in the middle.

That said, there are very few, mostly performance-related, situations in which a goto is appropriate. In a programming course, goto should probably never be used, as you'd probably never come across a situation where another control structure would not be better suited.


Also, Java does reserve the goto keyword, but (last I heard) leaves it purposely unimplemented. This is, in my opinion, a case of taking Dijkstra's message too far, though it admittedly has little use in most Java programs.