Of course goto isn't evil. It is however in most situations not the best solution to use goto, hence by not providing goto the overall quality of the code will be higher. I agree that Pers solution to your problem was not a good one, but you forced him to that since your problem was faulty. By using undisclosed code blocks with arbitrary constrains you can prove almost anything, since the "real solution" might be to alter these code blocks. I would have suggested
void init() { [some-setup-code] }; init(); while(1) { [some processing code] if (condition) { init(); continue; } [some processing code] } [some more code]
but it is impossible to give a good answer unless one knows what you want to achieve with the code.
/ Martin Nilsson (lambda)
Previous text:
2003-05-13 20:51: Subject: goto
On Tue, May 13, 2003 at 08:35:02PM +0200, Martin Nilsson (lambda) @ Pike (-) developers forum wrote:
Of course it lessens readability when you try to emulate goto in a language that has no goto concept. The "correct" solution is to design the code differently.
The "correct" code is the code that works as expected and easy to understand.
This way, if use of "goto" improves readability and undestanding - it should be done instead of designing code to avoid something. Why to create obstacles and then avoid then, instead of going directly to the goal? :)
NB: I would like to know, if possible, the reason why "goto" is not included in Pike (except well-known "the "goto" is evil" - this is not the reason, this is like "the appless are evil because I don't like them").
Regards, /Al
/ Brevbäraren