Jump to content

  • Log In with Google      Sign In   
  • Create Account


C++ - Is Goto a Good Practice?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
46 replies to this topic

#41 powly k   Members   -  Reputation: 648

Like
-6Likes
Like

Posted 15 November 2012 - 09:22 AM

A small remark - the guys who dislike goto are on the forums whining about it while the guys who like goto are actually coding something.

Which do you want to be?

(EDIT: Another small remark - guys around here seem to have no clue about the concept of humour!)

Edited by powly k, 18 November 2012 - 03:40 AM.


Sponsor:

#42 rip-off   Moderators   -  Reputation: 8112

Like
0Likes
Like

Posted 15 November 2012 - 10:16 AM

... the guys who dislike goto are on the forums whining about it while the guys who like goto are actually coding something.

Wow. That is an impressively simplistic false dichotomy.

#43 powly k   Members   -  Reputation: 648

Like
0Likes
Like

Posted 15 November 2012 - 06:07 PM

... or a bad joke :) And though I (seriously) don't think goto is bad by default, I've never had a reason to use it.

#44 Bacterius   Crossbones+   -  Reputation: 8504

Like
1Likes
Like

Posted 15 November 2012 - 06:15 PM

I think one of the only times I ever used goto was to get out of a three-level nested loop. It wasn't final code and I couldn't be bothered to add break flags or put the loops in their own function, so I just used goto as an extended break. But I wouldn't recommend it - it's not really compatible with higher level control flow, but it's nice to know it exists.

I'm sure there are instances out there where goto may in fact be beneficial (someone mentioned cleaning up C functions, which is a good one, of course you can achieve the same goal by carefully nesting your allocations but sometimes goto is the only elegant way to do it), but you certainly don't use goto "just because you can".

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#45 Blewweh   Members   -  Reputation: 107

Like
0Likes
Like

Posted 16 November 2012 - 07:55 AM

Say no to goto!~~

heehee.

#46 Codarki   Members   -  Reputation: 462

Like
0Likes
Like

Posted 16 November 2012 - 01:51 PM

I don't actually know what happens in the following scenarios. Does goto respect rules of the scoped objects?
{
	std::string tee("hee");
	goto forward;
}
forward:
// what happens with destruction of tee? Memory leak I guess.
backward:
// what happens with destruction of tee? Memory leak I guess.
int i = 0;
if (i == 0)
{
	i = 1;
	std::string tee("hee");
	goto backward;
}
if (rand()%2 == 0)
	goto forward2;

{
	std::string tee("hee");
forward2:
	// tee isn't constructed here with goto. Crash if referenced I guess.
	// tee must be destructed at scope exit if entered without goto.
}

Does goto break all RAII objects?

Edited by Codarki, 16 November 2012 - 01:54 PM.


#47 SiCrane   Moderators   -  Reputation: 9541

Like
0Likes
Like

Posted 16 November 2012 - 04:38 PM

A goto out of a block destroys all objects that have been initialized in that block. A goto into a block after a statement creating an object with an initializer is ill-formed (i.e. the compiler should bitch at you for trying it). So in your specific scenario, the first goto to forward should properly destroy tee. The goto to backward will destroy the second tee because control flow still leaves that block. The goto to forward2 should trigger a compiler error.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS