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

[Phlip]

E. Mark Ping wrote:

In 10+ years of C/C++ coding I've never seen goto used except to exit
from an inner loop, which is where it's commonly recommended.

'goto' has been frowned upon for well over 10 years. However, if you have
never encountered any related design smell, consider yourself amazingly
lucky.

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

[E. Mark Ping]

In article <AA************ ****@newssvr17. news.prodigy.co m>,
Phlip <ph*******@yaho o.com> wrote:

E. Mark Ping wrote:

In 10+ years of C/C++ coding I've never seen goto used except to exit
from an inner loop, which is where it's commonly recommended.

'goto' has been frowned upon for well over 10 years. However, if you have
never encountered any related design smell, consider yourself amazingly
lucky.

Yes, Dijkstra's "Go To Statement Considered Harmful" was written
before C was created, yet people still unthinkingly carried the "goto
is bad" mantra beyond it's intent. The restrictions C places on goto
and the common advice (only use for escaping inner loops) pretty much
invalidates the dogma.
--
Mark Ping
em****@soda.CSU A.Berkeley.EDU

[Andrew McDonagh]

Phlip wrote:

E. Mark Ping wrote:

In 10+ years of C/C++ coding I've never seen goto used except to exit
from an inner loop, which is where it's commonly recommended.

'goto' has been frowned upon for well over 10 years. However, if you have
never encountered any related design smell, consider yourself amazingly
lucky.

seconded!

[Chris Croughton]

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

Chris Croughton wrote:

I don't use it either, but I do return from funtions in the middle, or
particularly near the start if conditions aren't met, which many people
regard as just as bad:

int func(int param)
{
if (param < 0)
return FAIL_VAL_1;
/* do stuff setting up conditions */
if (error_setting_ conditions)
return FAIL_VAL_2;
/* do the actual stuff */
return SUCCESS_VAL;
}

I know some say that this is bad, I but do not agree with them. This
is an unneeded constraint, just to make our lives more difficult (or
in other words, they think that by imposing such restrictive rules
will be able to protect bad programmers from bad programming).

But the same is true about blanket forbidding of goto. Unclear
programming is always bad, no language structure is inherrently bad
(well, OK, Intercal!) it's how you use it.

However, I've seen goto used with good and clear effect as well.

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.

I can understand its use on machine-produced C++ code and in a very
desperate need for performance, when all other alternatives are
exhausted.

That's not the only time it's useful.

May you say in what other conditions it is useful?

Duh, breaking out of nested loops (see above). Which is where we came
in...

Chris C

[Ioannis Vranos]

Chris Croughton 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.

This is better done with exceptions.

Duh, breaking out of nested loops (see above). Which is where we came
in...

In the above you use it to perform error handling.
--
Ioannis Vranos

http://www23.brinkster.com/noicys

[I am using 90 characters word-wrapping - (800/640) *72= 90 or better described as:
(800/640) *80 - 10 for quotation= 90. If someone finds it inconvenient, please let me know].

[Andrew McDonagh]

Chris Croughton wrote:

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

Chris Croughton wrote:

I don't use it either, but I do return from funtions in the middle, or
particular ly near the start if conditions aren't met, which many people
regard as just as bad:

int func(int param)
{
if (param < 0)
return FAIL_VAL_1;
/* do stuff setting up conditions */
if (error_setting_ conditions)
return FAIL_VAL_2;
/* do the actual stuff */
return SUCCESS_VAL;
}
I know some say that this is bad, I but do not agree with them. This
is an unneeded constraint, just to make our lives more difficult (or
in other words, they think that by imposing such restrictive rules
will be able to protect bad programmers from bad programming).

But the same is true about blanket forbidding of goto.

I think one problem a lot of people have with it, is seeing it being
used/abused so often. Yes this should not mean we forbid it, but its use
should be very limited.

I had the great 'pleasure' to have to add a new feature to an existing
product, in which the original developer could not see an easy way out
of a 2 tier nested for loop with several If conditions inside. So they
used goto BAD_BOY:

He knew it was rubbish code, but time pressure meant he wanted something
out quickly. This code was supposed to remain in existence for a few
days until he could make it better. He even left a comment saying as much.

It lived for almost 2 years before finally being refactored away in
order to add functionality.
Unclear programming is always bad, no language structure is inherrently bad (well, OK, Intercal!) it's how you use it.

However, I've seen goto used with good and clear effect as well.

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.

The problem I have with this type of code structure though, is that
whilst I can see on the screen the 3 nested for loops, the two If
conditions, the Do stuff AND finally the cleanup stuff, I would either
have to use a very small font, a very large monitor or scroll about to
see it all.

What I'm getting at, is that whilst it may appear to be 'clear' the
sheer amount of code means we can't easily see what is happening.

I'd also bet that there is significant duplication within the class(es)
.. If we have to do 3 nested for loops here, you can 'usually' bet
another place in the code base is doing the same nested loops.

Where as, if we separated 'query', 'retrieval' and 'do stuff to',
applied the appropriate design patterns (visitor, command what ever..)
then we usually end up with much smaller methods, no or little
duplication and just as easy and clear code.

[Andrew McDonagh]

Ioannis Vranos wrote:

Chris Croughton 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.

This is better done with exceptions.

If the 'something wrong' is an exceptional case, then I'd agree
exceptions are appropriate. However, if the something wrong is not an
exceptional case, then using exceptions is really just another
interpretation/implementation of goto.

for example, it may be appropriate to throw an exception if one of the
function params is out of bounds.

if (param > arraySize) {
throw new IndexOutOfBound sException();
}

where as, it might not be appropriate to throw an exception just because
something does not exist.

if (something == null) {
throw new NotFoundExcepti on();
}

[Ioannis Vranos]

Andrew McDonagh wrote:

for example, it may be appropriate to throw an exception if one of the
function params is out of bounds.

if (param > arraySize) {
throw new IndexOutOfBound sException();
}

Yes.

where as, it might not be appropriate to throw an exception just because
something does not exist.

if (something == null) {
throw new NotFoundExcepti on();
}

Yes. It will not be appropriate if for example the null is signifying the expected end of
a sequence. But then, "something wrong" is not an accurate term to describe that.
That pseudocode was displaying error handling, with the use of goto to jump to the error
handling code, clearly substituting the exception handling mechanism.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[I am using 90 characters word-wrapping - (800/640) *72= 90 or better described as:
(800/640) *80 - 10 for quotation= 90. If someone finds it inconvenient, please let me know].

[Andrew Koenig]

"Andrew McDonagh" <ne**@andrewcdo nagh.f2s.com> wrote in message
news:d2******** **@news.freedom 2surf.net...

If the 'something wrong' is an exceptional case, then I'd agree exceptions
are appropriate. However, if the something wrong is not an exceptional
case, then using exceptions is really just another
interpretation/implementation of goto.

Not really.

There are (at least) three fundamental differences between exceptions and
goto:

1) The author of a throw statement does not need to know where the
exception will be caught.

2) It is possible to transfer information between the throw and the
corresponding catch.

3) It is possible to reach a catch only from code executed as part of
the corresponding try. It is possible to reach a label from anywhere in the
entire function (subject only to the restriction that you cannot jump from a
place where a variable is out of scope to a place where it is in scope).

[Ioannis Vranos]

Andrew McDonagh wrote:

where as, it might not be appropriate to throw an exception just because
something does not exist.

if (something == null) {
throw new NotFoundExcepti on();
}

About the not-exists stuff, as a return value, let me give you an example. .NET is *very*
high-level, OO and modern (meaning it uses all modern facilities). It uses exceptions
completely for error-handling, for every single error it throws an exception.

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.

Since we have exceptions, we do not need any error signalling through value return.
--
Ioannis Vranos

http://www23.brinkster.com/noicys

[I am using 90 characters word-wrapping - (800/640) *72= 90 or better described as:
(800/640) *80 - 10 for quotation= 90. If someone finds it inconvenient, please let me know].