goto

[Michael]

Hi,
I know I know its notoriously bad! I don't want to use it. I was wondering,
does it still exist? If it does, I really don't understand how!? like what
happens if you just goto halfway through a function (no objects properly
constructed!) , or a constructor itself??
Just intrigued!!

Mike

[Clark S. Cox III]

On 2005-03-28 06:58:54 -0500, Chris Croughton <ch***@keristor .net> said:

On Mon, 28 Mar 2005 04:24:31 +0300, Ioannis Vranos
<iv*@remove.thi s.grad.com> wrote:

I can understand the use of goto for the situations that I described.
For example, in application programming, in non-desperate for speed
conditions, why should one use goto?

For clarity when appropriate.

void func(...)
{
for (...)
{
for (...)
{
for (...)
{
/* do stuff */
if (something_wron g)
goto cleanup;
/* do more stuff */
if (something_wron g)
goto cleanup;
}
}
}
cleanup:
/* do cleanup stuff */
}

It's a lot clearer than using flags to do it, and return isn't
appropriate because the 'cleanup' code would need to be duplicated which
is a maintenabce risk.

What about this (no duplication, exception safe, no potential for goto
jumping across constructors/destructors, etc.):

void func(...)
{
struct cleanup {
~cleanup() { /* do cleanup stuff */ }
} cleaner;

for (...)
{
for (...)
{
for (...)
{
/* do stuff */
if (something_wron g)
return; /* or throw*/

/* do more stuff */
if (something_wron g)
return; /* or throw*/
}
}
}
}

--
Clark S. Cox, III
cl*******@gmail .com

[Phlip]

Clark S. Cox III wrote:

What about this (no duplication, exception safe, no potential for goto
jumping across constructors/destructors, etc.):

void func(...)
{
struct cleanup {
~cleanup() { /* do cleanup stuff */ }
} cleaner;

for (...)
{
for (...)
{
for (...)
{
/* do stuff */
if (something_wron g)
return; /* or throw*/

/* do more stuff */
if (something_wron g)
return; /* or throw*/
}
}
}
}

Try to pass local variables into ~cleanup(), to reliably clean them up. Your
little class rapidly gets very ugly - it grows a constructor, members, etc.

RAII works best when handles destruct themselves. Put another way,
destruction is an encapsulated detail of the handle, not of the function
using the handle.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Ioannis Vranos]

Ioannis Vranos wrote:

So if you want to establish a simple network connection for example and
it fails, it throws an exception. It doesn't return a null pointer. And
I think this is the right approach.

Actually, it does not throw an exception on connection failure but a positive integer is
returned in connection success, and 0 in network failure.

However for all unexpected errors an exception is thrown, like when trying to open a file
with write access while it is being used by another application, for example.
--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Ioannis Vranos wrote:

So if you want to establish a simple network connection for example
and it fails, it throws an exception. It doesn't return a null
pointer. And I think this is the right approach.

Actually, it does not throw an exception on connection failure but a
positive integer is returned in connection success, and 0 in network
failure.

Actually I think it is a mistake of the book I am reading, it *does* throw an exception.
http://msdn.microsoft.com/library/en...necttopic2.asp

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Dave Rahardja]

Phlip wrote:

Try to pass local variables into ~cleanup(), to reliably clean them up. Your
little class rapidly gets very ugly - it grows a constructor, members, etc.

RAII works best when handles destruct themselves. Put another way,
destruction is an encapsulated detail of the handle, not of the function
using the handle.

I prefer...

int cleanup_variabl e = 0; // Local vars needed for cleanup

class my_exception {};

try {
for (...)
{
for (...)
{
for (...)
{
// ...
if (something_wron g)
throw my_exception;

// ...
if (something_wron g)
throw my_exception;
}
}
}
} catch (my_exception&) {
// cleanup
// Optionally rethrow another exception
}

With a good compiler and optimizer, the run-time behavior of this code
should be equivalent to a goto to the outer block, with the additional
bonus that destructors for objects created in the for scope will be
properly called on the way out.

-dr

[Phlip]

Dave Rahardja wrote:

Phlip wrote:

Try to pass local variables into ~cleanup(), to reliably clean them up. Your little class rapidly gets very ugly - it grows a constructor, members, etc.
RAII works best when handles destruct themselves. Put another way,
destruction is an encapsulated detail of the handle, not of the function
using the handle.

I prefer...

int cleanup_variabl e = 0; // Local vars needed for cleanup

class my_exception {};

try {
for (...)
{
for (...)
{
for (...)
{
// ...
if (something_wron g)
throw my_exception;

// ...
if (something_wron g)
throw my_exception;
}
}
}
} catch (my_exception&) {

catch(...), so called functions can throw safely.
// cleanup
// Optionally rethrow another exception
}

With a good compiler and optimizer, the run-time behavior of this code
should be equivalent to a goto to the outer block, with the additional
bonus that destructors for objects created in the for scope will be
properly called on the way out.

However, RAII works best when handles destruct themselves. Put another way,
destruction is an encapsulated detail of the handle, not of the function
using the handle.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Ioannis Vranos]

Dave Rahardja wrote:

I prefer...

int cleanup_variabl e = 0; // Local vars needed for cleanup

class my_exception {};

try {
for (...)
{
for (...)
{
for (...)
{
// ...
if (something_wron g)
throw my_exception;

// ...
if (something_wron g)
throw my_exception;
}
}
}
} catch (my_exception&) {
// cleanup
// Optionally rethrow another exception
}

With a good compiler and optimizer, the run-time behavior of this code
should be equivalent to a goto to the outer block, with the additional
bonus that destructors for objects created in the for scope will be
properly called on the way out.

A style that I saw in a .NET book recently. I am just posting it here to see comments. :-)
for(...)
{
try
{
// Network connection attempt with object in the managed heap
}

catch(Exception *)
{
break;
}
}

I guess this makes sense for garbage collected objects in the heap.

--
Ioannis Vranos

http://www23.brinkster.com/noicys