From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,cf677878aa77e0d8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-07-19 04:38:27 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!193.174.75.178!news-fra1.dfn.de!news-koe1.dfn.de!news.rhrz.uni-bonn.de!not-for-mail From: Matthias Kretschmer Newsgroups: comp.lang.ada Subject: Re: an infinate loop Date: Thu, 19 Jul 2001 13:38:26 +0200 Organization: RHRZ - University of Bonn (Germany) Message-ID: <3B56C6B2.559EE5F3@bsdger.org> References: <3B4F2962.25BB60FF@boeing.com> <3B4F758B.197CA145@boeing.com> <9iv0ce$3d3$1@nh.pace.co.uk> <3B546F9D.4030809@gmx.net> <9j1u8a$863$1@nh.pace.co.uk> NNTP-Posting-Host: rubin.informatik.uni-bonn.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: f1node01.rhrz.uni-bonn.de 995542706 26886 131.220.5.45 (19 Jul 2001 11:38:26 GMT) X-Complaints-To: usenet@f1node01.rhrz.uni-bonn.de NNTP-Posting-Date: 19 Jul 2001 11:38:26 GMT X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en Xref: archiver1.google.com comp.lang.ada:10241 Date: 2001-07-19T11:38:26+00:00 List-Id: Ted Dennison wrote: > So while I can't agree that "goto" inarguably makes this particular algorithm > look better, it at least doesn't make it worse, and it performs it slightly > quicker. I'm not sure that would normally be enough to justify its inclusion in > the language. However, I'd observe that this issue comes up a lot more for > compiler writers than for the rest of us, and compiler writers did create this > language. :-) > Another way of implementing a state machine would be to make an array of subprogram access types to subprograms handling the different states. This could be faster than using case with using the current state as an index to the array. This should be nearly as fast as using goto, just it doesn't use fixed jump-points. But if you just implement features because of speed enhancements of special problems, than you should implement everything including an assembler. Goto doesn't make it look worse, but make it may be more complicated. Using for each state a seperate subprogram would be probably make the whole stuff more appealing to the eyes of other people. But in the other hand, just use aflex or something like that for processing strings and do not think about the implementation. As long as the aflex-programmers did their job well, one do not have to worrie how it is implemented and how to change the specific implementation, just using it is enough. But this leads to another way of implementing a state machine. Using an approach similar to aflex and the like. Implementing the statemachine with rules that apply to different states and having just one subprogram processing the rules stored for example in an array of records or something like that. The array can be filled at run-time by processing a file (which could lead to the problem of using a state machine for this parser :-)) or by a constant array hardcoded in the program. mfg Matthias