goto

[AlexanderCZ]

What is bad on using goto statement???
I often heard:"if you use goto,you can't make good programs.."
What do you think about it?
I think you are better programmer when you can use goto statement then somebody who can't use it...

[Sput]

I was also taught Goto statements are bad. They are evil constructs that allow program flow to just jump practically anywhere.

But I do use them once in a GREAT while. Why? Lets say you have a method that is allocating a bunch of resources/memory. And at anypoint, you could receive a error condition. To keep the method clean/readable, I have used a goto statement to jump to the end of the method. This way I have one exit point of the method that frees everything up. Less chances for memory leaks.


Disclaimers:
a) The below is a VERY simple example. Just here for demonstration
b) There are other ways of solving the memory cleanup without using gotos
b1) re-organize without goto
b2) exception handling
b3) smart pointers concepts


void MyFunc()
{
type* p1 = NULL;
type* p2 = NULL;

p1 = new type[50];
if (something bad)
goto FuncExit;

p2 = new type[2];
if (something bad)
goto FuncExit;

do some other code with other possible exit points

FuncExit;
delete [] p1; // works if p1 is NULL;
delete [] p2;
}

I can't think of an example of me using goto in my current project. Buts it there in my bag of tricks.

[PaulWendt]

Let the debate begin.

Honestly, anyone can use goto; that's part of the problem. When
used improperly, goto can lead to circuitous and confusing code.
When used carefully, goto can save time and ... <gasp> ... even
make things more readable. The problem is that everyone has
different opinions on what proper goto usage is. Also, most
things can be done without goto with no problem so more
tradational control structure are preferrable in my opinion.

One instance <I> consider goto useful is if you're in two [or more]
loops .. and from the inner loop, you want to break out to the
outer loop. You could just set the outer loop's terminating
condition to get out of that loop, too.

The big problem with goto and C++ is that goto will skip
destructor calls if you goto a spot that's out of a created
object's scope.

Given the inherent complexity and potential misuse, I don't use
goto. I WOULD use it if I found an instance where I really needed
it ... but I'm usually able to get by just fine with the other features
of the language. The more low-level you get with your
programming, the more useful you might find goto. I try to
program on as high a level as I can most of the time

--Paul

[dude_1967]

Hi gurus,

Generally we do not use goto in our group. We discourage ist use but do not forbid it.

We actually do use goto for improved readibility and clarity when dealing with assembler labels in mixed assembler / C / C++ development of hard real-time operating systems.

There are other flow-control statements such as break and continue. Along the same lines, some radical developers even try to eliminate the use of these (relatively) harmless flow controls. I've got no real opinion here.

Chris.

[jflegert]

Paul,

The big problem with goto and C++ is that goto will skip
destructor calls if you goto a spot that's out of a created
object's scope.

Could you expand on this? I just did a little test code (I had a goto exit a for loop with a variable defined in the for loop) and the destructor got called.

Thanks,
John Flegert

[Graham]

Originally posted by Sput
[...] Lets say you have a method that is allocating a bunch of resources/memory. And at anypoint, you could receive a error condition. To keep the method clean/readable, I have used a goto statement to jump to the end of the method. This way I have one exit point of the method that frees everything up. Less chances for memory leaks.

No, no, no (at least, in the C++ world). You have said that there are other ways of solving memory cleanup. Quite right, RAII (Resource Acquisition Is Initialisation) reduces (or eliminates) resource leaks. Do not even suggest the cleanup on exit "solution" - it isn't a solution: don't ever do it. All the points you make under (b) are valid reasons to never use the "cleanup on exit" approach. In fact, b2 is enough on its own:

void MyFunc()
{
    type* p1 = NULL;
    type* p2 = NULL;

    p1 = new type[50];
    if (something bad)
        goto FuncExit;

    p2 = new type[2]; ***
    if (something bad)
        goto FuncExit;

    do some other code with other possible exit points

FuncExit;
    delete [] p1; // works if p1 is NULL;
    delete [] p2;
}

Suppose the "new" at *** throws an exception (like it's supposed to do, VC++ notwithstanding), or the bulk code throws. p1 (and, possibly, p2) does not get deleted - you have a resource leak. The only way to avoid this is to allocate the resource in an object's constructor and release it in the destructor, because the the destructor will always be called.

void MyFunc()
{
    std::vector<type> p1;
    std::vector<type> p2;

    p1.reserve(50);

    p2.reserve(2); ***

    do some other code with other possible exit points
    and possible exceptions thrown
}

This code is resource safe. No matter how the function exits, the memory grabbed by p1 and p2 will be freed - and any destructors for objects stored in the vectors will be called.

Putting in a goto to a mythical cleanup section gives a false sense of security - it is not safe.

So, the one "use" of goto that you advocate is unsafe and unnecessary.

Paul: I would suggest that goto out of a nested loop reduces readability - others may disagree: I don't want to argue the point. I would also suggest, though, that it indicates a design flaw. I've written some pretty hairy nested loops in my time and (apart from the bad old days of FORTRAN), I've not found a need for goto. in fact, in recent times, I've even managed to avoid break and continue in loops. There are no hard and fast rules, but often factoring out inner loops and conditional sections of loop bodies dramatically increases readability and maintainability. In fact, I'll stick my neck out here: if you want to use a goto, consider refactoring (or using RAII properly) instead.

[Sput]

Graham: Sorry about the example. Thats what the disclaimer was for. Especially the first one (A). I should of given a better (more valid) example. Maybe one not using memory, and one such that all paths don't automatically work.

Looking at my 30-second-to-write piece of source code, your comments about it are correct.

The only point I was trying to make is that if you allocate/use resources ( memory or OTHER ) and your method is coded to have multiple exit points, one use of the GOTO statement is to jump to the end and have one place for resource cleanup/release and one method/function exit point. Situations like this usually end up happening due to multiple conditions or loops. (although, you can always take a step back and see if you can restructure the source )

oh yea... By other resources, I'm thinking if could be files (close or delete), threads, etc... I don't know. Theres always many ways to solve the same problem. I just don't dismiss the use of Goto. Although, I don't always recommend or use it either.

One question though:

Suppose the "new" at *** throws an exception (like it's supposed to do, VC++ notwithstanding), or the bulk code throws. p1 (and, possibly, p2) does not get deleted - you have a resource leak. The only way to avoid this is to allocate the resource in an object's constructor and release it in the destructor, because the the destructor will always be called.

If I understand what you are stating, If you use the smart pointer concept (allocate in constructor, free in destructor) then once the exception is thrown, all destructors in the method are called. Is this true? Or just whats in the Try block. I don't use exceptions that much (nor is it encouraged at my work to do so). Only when calling code that uses exceptions.

As far as the smart pointers concept. Thats usually what I do. This concept can even be taken as far as to create a template utility classes for selecting GDI objects into the DC (in ctor) and releasing in dtor (destructor). hhmm.. I can vaguely remember dealing with this in complicated c functions (in my sdk days) using Gotos.

[galathaea]

The keyword goto is a there if you need it, so don't be afraid to use it. There are better design implementations possible, though, so if you are looking for something that is consistent and readable, I would look into things like termination handlers. Especially for cleanup routines. Wrapping some code in __try, __finally will help if you don't have any need for strong c++ handling of scope and destructors.

[Graham]

Originally posted by Sput
Graham: Sorry about the example. Thats what the disclaimer was for. Especially the first one (A). I should of given a better (more valid) example. Maybe one not using memory, and one such that all paths don't automatically work.

... and my point is that you'll waste an awful lot of time looking for a better or more valid example. There aren't any. The set of situations in which the use of goto is elegant, readable, maintainable and correct is vanishingly small.

The only point I was trying to make is that if you allocate/use resources ( memory or OTHER ) and your method is coded to have multiple exit points, one use of the GOTO statement is to jump to the end and have one place for resource cleanup/release and one method/function exit point. Situations like this usually end up happening due to multiple conditions or loops. (although, you can always take a step back and see if you can restructure the source )

... and my point was that it doesn't address the whole problem. You can still leak resources, so do do it properly (with RAII) or don't bother.

If I understand what you are stating, If you use the smart pointer concept (allocate in constructor, free in destructor) then once the exception is thrown, all destructors in the method are called. Is this true? Or just whats in the Try block. I don't use exceptions that much (nor is it encouraged at my work to do so). Only when calling code that uses exceptions.

Absolutely - that's why RAII works. As soon as a fully constructed object goes out of scope, for whatever reason (short of something disastrous, in which case it won't matter), its destructor will be called.

As far as the smart pointers concept. Thats usually what I do. This concept can even be taken as far as to create a template utility classes for selecting GDI objects into the DC (in ctor) and releasing in dtor (destructor). hhmm.. I can vaguely remember dealing with this in complicated c functions (in my sdk days) using Gotos.

RAII is about managing ALL your resources, not just memory. Don't restrict yourself to smart pointers: GDI resources, locks, whatever: if it's a resource that needs managing, RAII handles it. That's why I don't like Garbage Collectors: they may well manage memory, but in the process you lose deterministic destructors, so all the other resources that could have been managed are now subject to leaking. Here's an example that doesn't involve memory at all:

class DatabaseLock
{
public:
    DatabaseLock(Database* db)
    {
        // Obtain a lock on the database to prevent concurrent write
        db->StopOthersWriting();
    }
    ~DatabaseLock()
    {
        // Release the lock
        db->AllowOthersToWrite();
    }
};

void WriteToDatabase(Database* db)
{
    DataBaseLock lock(db);

    // Write to database
} // Lock released as lock object goes out of scope.

Imagine that in the process of writing to the database, the system throws an exception....
How does the above compare with:

void WriteToDatabase(Database* db)
{
    db->StopOthersWriting();

    // Write to the database

Done:
    db->AllowOthersToWrite();
}

How long will that database stay uncorrupt?

[Graham]

Originally posted by galathaea
The keyword goto is a there if you need it,

you don't need it

so don't be afraid to use it.

I'm not afraid to use it - I choose not to contaminate my code with it.

There are better design implementations possible, though,

Absolutely

so if you are looking for something that is consistent and readable, I would look into things like termination handlers.

Why?

Especially for cleanup routines.

Use RAII. What are cleanup routines?

Wrapping some code in __try, __finally

No such keywords in C++

will help if you don't have any need for strong c++ handling of scope and destructors.

I don't understand that last statement - you always have to consider and deal with scope. You may only ever use simple classes that have trivial destructors, but at some point you'll have more complex needs.

[jfaust]

The keyword goto is a there if you need it, so don't be afraid to use it.

That's the problem. It's a very simple concept to use. So simple that a beginner can use it, and feel confident he/she knows what's happening. It's so simple that it might seem like the way to go. I like the "simple is best" approach. I preach the K.I.S.S. principal. That is not the case here.

I think if you are ever considering using a goto, that you should be afraid. You should step back and take a serious look at it. You should discuss it with a colleague. You should find different solutions, and convince yourself that this is really best. And even then, you should document it heavily. I've spent enough time sifting through old (I mean old) FORTRAN, that gotos make me cringe.

I suppose you could come up with a situation where a goto really does solve the problem better than other solutions. I don't know. I can't think of one, and I have never seen one. That doesn't mean it doesn't exist.

Jeff

[PaulWendt]

Originally posted by jflegert
Paul,

Could you expand on this? I just did a little test code (I had a goto exit a for loop with a variable defined in the for loop) and the destructor got called.

Thanks,
John Flegert

Oops What I meant was the "goto" concept. Um ... in other
words, there are things called "nonlocal goto's"; these are the
setjmp() or longjmp() functions. If you use THESE functions, your
destructors will not get called [depending, of course, on your
compiler]. So, the 'goto' itself will let destructors be called, but
certain goto constructs won't.

I guess this discussion is about the 'goto' keyword and not the
concept of "goto" statements. Either way, I don't use very many
goto-type statements.

--Paul

[AnthonyMai]

Graham said:

The big problem with goto and C++ is that goto will skip
destructor calls if you goto a spot that's out of a created
object's scope.

That's a reasonable imagination of what could happen. But unfortunately it is NOT TRUE. Don't spread the rumor. Check the fact first, Graham!

I am not sure whether it is in the standard or not. But all compilers I used are smart enough to figure out that a "goto" would jump to an outside scope, and it will call appropriate destructors for objects declared in inside scopes. Same as when you call "return" it will call all appropriate destructors.

And compilers are also smart enough to prevent you from "goto" an inside scope. The only place you can go to are the places within the same scope, or outside current scope but still within the function scope. i.e., you can jump out of a scope but not into a scope.

[AnthonyMai]

Graham said:

Oops, my eyes skipped lines. The wrong statement was made by Paul, not Graham.

[jfaust]

Originally posted by Anthony Mai
you can jump out of a scope but not into a scope

You can jump into a scope just fine:

int main()
{
	if( 0 )
	{
inner_scope:
		return 0;
	}

	goto inner_scope;
	return 1;
}

Jeff