[gameprogrammer] Re: More scripting engines
- From: Bob Pendleton <bob@xxxxxxxxxxxxx>
- To: Gameprogrammer Mailing List <gameprogrammer@xxxxxxxxxxxxx>
- Date: Thu, 29 Apr 2004 09:33:06 -0500
On Mon, 2004-04-26 at 01:41, grant hallman wrote:
> At 06:39 PM 24-04-04 +0200, you wrote:
> >On Saturday 24 April 2004 17.18, Bernhard Bliem wrote:
> >> That's an interesting idea. However, wouldn't a goto be actually
> >> sufficient?
> >
> >Sufficient, but not adequate. In fact, I'm probably not going to
> >support goto at all, considering the horrible mess it tends to create
> >when mixed with higher level flow control constructs. (Etc etc.)
> >
> >In short, goto is plain evil. :-)
>
> Personally, i suspect brainwashing ;)
>
> Goto can be part of hideous code, no doubt about it. But according to the
> NRA, goto's don't hurt programs, it's programmers who hurt programs ;-D
>
> IOW, if a programmer does not think and code clearly, nothing the language
> does can save the results, and if (s)he does, (s)he will write good code
> whether goto is available or not. A good clean goto with a
> sensibly-labelled target in plain view, is far easier to read, support etc.
> than the eleventy-deep-nested "break" which the compiler will turn into an
> asmb goto anyways. It's better, because it's explicit.
Implementing a goto into a block structured language is a real pain.
Gotos always cross block boundaries and interfere with variable scope.
So, a goto has to clean up the stack for the appropriate number of
levels and then do the jump. It is hard to handle properly in C. In
languages with scope exit rules for invoking destructors, like C++, goto
become a serious implementation problem.
Bob Pendleton
>
> >However, "break <n>", while rather nice and useful in cases, is pretty
> >evil as well. The biggest issue is that you can't clearly see where
> >you land, and it's easy to mix up ordinary {...} blocks with
> >breakable blocks and land totally off without even getting a compiler
> >warning.
>
> Hey, if u have a clear goto label, u see just where u land.
>
> >Of course, there's the alternative of not supporting multilevel break
> >( C/C++), or even not supporting break at all (!) - but then you end
> >up throwing in extra flag variables and stuff to get the job done in
> >real life code. (Or even using goto, if that's available... Ewww.)
> >
> >So, I figured if I reference outer scopes by name when breaking more
> >than the current level, the code gets more readable, you can't
> >accidentally land on the wrong level, and the risk of breaking stuff
> >when you modify the code is lower.
>
> A close runner-up, IMHO, and rather more tedious to implement.
>
> cheers - grant
>
>
>
--
+--------------------------------------+
+ Bob Pendleton: writer and programmer +
+ email: Bob@xxxxxxxxxxxxx +
+ blog: www.Stonewolf.net +
+ web: www.GameProgrammer.com +
+--------------------------------------+
Other related posts:
