Comment by Aardwolf

Many people are correctly citing the usage of goto in the Linux kernel. One thing I would like to add is what Greg Kroah-Hartman says about goto in one of his talks: only jump forward, never backwards. This is precisely what you do when you goto cleanup.

I, personally, think the pattern is clean. A labelled break is basically a goto anyway, yet not always available in your language. I never liked needing a flag to exit some nested structure early. I don't find reading that clean at all.

Also, a minor rant here: Dijkstra's "Go To Statement Considered Harmful" is often mentioned, sometime wordlessly, when goto is brought up, but it seems many of those people misunderstood what was actually being argued. Although he mentions being "convinced that the go to statement should be abolished from all 'higher level' programming languages," his main gripe was that the "unbridled use of the go to statement has an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress." He felt it was "as it stands is just too primitive; it is too much an invitation to make a mess of one's program." So, as others have pointed out already, his main issue was with goto being used in a way that resulted in unstructured, hard to understand programs.

Goto for cleanup is not bad IMHO. I use it extensively...

$ cd redis; grep goto *.c | wc -l 251

All the instances are like:

    goto cleanup;
    goto error;
    goto badfmt;
    goto numargserr;

In this context is easy to read and makes the code structure better.

FWIW, gcc does have destructors for stack-allocated data as an extension: http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html#i...

    #include <stdio.h>
    
    typedef struct foo foo_t;
    
    void foo_cleanup(foo_t *f);
    
    struct foo { int i; };
    
    void foo_cleanup(foo_t *f) {
        printf("f %d\n", f->i);
    }
    
    int main() {
    
        foo_t a __attribute__((cleanup(foo_cleanup))) = { 7 };
    
        printf("l %d\n", __LINE__);
    
        {
            foo_t b __attribute__((cleanup(foo_cleanup))) = { 8 };
            
            printf("l %d\n", __LINE__);
        }
    
        printf("l %d\n", __LINE__);
    }


    l 18
    l 23
    f 8
    l 26
    f 7

Yea, I agree. I love C and was a C purist and flat-out refused to learn C++ well and use it in practice. This recently changed and now I quite enjoy C++. Destructors are one reason why. The whole idea of resource-managing classes and RAII is clever and really useful.

The hard part is that it takes a lot to be a good C++ programmer. C is such a smaller language, you can master a handful of best practices, gain experience, and become a competent C programmer. In contrast, C++ is such a large language you have to be active in learning everything — read Meyers, Modern C++, GoF's Design Patterns, etc. Anything short of this, and you're going to accidentally reinvent the wheel or do something stupid. But still, C++(11) is a terrific language that I'm learning to love.

> But goto is considered harmful,

Dijkstra never considered the kind of goto you describe as harmful. This is a distinction that's lost on most programmers now that the kind of languages that did have harmful gotos are dead and forgotten.

What he argued against was gotos that jump across procedure or scope boundaries.

The goto cleanup pattern is a good one. It's important to know why certain constructs are frowned upon. That pattern is not one of them.

Look at the Linux kernel; it's used extensively. For example: http://lxr.free-electrons.com/source/kernel/fork.c?v=3.3#L42...

"But goto is considered harmful"

GOTO _was_ considered harmful back in 1968(!) when structured programming was still in its infancy. Code of that time was usually peppered with GOTOs and therefore a pain to read.

Using GOTO for cleanup tasks is perfectly fine because it increases readability.

"goto cleanup" is fine, it's precisely how exceptions work anyway.

It's a commonly used pattern, most famously in the Linux kernel.

If you read much of the original discussion around the "Go To Statement Considered Harmful", this pattern is frequently pointed out as a reasonable use case absent proper exception handling.

Indeed, from the original editorial: "I remember having read the explicit recommendation to restrict the use of the go to statement to alarm exits, but I have not been able to trace it[.]"

It is the right way to handle exceptional conditions in modern C.

This is a question I've wondered myself. It's nice to see some different answers and reasoning here.

The solution I came up with myself is to have a destroy() function that is capable of cleaning up no matter what state the object is in.

Example: https://github.com/andrewrk/libgroove/blob/bc7d72589eb297342...

Notice all the calls to groove_playlist_destroy. And then in the destroy function it checks the conditions it has to before cleaning up.

I'm not saying it's necessarily the best answer but I think it's a pretty clean strategy.

Well here is one alternative: allocate temporary strings on a stack basis. Have some higher level functions reset the stack pointer. So now things are allocated temporarily by default, and only in the (hopefully) rare case where you need a long-lived item do you promote it to long lived. Promoting could mean copying the string to the heap, or it could just mean marking it so that the stack cleanup mechanism skips it (so perhaps you have a linked list of temporary items or something similar).

You still have to 'free' in destructors in C++. Destructors don't free your memory for your custom types for you.