Thread: Why is goto the devil and exiting programs question.

Keywords such as continue and break do indeed behave like goto; but unlike goto, when I see them, I know exactly where it will jump, because the rules for break and continue are very strict, unlike goto.
Furthermore, if you would use goto, you need to put a label everywhere. And labels do no follow scope rules, so each label would be unique for every loop in a function. So if I said goto StartOfLoop50, I would first need to know which is the loop 50.
And then we have to type out more stuff and clutter the code even more, making continue and break easier to read, decipher and type, hence making goto a worse solution. It might just work, I'm not saying it wouldn't, but in these cases, all I say is that it's unnecessary. There are better alternatives.

In essence I would say: all the legitimate uses of goto has been replaced by other approaches in the language, making goto unnecessary. Where you would use goto to jump around in the code, like the abovementioned example, it's really evil because it hurts readability and maintainability.

I don't fancy reading through that document. It looks so boring. All I want is some examples (in C++!) where goto really improves some part of the code. I would gladly change my notion of goto. Failing that, I will stick to the tried-and-true notion of that goto is evil.

Goto is valid if it truly simplifies the code.

If you have a function which takes a couple of locks and then needs to release them [and there isn't a good way using C++ objects to AUTOMATICALLY lock/unlock using the constructor destructor mechanisms], then a goto to a label that unlocks and returns is better than trying to ensure that all return points have the relevant unlocks. I have found more than one bug caused by a return that the programmer forgot to add the relevant unlock(s) (usually a rare error condition [e.g. out of memory], so no one discovered it early on in testing)

In C++, there is, as I hinted at above, little reason to use locks this way. We can do:

Code:

class Lock
{
private:
    SomeLockingType &theLock;
public:
    Lock(SomeLockingType &lock) : theLock(lock)
    {
       theLock.MakeLocked();
    }
    ~Lock()
    {
       theLock.UnLockIt();
    }
}

Now there is absolutely no need to manually lock/unlock the lock mechanism.

--
Mats

Ah, but there is another way. It's called boost::bind. Use it to bind the unlock functions of all the locks and wrap them in RAII objects whose destructor calls the functor it wraps. I've used this approach before.
Example:

Code:

class ScopedCallerBase
{
public:
    virtual ~ScopedCallerBase() { }
}

template<typename T> class ScopedCaller: public ScopedCallerBase
{
public:
    ScopedCaller(T Functor): m_Functor(Functor) { }
    virtual ~ScopedCaller() { m_Functor(); }
private:
    T m_Functor;
};

template<typename T> ScopedCaller<T>* CreateScopedCaller(T Functor)
{
    return new ScopedCaller<T>(Functor);
}

void MyFunction(Lock& lock1, Lock& lock2, Lock& lock3)
{
    std::auto_ptr<ScopedCallerBase> AutoRelLock1 = CreateScopedCaller( boost::bind(&Lock::unlock, lock1) );
    std::auto_ptr<ScopedCallerBase> AutoRelLock2 = CreateScopedCaller( boost::bind(&Lock::unlock, lock2) );
    std::auto_ptr<ScopedCallerBase> AutoRelLock3 = CreateScopedCaller( boost::bind(&Lock::unlock, lock3) );
}

Somewhat messy, but C++0x will make this easier. I also do believe Boost has some macros and other stuff that simplifies this.
Of course, ScopedCaller, ScopedCallerBase and CreateScopedCaller are all generic so they'll work with everything.

Of course, this is a techy C++ solution (a preferred one, I suppose) and easy to read for the trained eye.

Oh yeah, btw, welcome back, Mats.
I noticed you haven't been around for a while.

Originally Posted by Elysia

I don't fancy reading through that document. It looks so boring.

Well, it really doesn't help your case if you aren't willing to go through a document that is hands-down the most in-depth analysis of the goto statement and find pseudo-code hard to read. I'll be taking that as a "I don't want to know about it. Goto is evil because I think so".

Yeah, that's fine. After all, it's an opinion by me that you're trying to convince
The document might be evidence against the goto paradigm.

Originally Posted by Elysia

The document might be evidence against the goto paradigm.

It is in fact. Knuth is making a case against Goto statements and for structured programming. But he is doing it in a smart way. He's constructing difficult problems to handle without goto and then deconstructing them, showing how to avoid goto.

He then proceeds to show us a few cases where goto can make sense, even if it can be easily replaced by some other language feature. Other than the actual examples and his analysis about them, I find this particular quote rather interesting:

Originally Posted by pag.294 (With go to Statements)

We've already mentioned that go to's do no have a syntactic structure that the eye can grasp automatically; but in this respect they are no worse off than variables and other identifiers. When these are given a meaningful name[...] we need not apologize for the lack of syntactic structure.[...] In other words, we can consider goto statements as part of a systematic abstraction; all we need is a clearcut notion of exactly what it means to goto each label.

Note that he concludes with the idea that goto should indeed have been removed from future programming languages as a legislative maneuver, in order to better educate programmers into the benefits of structured programming. Thankfully, such wasn't necessary as you well know. The goto debate today is nothing like what it was back then when structured programming was emerging in the form of such languages as ALGOL or PL/I.

Let me be clear about what I'm trying to say here...

That I don't understand the hoopla about goto. It's old and it makes no sense these days since you cannot find anywhere someone actively defending their consistent use in modern languages. It's beating on a dead horse. Yes, we all know goto is not good for most programming. Thank you. Move on. Nothing to see here.

So, it's instead a lot more meaningful to learn to identify those cases where goto can make a difference. Because all this goto is evil taught us was ignorance of its use. We aren't trained in its use and we don't know how to take advantage of it or even when to identify the need for it. Goto became the tool of expert programmers. Think about it.

Yes, I do get your point. Now all we actually need is some examples of where goto is a good tool (especially for C++). Then we start digesting good uses of goto and start implementing and experimenting with it elsewhere. Unfortunately, I don't know many good examples, but I am open to good suggestions.
I hope everyone else is, too.

That's one valid example that I know of. Haven't had much use of it myself, though.
But are there other situations?

whatever... You don't wnt to erad it, don't.

You refuse to learn how to identify these situations and instead want to see the pretty pictures? Fine, I'll give you examples where goto is today used by expert programmers:

- Language parsers
- Complex State Machines
- Complex traversing algorithms (complex multi-branch tree traversing rings a bell, but i'm shaky on this one because I can't seem to remember the details of what I read a long time ago)

Originally Posted by Mario F.

More important than showing why goto shouldn't be used, is showing when goto should be used. Anyone with a few weeks of C++ will immediately learn to recognize the benefits of a structured language and doesn't need to be told against Goto. If they don't, their careers in software programming will be short and not warrant the debate. But much, much, more difficult is identifying those moments when goto can become useful.

Keep in mind that this thread was started by Jefff, who is apparently new to (C++) programming. As such, it is more important here to show why goto shouldn't be used than to show when it should be used. As I stated in post #37, "it is only when you are familiar with the rule that you can appreciate when it is time to invoke an exception to it".