goto

In a function that has multiple exit points, and also has multiple dynamically allocated variables, I could repeat all the necessary delete statements before every return statement (if I remember), or I could put an Exit: label followed by all of the deletes at the end of the function and simply ( ) goto Exit at the various exit points. I'm thinking that the latter seems more efficient, more readable, and easier to maintain, and that therefore this is one of those "rare" situations in which goto is appropriate. Any comments?

I tend to agree, but in C++ there is a possibly better solution: make use of RAII, e.g., use smart pointers such that all the deletes are performed automatically.

There have been several times that I have coded a GOTO statement, and every time, it eventually got in the way of an otherwise well structured module or a refactoring process.

Depending on the environment for which your code will run, you can let the operating system free the storage, or you have to do it yourself. If the latter, you could keep an internal list of memory chunks that are allocated, and instead of coding an exit everywhere with a host of DELETE statements, you could call a cleanup routine that would in turn be a single point for freeing any storage and then exit from there.

Originally Posted by Laserlight

I tend to agree, but in C++ there is a possibly better solution: make use of RAII, e.g., use smart pointers such that all the deletes are performed automatically.

I'm not familiar with RAII. I'll have to look into that.

Originally Posted by Dino

... you could keep an internal list of memory chunks that are allocated, and instead of coding an exit everywhere with a host of DELETE statements, you could call a cleanup routine that would in turn be a single point for freeing any storage and then exit from there.

I thought of writing an "exit" function, but then I'd have to pass it pointers to each variable to be deleted -- not very appealing. But unless I misunderstood, you seem to be suggesting yet another function to handle all the dynamic allocation, along with some sort of global structure containing or pointing to the dynamically allocated memory? Is that what you are suggesting?

Originally Posted by R.Stiltskin

I'm not familiar with RAII. I'll have to look into that.

You could start by reading Stroustrup's answer to the FAQ How do I deal with memory leaks?.

Originally Posted by R.Stiltskin

... But unless I misunderstood, you seem to be suggesting yet another function to handle all the dynamic allocation, along with some sort of global structure containing or pointing to the dynamically allocated memory? Is that what you are suggesting?

Yes.

(EDIT: But use of auto_ptr seems to be a simpler solution)

Thanks, laserlight and Dino. auto_ptr is clearly something I should add to my repertoire. Oh, and I haven't come across that Stroustrup FAQ before either -- very handy.

Happy New Year!

You can always use a destructor. If you have

Code:

foo a = new foo;
boo b = new boo;

you can do something like

Code:

class ab
{
foo* a;
boo* b;
class()
{
a = new foo;
b = new boo;
}
~class()
{
   delete a;
   delete b;
}
};
//use like
ab myVar;

Just a general example. Depends on exactly what you want. The idea is to wrap around new/delete a class that will be statically allocated so you can use the destructor mechanism.
You also try something like

Code:

template<class T>
class ptr
{
   T* p;
    ptr(){p = new T;}
   ~ptr() {delete T;}
};
//use like
ptr<foo> f;
f.p->value = 1;

You get the general idea.

I would prefer a keyword like "breakAll" to break from nested loops.

Originally Posted by C_ntua

You can always use a destructor. If you have

Code:

foo a = new foo;
boo b = new boo;

you can do something like

Code:

class ab
{
foo* a;
boo* b;
class()
{
a = new foo;
b = new boo;
}
~class()
{
   delete a;
   delete b;
}
};
//use like
ab myVar;

Just a general example. Depends on exactly what you want. The idea is to wrap around new/delete a class that will be statically allocated so you can use the destructor mechanism.
You also try something like

Code:

template<class T>
class ptr
{
   T* p;
    ptr(){p = new T;}
   ~ptr() {delete T;}
};
//use like
ptr<foo> f;
f.p->value = 1;

You get the general idea.

I would prefer a keyword like "breakAll" to break from nested loops.

It is a much better idea to use existing smart pointer implementations that attempting to create your own as you have done. Your "simple" example is incomplete and has several bugs.

...and before you get too cozy with std::auto_ptr keep in mind it is not a 'shared' pointer in the truest sense. It also has some very weird copy semantics. I highly recommend using boost's various assortment of pointer types.

And to answer your first question it seems to me that the function in question is probably too complex and needs to be broken out into several functions.

One serious problem with any use of goto in C++ is this:

Code:

class X;

void foo()
{
    goto label;

    X obj;
label:
    // obj may, or may not be constructed at this point, depending whether we got here via goto or not
}

In other words, it can produce a situation where names are in scope but the objects they refer to are uninitialized. VERY BAD. The compiler should warn, but if it doesn't, your code will silently be wrong and it will be maddening to figure out what the problem is.

"Failure ladders" are useful in C, but in C++ resources should be managed with containers, such as smart pointers.

Originally Posted by Bubba

...and before you get too cozy with std::auto_ptr keep in mind it is not a 'shared' pointer in the truest sense. It also has some very weird copy semantics. I highly recommend using boost's various assortment of pointer types.

Seconded. The std::auto_ptr is too limited for most applications - definitely check out the Boost suite of smart-pointers.

Also, another good replacement for the std::auto_ptr that is still quite light-weight is this one, which was designed by yours truly.

Whatever you do, though, be sure to always use smart-pointers, and generally speaking, RAII techniques. There's absolutely no excuse for managing raw pointers "by hand"...EVER!!!

Originally Posted by laserlight

I tend to agree, but in C++ there is a possibly better solution: make use of RAII, e.g., use smart pointers such that all the deletes are performed automatically.

That doesn't always work, for example, if there exist execution paths where the object is not deleted. If the object is always deleted then simply putting the deletes before the return would have worked.

Originally Posted by abachler

That doesn't always work, for example, if there exist execution paths where the object is not deleted. If the object is always deleted then simply putting the deletes before the return would have worked.

If the object isn't deleted, then it must be returned from the function or stored somewhere (otherwise it would be a memory leak). In that case the smart pointer will manage its lifetime correctly.

In other words, it can produce a situation where names are in scope but the objects they refer to are uninitialized. VERY BAD. The compiler should warn, but if it doesn't, your code will silently be wrong and it will be maddening to figure out what the problem is.

I thought GCC won't even allow that. I don't think it allows goto's to fly over initializations (or even declarations?)