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

 

[Andre Kostur]

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!!

Yes goto still exists.

The type of goto you describe is ill-formed. See section 6.7(3) of the
Holy Standard

 

[Alf P. Steinbach]

* Michael:

I know I know its notoriously bad! I don't want to use it. I was wondering,
does it still exist?
Yes.


If it does, I really don't understand how!?

Like always.

like what
happens if you just goto halfway through a function (no objects properly
constructed!) ,

That is forbidden by §6.6.4/3; it won't or shouldn't compile.

or a constructor itself??
?


Just intrigued!!

As you learn more you'll find many more unsafe constructs, in all languages.

 

[Phlip]

I know I know its notoriously bad!

Long functions are bad. Short ones have no reason to use 'goto', and thus
'goto' is relatively harmless.

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??

Ordinarily, one should not learn C++ laws via "but my compiler likes it".

In this case, a little VC++ experiment is useful:

goto bar;
string foo;
bar:;

error C2362: initialization of 'foo' is skipped by 'goto bar'

The language designers took care of it. With no legacy C constructors to
support, they ordained compilers reject (relatively) non-structured 'goto'
abuses.

 

[Michael]

* Michael:

Like always.



That is forbidden by §6.6.4/3; it won't or shouldn't compile.

so what are the limits on what you can 'goto' 'to' ?
local scope?

 

[Alf P. Steinbach]

* Michael:

* Alf P. Steinbach:
so what are the limits on what you can 'goto' 'to' ?
local scope?

Quoting the standard: "It is possible to transfer into a block, but not in a
way that bypasses declarations with initialization."

Btw., don't quote things you don't reply to or irrelevant to your reply;
snipped further quoting.

Download and install <url: http://home.in.tum.de/~jain/software/oe-quotefix/>.

 

[Ioannis Vranos]

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!?

Yes it exists. Assume by "how" you mean "why". goto is extensively used
in machine-produced efficient C++ code.

 

[Phlip]

Yes it exists. Assume by "how" you mean "why". goto is extensively used
in machine-produced efficient C++ code.

Please note Ioannis did not say "goto is efficient". It might be more
efficient than a well-structured function call; it might not.

Under the theory that a function takes time pushing variables onto a stack,
'goto' might generate a single branch opcode. However, that 'goto' might
live in a function that's now long enough to overflow the CPU cache. Several
small functions might have fit in the cache, making their specific function
calls faster.

 

[Maciej Pilichowski]

I know I know its notoriously bad! I don't want to use it.

Why not? Goto is very useful since there is not labelled break. When
you have nested for in another for /for example/ the easiest way /and
elegant too/ to break from the external one is to use goto.

have a nice day
bye

 

[Phlip]

Why not? Goto is very useful since there is not labelled break. When
you have nested for in another for /for example/ the easiest way /and
elegant too/ to break from the external one is to use goto.

or return.

Why is your function so long?

 

[Maciej Pilichowski]

or return.

AFAIK return breaks the entire function ;-).

Why is your function so long?

I don't think that function 10-lines long is "so long". And I am
talking about pretty obvious

for (int x=0;x<width;++x)
for (int y=0;y<height;++y)
if (something())
break_the_x_loop;

and there is nice goto construction.

I just pointed the use of goto, if you are not convinced -- ok, it is
not Java, write your programs as you like.

have a nice day
bye

PS. On the other hand, such situations are rather rare -- in project
~40,000 lines long I had to use goto once

 

[Ioannis Vranos]

I don't think that function 10-lines long is "so long". And I am
talking about pretty obvious

for (int x=0;x<width;++x) {
for (int y=0;y<height;++y)

if (something())
break;

if(something())
break;
}

and there is nice goto construction.

Which can be avoided.



--
Ioannis Vranos

http://www23.brinkster.com/noicys

[I have set the word-wrapping at 90 characters. I am interested in hearing if it causes
inconvenience to anyone].

 

[Chris Croughton]

if (something())
break;

if(something())
break;
}

You called something() twice, what if it has side-effects (like I/O)?

Yes, you can get round that with a boolean flag:

bool running = true;
for (int x = 0; running && x < width; ++x)
for (int y = 0; y < height; ++y)
if (something())
running = false;

but that is less obvious and in the case of more complicated loops can
obscure the actual flow.

Which can be avoided.

Of course it can, so can most things. There are however occasions when
goto (and return in the middle of a function, which many ivory tower
computer scientists regard as nearly as bad) are the cleanest and most
maintainable constructions.

Just like the misquotation "Money is the root of all evil", saying that
all uses of goto are evil misses the point. Certainly /some/ uses of
goto are dangerousm just like /some/ uses of money, but the thing itself
is a tool nothing more.

As the C++ FAQ Lite says:

[6.14] What does the FAQ mean by "such and such is evil"?

It means such and such is something you should avoid most of the
time, but not something you should avoid all the time. For example,
you will end up using these "evil" things whenever they are "the
least evil of the evil alternatives." It's a joke, okay? Don't take
it too seriously.

...

Another thing: things labeled as "evil" (macros, arrays, pointers,
etc.) aren't always bad in all situations. When they are the "least
bad" of the alternatives, use them!

And as we know from the FDA, anything in excess can be "considered
harmful". Sugar, water, oxygen; goto, pointers, macros... People who
try to write everything as OO whether the problem domain matches it or
not. People who think "self-documenting code" means that all
identifiers have to be complete sentences. People insisting on "one
true way" in any field...

Fanaticism is the true evil. Death to all fanatics! The must be
moderation in all things (especially in moderation).

Chris C

 

[Ioannis Vranos]

You called something() twice, what if it has side-effects (like I/O)?

Yes, you can get round that with a boolean flag:

bool running = true;
for (int x = 0; running && x < width; ++x)
for (int y = 0; y < height; ++y)
if (something())
running = false;

but that is less obvious and in the case of more complicated loops can
obscure the actual flow.

or in this case:


return_type res;

for(int x=0; x<width; ++x)
{
for(int y=0; y<height; ++y)
{
res= something();

if(return_type)
break;
}


if(return_type)
break;
}

Of course it can, so can most things. There are however occasions when
goto (and return in the middle of a function, which many ivory tower
computer scientists regard as nearly as bad) are the cleanest and most
maintainable constructions.

Just like the misquotation "Money is the root of all evil", saying that
all uses of goto are evil misses the point. Certainly /some/ uses of
goto are dangerousm just like /some/ uses of money, but the thing itself
is a tool nothing more.

As the C++ FAQ Lite says:

[6.14] What does the FAQ mean by "such and such is evil"?

It means such and such is something you should avoid most of the
time, but not something you should avoid all the time. For example,
you will end up using these "evil" things whenever they are "the
least evil of the evil alternatives." It's a joke, okay? Don't take
it too seriously.

...

Another thing: things labeled as "evil" (macros, arrays, pointers,
etc.) aren't always bad in all situations. When they are the "least
bad" of the alternatives, use them!

However I haven't used goto since some time back in school, when I was checking
GWBASIC/QBasic then. So, this means it is not much needed, for regular application
programming at least.

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



--
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].

 

[Chris Croughton]

An extra break; is needed, or a test in te inner loop for running, I
chopped it down too far:

bool running = true;
for (int x = 0; running && x < width; ++x)
for (int y = 0; running && y < height; ++y)
if (something())
running = false;

or in this case:

return_type res;

for(int x=0; x<width; ++x)
{
for(int y=0; y<height; ++y)
{
res= something();

if(return_type)


However I haven't used goto since some time back in school, when I was checking
GWBASIC/QBasic then. So, this means it is not much needed, for regular application
programming at least.

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;
}

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

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.

Chris C

 

[E. Mark Ping]

Which can be avoided.

But is sometimes the best tool for the job. Ignoring your best tool
because of dogma is idiotic.

 

[Andrew McDonagh]

But is sometimes the best tool for the job. Ignoring your best tool
because of dogma is idiotic.

most of the time though, its an indicator that the design smells.

In the case of the example code within this thread, the nested for loops
are searching for something within an X & Y co-ordinate within a certain
width & height dimension.

When the target was originally placed at the co-ordinate, we could have
had the Dimension object keep a mapping co-ordinate -> target or target
-> co-ordinate, etc...

Then we could have queried and retrieved the target from the Dimension


Also, Goto's make refactoring very difficult.

 

[Andrew McDonagh]

snipped


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;
}

There is nothing wrong with a function of that length having multiple
returns. Its very clear.

The problem with multiple returns within a single function is when the
functions are long. The longer a function to harder it is to see the
return points. By long I mean more than a hand full of lines, my
personal line per function limit is around 7. Comes from the human
minds ability to deal with groupings of 7 or less easily. (Its one
reason why your credit card numbers are bunched into groups of 4 digits,
and why telephone numbers typically have an area code and actual number
as two groupings).

Guard clauses as your example above are a great technique for aiding the
reader.

The worst Guard clauses are when the logic is inverted resulting in the
entire function body being indented excessively.

e.g. your code with badly implemented clauses.

int func(int param)
{
if (param > 0)
{
/* do stuff setting up conditions */
if (! error_setting_conditions )
{
/* do the actual stuff */
return SUCCESS_VAL;

} else
return FAIL_VAL_2;

} else
return FAIL_VAL_1;
}


I see this type of code all to often unfortunately.

 

[Ioannis Vranos]

You meant res, I assume <g>. And assuming that return_type evaluates to
non-zero if the exit is needed.

Yes.




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).

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?

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

May you say in what other conditions it is useful?



--
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].

 

[E. Mark Ping]

most of the time though, its an indicator that the design smells.

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.