Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #64979 > unrolled thread
| Started by | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| First post | 2015-07-09 12:49 +0200 |
| Last post | 2015-07-16 09:41 +1200 |
| Articles | 20 on this page of 292 — 25 participants |
Back to article view | Back to comp.lang.c
Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 12:49 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 12:03 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 14:15 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 13:49 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 15:15 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 14:25 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 15:36 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 14:51 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 16:02 +0200
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-09 20:48 +0100
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-09 09:54 -0400
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 15:08 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 16:16 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 15:18 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 16:24 +0200
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-09 20:31 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 21:42 +0200
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-10 00:57 +0100
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-09 20:39 +0100
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 21:44 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-09 22:50 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-09 13:49 +0100
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 13:52 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 15:26 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 14:28 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-09 05:28 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 15:09 +0200
Re: Recursion or loop, design questions "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-07-09 09:25 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 18:41 +0200
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-10 11:52 -0400
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-10 18:44 +0200
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-10 18:52 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-10 20:34 +0200
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-10 11:50 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-10 20:56 +0200
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-10 13:30 -0700
Re: Recursion or loop, design questions Philip Lantz <prl@canterey.us> - 2015-07-11 10:51 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-11 16:07 -0700
Re: Recursion or loop, design questions Philip Lantz <prl@canterey.us> - 2015-07-12 00:20 -0700
Re: Recursion or loop, design questions gordonb.j93iw@burditt.org (Gordon Burditt) - 2015-07-11 21:26 -0500
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-09 10:08 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 19:19 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 19:11 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 21:28 +0200
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-09 13:41 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 15:22 +0200
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 18:45 +0200
Re: Recursion or loop, design questions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-09 18:05 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 07:06 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-11 15:51 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 09:36 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-15 10:49 -0700
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-15 13:05 -0500
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 10:28 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-20 12:41 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-20 21:37 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-24 13:05 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-24 15:07 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 12:42 -0700
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-24 15:38 -0500
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 12:39 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-30 22:35 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-02 07:09 -0700
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-08-02 14:43 -0500
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-03 09:48 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-09 21:23 +0200
Re: Recursion or loop, design questions Andrew Cooper <amc96@cam.ac.uk> - 2015-07-10 00:52 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-10 01:28 +0100
Re: Recursion or loop, design questions Phil Carmody <pc+usenet@asdf.org> - 2015-07-12 13:20 +0300
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-12 11:39 +0100
Re: Recursion or loop, design questions David Kleinecke <dkleinecke@gmail.com> - 2015-07-12 10:28 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-13 08:17 +1200
Re: Recursion or loop, design questions David Brown <david.brown@hesbynett.no> - 2015-07-21 14:46 +0200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 19:27 -0700
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-07-13 21:16 +0000
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-10 08:34 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-10 00:46 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-10 12:35 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-10 12:47 +0100
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-10 14:29 +0200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 06:36 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 07:16 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 14:23 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-15 15:27 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 19:27 -0700
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-11 15:27 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 08:00 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-11 15:46 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-11 16:01 -0700
Re: Recursion or loop, design questions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-12 00:36 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 13:55 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-15 14:12 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 19:45 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 14:34 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-15 15:37 -0700
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-16 10:07 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-16 10:18 +0100
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-16 13:35 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-16 21:10 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-17 13:55 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-17 11:16 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-17 11:25 -0700
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-17 20:51 +0100
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-17 13:48 -0700
Re: Recursion or loop, design questions David Brown <david.brown@hesbynett.no> - 2015-07-21 15:12 +0200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-21 10:56 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-21 19:43 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-21 12:52 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-21 21:17 +0100
Re: Recursion or loop, design questions David Brown <david.brown@hesbynett.no> - 2015-07-21 23:58 +0200
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-22 20:39 +0100
Re: Recursion or loop, design questions Richard Damon <Richard@Damon-Family.org> - 2015-07-24 00:54 -0400
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-24 09:06 +0100
Re: Recursion or loop, design questions Richard Damon <Richard@Damon-Family.org> - 2015-07-24 08:04 -0400
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-24 13:48 +0100
Re: Recursion or loop, design questions Richard Damon <Richard@Damon-Family.org> - 2015-07-25 14:02 -0400
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 13:41 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-02 15:41 +0200
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-02 21:51 +0000
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-03 01:20 +0200
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-04 10:54 +0000
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-04 06:02 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-08-04 14:03 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 11:36 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 11:21 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 12:18 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 13:19 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 13:35 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-08-04 21:40 +0100
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 13:51 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-04 22:57 +0200
Re: Recursion or loop, design questions David Brown <david.brown@hesbynett.no> - 2015-08-05 08:45 +0200
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 14:19 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-04 23:22 +0200
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-04 14:28 -0700
Language (was: Re: Recursion or loop, design questions) "Morten W. Petersen" <morphex@gmail.com> - 2015-08-04 23:35 +0200
Re: Language (was: Re: Recursion or loop, design questions) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-04 14:45 -0700
Re: Language "Morten W. Petersen" <morphex@gmail.com> - 2015-08-04 23:55 +0200
Re: Language (was: Re: Recursion or loop, design questions) fir <profesor.fir@gmail.com> - 2015-08-04 16:44 -0700
Re: Language (was: Re: Recursion or loop, design questions) fir <profesor.fir@gmail.com> - 2015-08-04 17:18 -0700
Re: Language (was: Re: Recursion or loop, design questions) fir <profesor.fir@gmail.com> - 2015-08-05 01:32 -0700
Re: Language Richard Heathfield <rjh@cpax.org.uk> - 2015-08-05 09:51 +0100
Re: Language Richard Heathfield <rjh@cpax.org.uk> - 2015-08-05 12:55 +0100
Re: Language Gareth Owen <gwowen@gmail.com> - 2015-08-05 19:12 +0100
Re: Language Richard Heathfield <rjh@cpax.org.uk> - 2015-08-06 17:09 +0100
Re: Language luser droog <luser.droog@gmail.com> - 2015-08-06 15:10 -0700
Re: Language Richard Heathfield <rjh@cpax.org.uk> - 2015-08-07 09:48 +0100
Re: Language luser droog <luser.droog@gmail.com> - 2015-08-07 13:37 -0700
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-06 10:54 +0000
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-06 13:32 +0200
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-08-06 11:06 -0400
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-06 11:52 -0700
Re: Recursion or loop, design questions David Brown <david.brown@hesbynett.no> - 2015-08-06 21:19 +0200
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-08-06 17:59 -0400
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-06 15:54 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-06 12:56 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-07 23:45 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-08 09:27 +0200
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-08 01:09 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-08 01:34 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-08-08 13:00 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-08 14:22 -0700
Re: Recursion or loop, design questions David Kleinecke <dkleinecke@gmail.com> - 2015-08-08 16:12 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-08-08 17:31 -0700
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-09 13:34 +0000
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-09 08:38 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-09 09:31 +0200
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-09 01:52 -0700
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-06 04:40 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 20:19 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 23:59 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 15:53 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 19:43 -0700
Re: Recursion or loop, design questions David Kleinecke <dkleinecke@gmail.com> - 2015-07-25 20:05 -0700
Re: Recursion or loop, design questions Richard Heathfield <rjh@cpax.org.uk> - 2015-07-27 23:53 +0100
Re: Recursion or loop, design questions fir <profesor.fir@gmail.com> - 2015-08-03 01:51 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-03 10:04 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-17 21:34 +0100
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-17 13:52 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-17 21:57 +0100
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 10:44 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-18 11:00 +0100
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-18 05:25 -0500
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 14:26 +0100
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-18 17:38 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-18 10:05 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 21:31 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-18 14:28 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-18 15:01 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-18 15:39 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-18 15:44 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-18 15:55 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-19 10:58 +1200
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-18 16:26 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-18 17:23 -0700
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-18 18:04 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 00:03 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-19 13:30 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 08:45 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-19 20:59 +0200
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-19 21:19 +0200
Re: Recursion or loop, design questions Les Cargill <lcargill99@comcast.com> - 2015-07-20 07:23 -0500
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-07-19 21:11 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 15:37 -0700
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-09 13:55 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 11:22 -0700
Re: Recursion or loop, design questions Gareth Owen <gwowen@gmail.com> - 2015-07-19 17:22 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 10:25 -0700
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-19 03:15 -0500
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-19 10:36 +0100
Re: Recursion or loop, design questions Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-07-19 12:45 -0400
Re: Recursion or loop, design questions Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-07-19 13:05 -0400
Re: Recursion or loop, design questions Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-07-19 13:09 -0400
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 10:40 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-19 22:31 +0100
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-09 14:05 +0000
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-09 21:22 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-09 16:14 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-10 05:39 +0200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-10 01:40 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-08-10 21:03 +1200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-10 03:16 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-10 12:16 +0200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-10 03:36 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-10 12:45 +0200
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:07 +0000
Re: Recursion or loop, design questions raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:07 +0000
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 02:47 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-19 22:23 +1200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 05:01 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-20 09:55 +1200
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-19 23:13 +0100
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-20 10:19 +1200
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-19 17:21 -0500
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-20 00:25 +0100
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-20 11:45 +1200
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-20 02:34 -0500
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-20 10:52 +0100
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-20 05:31 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 22:16 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-20 17:24 +1200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 22:36 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-20 21:07 +1200
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-20 02:51 -0700
Re: Recursion or loop, design questions Les Cargill <lcargill99@comcast.com> - 2015-07-19 10:12 -0500
Re: Recursion or loop, design questions Robert Wessel <robertwessel2@yahoo.com> - 2015-07-19 16:54 -0500
Re: Recursion or loop, design questions Les Cargill <lcargill99@comcast.com> - 2015-07-20 12:34 -0500
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 07:28 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-27 11:08 +0200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-30 15:45 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-02 14:59 +0200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 08:40 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-08-04 23:05 +0200
Re: Recursion or loop, design questions Keith Thompson <kst-u@mib.org> - 2015-07-19 12:46 -0700
Re: Recursion or loop, design questions Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-19 12:57 -0700
Re: Recursion or loop, design questions Gareth Owen <gwowen@gmail.com> - 2015-07-19 21:16 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 15:50 -0700
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-18 09:13 -0400
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 15:04 +0100
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-18 12:40 -0400
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 16:27 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 14:26 +0100
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-18 09:58 -0400
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 15:24 +0100
Re: Recursion or loop, design questions Richard Damon <Richard@Damon-Family.org> - 2015-07-18 10:29 -0400
Re: Recursion or loop, design questions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-18 17:32 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 15:28 -0700
Re: Recursion or loop, design questions glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-20 22:58 +0000
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 03:13 -0700
Re: Recursion or loop, design questions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-18 21:49 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 15:12 -0700
Re: Recursion or loop, design questions "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-07-20 15:21 -0700
Re: Recursion or loop, design questions "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-07-20 15:23 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 03:46 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 03:31 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-21 04:08 -0700
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 08:50 -0700
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-11 18:43 +0200
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-11 18:54 +0200
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-11 13:06 -0400
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-12 23:45 +0200
Re: Recursion or loop, design questions James Kuyper <jameskuyper@verizon.net> - 2015-07-12 17:48 -0400
Re: Recursion or loop, design questions "Morten W. Petersen" <morphex@gmail.com> - 2015-07-13 01:27 +0200
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-11 19:39 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-11 14:51 -0700
Re: Recursion or loop, design questions Bartc <bc@freeuk.com> - 2015-07-11 23:51 +0100
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-15 08:04 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-16 09:36 +1200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 10:37 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-21 20:55 +1200
Re: Recursion or loop, design questions Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-23 07:39 -0700
Re: Recursion or loop, design questions Ian Collins <ian-news@hotmail.com> - 2015-07-16 09:41 +1200
Page 1 of 15 [1] 2 3 … 15 Next page →
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-09 12:49 +0200 |
| Subject | Recursion or loop, design questions |
| Message-ID | <mnljil$g29$1@speranza.aioe.org> |
Hi there. :) I'm working on an XML parser and writer, located here: https://github.com/morphex/smash_xml Now I'm getting to the point where I want to parse an entire XML file and get an internal representation of the XML file. As for internal representation, choosing a linked-list structure seems like the way to go. However, choosing between recursion and looping is less obvious, to me at least. From what I've gleaned so far, there will be function overhead on every level of recursion, while a loop will avoid the function overhead. There will be a limited amount of ways any given character can be handled. So choosing looping seems like the right way to go about it. Threading will also be added later, does that point towards recursion or looping? Regards, Morten
[toc] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-09 12:03 +0100 |
| Message-ID | <mnlkao$veg$1@dont-email.me> |
| In reply to | #64979 |
On 09/07/15 11:49, Morten W. Petersen wrote: > Hi there. :) > > I'm working on an XML parser and writer, located here: > > https://github.com/morphex/smash_xml > > Now I'm getting to the point where I want to parse an entire > XML file and get an internal representation of the XML file. I would recommend lexing it first, and then parsing the lexed list. > As for internal representation, choosing a linked-list > structure seems like the way to go. For a list of lexemes, yes. Normally a tree structure is preferable for the actual parse. > However, choosing between recursion and looping is less > obvious, to me at least. Which choice models the problem most naturally? I'd have said recursion. > From what I've gleaned so far, there will be function > overhead on every level of recursion, while a loop will > avoid the function overhead. That's micro-optimisation, and it's premature. Here's how you optimise for speed: 1) decide how fast you need it to be (in, say, MB/sec). Be realistic - don't say "as fast as possible" or "1TB/sec". 2) choose good algorithms and good data structures. Forget about stuff like function overhead and loop unrolling and all that until later. 3) write the code so that it's *readable*. 4) get it working, but *keep* it readable. 5) now, and *only* now, measure the speed. Until you have met your speed target, profile the program, identify the principal avoidable bottleneck (if you're reading from a 28kbps network connection, for example, no amount of tweaking the code is going to help you), and rewrite the code to minimise the effect of the bottleneck, *while keeping the program readable and correct*. When you have met your speed target, STOP. Readability is a higher priority than correctness, and correctness is a higher priority than speed. (It's easier to make a readable program correct than to make a correct program readable, and it's easier to make a correct program fast than to make a fast program correct.) -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-09 14:15 +0200 |
| Message-ID | <mnloih$v68$1@speranza.aioe.org> |
| In reply to | #64980 |
On 09.07.2015 13:03, Richard Heathfield wrote: > On 09/07/15 11:49, Morten W. Petersen wrote: >> Hi there. :) >> >> I'm working on an XML parser and writer, located here: >> >> https://github.com/morphex/smash_xml >> >> Now I'm getting to the point where I want to parse an entire >> XML file and get an internal representation of the XML file. > > I would recommend lexing it first, and then parsing the lexed list. Yes, I was thinking of something like that. The benefit of that would be that the process of getting the XML to an internal representation could be broken up into threads, where the lexer should be simple and fast and "run ahead". >> As for internal representation, choosing a linked-list >> structure seems like the way to go. > > For a list of lexemes, yes. Normally a tree structure is preferable for > the actual parse. Hm, I'm not sure what you mean here? >> However, choosing between recursion and looping is less >> obvious, to me at least. > > Which choice models the problem most naturally? I'd have said recursion. > >> From what I've gleaned so far, there will be function >> overhead on every level of recursion, while a loop will >> avoid the function overhead. > > That's micro-optimisation, and it's premature. Well, say you have an XHTML file. Most of those files aren't deeply nested. In a loop you can use a LIFO stack to keep track of where the program (element nesting and context) is. > Here's how you optimise for speed: > > 1) decide how fast you need it to be (in, say, MB/sec). Be realistic - > don't say "as fast as possible" or "1TB/sec". > 2) choose good algorithms and good data structures. Forget about stuff > like function overhead and loop unrolling and all that until later. > 3) write the code so that it's *readable*. > 4) get it working, but *keep* it readable. > 5) now, and *only* now, measure the speed. Until you have met your speed > target, profile the program, identify the principal avoidable bottleneck > (if you're reading from a 28kbps network connection, for example, no > amount of tweaking the code is going to help you), and rewrite the code > to minimise the effect of the bottleneck, *while keeping the program > readable and correct*. When you have met your speed target, STOP. > > Readability is a higher priority than correctness, and correctness is a > higher priority than speed. (It's easier to make a readable program > correct than to make a correct program readable, and it's easier to make > a correct program fast than to make a fast program correct.) I agree, readability is the most important thing; I've caught many bugs by just looking over the code. As for finding a processing speed, maybe diving CPU clock speed by 50 instructions per character is something to go by? I think the most important thing is good and simple data structures, and for example I'm choosing now to just implement 4 byte internal storage for Unicode characters and creating lots of tests, which can contribute to predictable and stable optimizations later. However, choosing between recursion and looping seems important, as that's the (...) main part of the program. I was thinking of having a big XML file read on a RAM FS and then seeing how fast it can go. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-09 13:49 +0100 |
| Message-ID | <mnlqik$leq$1@dont-email.me> |
| In reply to | #64986 |
On 09/07/15 13:15, Morten W. Petersen wrote: > On 09.07.2015 13:03, Richard Heathfield wrote: >> On 09/07/15 11:49, Morten W. Petersen wrote: >>> Hi there. :) >>> >>> I'm working on an XML parser and writer, located here: >>> >>> https://github.com/morphex/smash_xml >>> >>> Now I'm getting to the point where I want to parse an entire >>> XML file and get an internal representation of the XML file. >> >> I would recommend lexing it first, and then parsing the lexed list. > > Yes, I was thinking of something like that. The benefit of > that would be that the process of getting the XML to > an internal representation could be broken up into threads, > where the lexer should be simple and fast and "run ahead". <shrug> You wouldn't need to. The lexer will run like something smelly off a shiny shovel. Firing up a thread for that purpose is pointless obfuscation. Why make the program hard to read, right off the bat, when there's no need? >>> As for internal representation, choosing a linked-list >>> structure seems like the way to go. >> >> For a list of lexemes, yes. Normally a tree structure is preferable for >> the actual parse. > > Hm, I'm not sure what you mean here? The lexing stage creates a linked list of lexemes (lexical elements). The parser then processes that list, creating the object tree. XML is inherently tree-like in nature. See http://www.w3schools.com/xml/xml_tree.asp for a better explanation than I'm likely to manage here. Once you accept (and you will, eventually) that XML is tree-like in nature, it makes sense to convert the XML data into an internal representation that reflects that tree-like nature. >>> From what I've gleaned so far, there will be function >>> overhead on every level of recursion, while a loop will >>> avoid the function overhead. >> >> That's micro-optimisation, and it's premature. > > Well, say you have an XHTML file. Most of those files aren't deeply > nested. > > In a loop you can use a LIFO stack to keep track of where the program > (element nesting and context) is. Yes, you can, but why go to all that trouble? Recursion gives you that for free, and it's a more natural way to think about what's going on. > >> Here's how you optimise for speed: >> >> 1) decide how fast you need it to be (in, say, MB/sec). Be realistic - >> don't say "as fast as possible" or "1TB/sec". >> 2) choose good algorithms and good data structures. Forget about stuff >> like function overhead and loop unrolling and all that until later. >> 3) write the code so that it's *readable*. >> 4) get it working, but *keep* it readable. >> 5) now, and *only* now, measure the speed. Until you have met your speed >> target, profile the program, identify the principal avoidable bottleneck >> (if you're reading from a 28kbps network connection, for example, no >> amount of tweaking the code is going to help you), and rewrite the code >> to minimise the effect of the bottleneck, *while keeping the program >> readable and correct*. When you have met your speed target, STOP. >> >> Readability is a higher priority than correctness, and correctness is a >> higher priority than speed. (It's easier to make a readable program >> correct than to make a correct program readable, and it's easier to make >> a correct program fast than to make a fast program correct.) > > I agree, readability is the most important thing; I've caught many bugs > by just looking over the code. > > As for finding a processing speed, maybe diving CPU clock speed by > 50 instructions per character is something to go by? I don't see how that's meaningful. All right, look at it this way: I have a program that does not-very-good encryption on arbitrary data. I run it like this: $ scc data.in data.out key iv data.in is the thing I'm encrypting. This one happens to be 4336263 bytes. scc isn't optimised in any way (no special compiler settings or anything like that). If I run this program and time it: $ time scc data.in data.out key iv I get these results: real 0m0.371s user 0m0.340s sys 0m0.008s Now, from my point of view the reason for having a fast program is so that I don't have to wait around for it. I don't give a stuff about anything but wall clock time, which in this case is 0.371 seconds. That's for processing 4336263 bytes. Now, the scaling may not be linear, but I happen to know that it probably is in this case, so we're looking at well over 11 Megabytes of data being processed per second. *BUT* I don't actually do very much with the data - I just encrypt it. XML processing is likely to be more costly. So... would you be happy with, say, 4 MB/sec? Personally, I'd be more than happy with that. The King James Version of the Bible is about 4 MB - a fair bit more than a thousand pages. If you can process that much data in a single second, I'd say you definitely had something usable. (In fact, 1 MB in a single second would be pretty darn good.) Most of your data is likely to be much less than a Megabyte, so (as long as you choose sensible algorithms and data structures) there is absolutely no need to make these tiny little micro-decisions about speed. They simply won't make any noticeable difference whatsoever. > I think the most important thing is good and simple data structures, > and for example I'm choosing now to just implement 4 byte internal > storage for Unicode characters and creating lots of tests, which > can contribute to predictable and stable optimizations later. > > However, choosing between recursion and looping seems important, > as that's the (...) main part of the program. Which do you think will be easier to write, read, and maintain? That should absolutely be your top priority. > I was thinking of having a big XML file read on a RAM FS and > then seeing how fast it can go. Faster than you could reasonably require it to. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-09 15:15 +0200 |
| Message-ID | <mnls4b$8f6$1@speranza.aioe.org> |
| In reply to | #64991 |
On 09.07.2015 14:49, Richard Heathfield wrote: > On 09/07/15 13:15, Morten W. Petersen wrote: >> On 09.07.2015 13:03, Richard Heathfield wrote: >>> On 09/07/15 11:49, Morten W. Petersen wrote: >>>> Hi there. :) >>>> >>>> I'm working on an XML parser and writer, located here: >>>> >>>> https://github.com/morphex/smash_xml >>>> >>>> Now I'm getting to the point where I want to parse an entire >>>> XML file and get an internal representation of the XML file. >>> >>> I would recommend lexing it first, and then parsing the lexed list. >> >> Yes, I was thinking of something like that. The benefit of >> that would be that the process of getting the XML to >> an internal representation could be broken up into threads, >> where the lexer should be simple and fast and "run ahead". > > <shrug> You wouldn't need to. The lexer will run like something smelly > off a shiny shovel. Firing up a thread for that purpose is pointless > obfuscation. Why make the program hard to read, right off the bat, when > there's no need? The lexer can also be setup to do other things, like creating an intermediate data structure that the "main" parser can use, this can be balanced better as necessary. >>>> As for internal representation, choosing a linked-list >>>> structure seems like the way to go. >>> >>> For a list of lexemes, yes. Normally a tree structure is preferable for >>> the actual parse. >> >> Hm, I'm not sure what you mean here? > > The lexing stage creates a linked list of lexemes (lexical elements). > The parser then processes that list, creating the object tree. > > XML is inherently tree-like in nature. > > See http://www.w3schools.com/xml/xml_tree.asp for a better explanation > than I'm likely to manage here. > > Once you accept (and you will, eventually) that XML is tree-like in > nature, it makes sense to convert the XML data into an internal > representation that reflects that tree-like nature. Yes, I haven't disagreed that XML is tree-like, probably some misunderstanding here. >>>> From what I've gleaned so far, there will be function >>>> overhead on every level of recursion, while a loop will >>>> avoid the function overhead. >>> >>> That's micro-optimisation, and it's premature. >> >> Well, say you have an XHTML file. Most of those files aren't deeply >> nested. >> >> In a loop you can use a LIFO stack to keep track of where the program >> (element nesting and context) is. > > Yes, you can, but why go to all that trouble? Recursion gives you that > for free, and it's a more natural way to think about what's going on. Well, speed is an issue, and I'd rather write a large block of code once than twice. As Bart pointed out, XML files 10 GBs in size should be handled as well. >> I think the most important thing is good and simple data structures, >> and for example I'm choosing now to just implement 4 byte internal >> storage for Unicode characters and creating lots of tests, which >> can contribute to predictable and stable optimizations later. >> >> However, choosing between recursion and looping seems important, >> as that's the (...) main part of the program. > > Which do you think will be easier to write, read, and maintain? That > should absolutely be your top priority. I think in total, making the right decision between recursion and looping will save me quite some programming time. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-09 14:25 +0100 |
| Message-ID | <mnlslo$tf8$1@dont-email.me> |
| In reply to | #64995 |
On 09/07/15 14:15, Morten W. Petersen wrote: > On 09.07.2015 14:49, Richard Heathfield wrote: >> On 09/07/15 13:15, Morten W. Petersen wrote: >>> On 09.07.2015 13:03, Richard Heathfield wrote: >>>> On 09/07/15 11:49, Morten W. Petersen wrote: >>>>> Hi there. :) >>>>> >>>>> I'm working on an XML parser and writer, located here: >>>>> >>>>> https://github.com/morphex/smash_xml >>>>> >>>>> Now I'm getting to the point where I want to parse an entire >>>>> XML file and get an internal representation of the XML file. >>>> >>>> I would recommend lexing it first, and then parsing the lexed list. >>> >>> Yes, I was thinking of something like that. The benefit of >>> that would be that the process of getting the XML to >>> an internal representation could be broken up into threads, >>> where the lexer should be simple and fast and "run ahead". >> >> <shrug> You wouldn't need to. The lexer will run like something smelly >> off a shiny shovel. Firing up a thread for that purpose is pointless >> obfuscation. Why make the program hard to read, right off the bat, when >> there's no need? > > The lexer can also be setup to do other things, like creating an > intermediate data structure that the "main" parser can use, this > can be balanced better as necessary. Keep it simple, and you'll thank yourself later. If you need a stage between lexing and parsing, put it /between/ lexing and parsing - don't try to complicate the lexer if you can possibly avoid it. <snip> >>> In a loop you can use a LIFO stack to keep track of where the program >>> (element nesting and context) is. >> >> Yes, you can, but why go to all that trouble? Recursion gives you that >> for free, and it's a more natural way to think about what's going on. > > Well, speed is an issue, and I'd rather write a large block of > code once than twice. How do you know speed is an issue until you measure it? When I asked how fast you wanted it to go, you didn't know. Is a Megabyte a second acceptable? If not, how fast /is/ acceptable? Decide before you write a single line of code. As for writing a large block of code once rather than twice, if you make the right decision up front, you'll only have to write it once (and it won't actually be that large). But remember Brooks's observation: "plan to throw the first one out - you will anyway". > As Bart pointed out, XML files 10 GBs in size should be handled > as well. One cannot help but wonder why. Will your process have access to 10GB? If not, you're going to have to store some of the data on disk, which you'll probably do by writing out... XML! What in heaven's name are you reading about that takes 10GB to describe? The only thing I can think of is video data, and there are far better ways than XML to store video data. >>> I think the most important thing is good and simple data structures, >>> and for example I'm choosing now to just implement 4 byte internal >>> storage for Unicode characters and creating lots of tests, which >>> can contribute to predictable and stable optimizations later. >>> >>> However, choosing between recursion and looping seems important, >>> as that's the (...) main part of the program. >> >> Which do you think will be easier to write, read, and maintain? That >> should absolutely be your top priority. > > I think in total, making the right decision between recursion > and looping will save me quite some programming time. Aye. You can have a stack for free, or you can spend the time it takes to write your own. Your call. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-09 15:36 +0200 |
| Message-ID | <mnltbp$bka$1@speranza.aioe.org> |
| In reply to | #64999 |
On 09.07.2015 15:25, Richard Heathfield wrote: > On 09/07/15 14:15, Morten W. Petersen wrote: [...] >> Well, speed is an issue, and I'd rather write a large block of >> code once than twice. > > How do you know speed is an issue until you measure it? When I asked how > fast you wanted it to go, you didn't know. Is a Megabyte a second > acceptable? If not, how fast /is/ acceptable? Decide before you write a > single line of code. > > As for writing a large block of code once rather than twice, if you make > the right decision up front, you'll only have to write it once (and it > won't actually be that large). But remember Brooks's observation: "plan > to throw the first one out - you will anyway". > >> As Bart pointed out, XML files 10 GBs in size should be handled >> as well. > > One cannot help but wonder why. Will your process have access to 10GB? > If not, you're going to have to store some of the data on disk, which > you'll probably do by writing out... XML! What in heaven's name are you > reading about that takes 10GB to describe? The only thing I can think of > is video data, and there are far better ways than XML to store video data. Well, it looks like dumps of for example Wikipedia can be around that size. >>>> I think the most important thing is good and simple data structures, >>>> and for example I'm choosing now to just implement 4 byte internal >>>> storage for Unicode characters and creating lots of tests, which >>>> can contribute to predictable and stable optimizations later. >>>> >>>> However, choosing between recursion and looping seems important, >>>> as that's the (...) main part of the program. >>> >>> Which do you think will be easier to write, read, and maintain? That >>> should absolutely be your top priority. >> >> I think in total, making the right decision between recursion >> and looping will save me quite some programming time. > > Aye. You can have a stack for free, or you can spend the time it takes > to write your own. Your call. My understanding of recursion, functions and looping is that: If a function is inlined, the compiler can avoid copying the value of the arguments and setting up a stack. However, when using recursion, this effect can't be achieved. A loop, some pointers and if-statements can be used to achieve the same as a recursive setup, working on the same data structures, but with less overhead. Am I wrong in thinking this? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-09 14:51 +0100 |
| Message-ID | <mnlu6e$3et$1@dont-email.me> |
| In reply to | #65001 |
On 09/07/15 14:36, Morten W. Petersen wrote: > On 09.07.2015 15:25, Richard Heathfield wrote: >> On 09/07/15 14:15, Morten W. Petersen wrote: > [...] >>> Well, speed is an issue, and I'd rather write a large block of >>> code once than twice. >> >> How do you know speed is an issue until you measure it? When I asked how >> fast you wanted it to go, you didn't know. Is a Megabyte a second >> acceptable? If not, how fast /is/ acceptable? Decide before you write a >> single line of code. >> >> As for writing a large block of code once rather than twice, if you make >> the right decision up front, you'll only have to write it once (and it >> won't actually be that large). But remember Brooks's observation: "plan >> to throw the first one out - you will anyway". >> >>> As Bart pointed out, XML files 10 GBs in size should be handled >>> as well. >> >> One cannot help but wonder why. Will your process have access to 10GB? >> If not, you're going to have to store some of the data on disk, which >> you'll probably do by writing out... XML! What in heaven's name are you >> reading about that takes 10GB to describe? The only thing I can think of >> is video data, and there are far better ways than XML to store video data. > > Well, it looks like dumps of for example Wikipedia can be around that > size. Oh, I see. You may be interested to hear how I solved that problem. I've managed to persuade some people to store the Wikipedia data on the other end of a TCP/IP connection, and I just go and find what I need, when I need it. :-) Seriously, if you want a data dump of Wikipedia, fine, but you surely don't need it all in memory at once, though, do you? I must confess that I just wouldn't even *try* to search a data dump of the entire Wikipedia by sucking the whole lot into memory. In fact, I'd probably store it in a database and use SQL to search it. >>>>> I think the most important thing is good and simple data structures, >>>>> and for example I'm choosing now to just implement 4 byte internal >>>>> storage for Unicode characters and creating lots of tests, which >>>>> can contribute to predictable and stable optimizations later. >>>>> >>>>> However, choosing between recursion and looping seems important, >>>>> as that's the (...) main part of the program. >>>> >>>> Which do you think will be easier to write, read, and maintain? That >>>> should absolutely be your top priority. >>> >>> I think in total, making the right decision between recursion >>> and looping will save me quite some programming time. >> >> Aye. You can have a stack for free, or you can spend the time it takes >> to write your own. Your call. > > My understanding of recursion, functions and looping is that: > > If a function is inlined, the compiler can avoid copying the value of > the arguments and setting up a stack. However, when using recursion, > this effect can't be achieved. > > A loop, some pointers and if-statements can be used to achieve the > same as a recursive setup, working on the same data structures, but > with less overhead. > > Am I wrong in thinking this? I think you're wrong in thinking it's something to think about in your first cut. First cut, keep it *simple*. Good data structures, good algorithms, and stop worrying about micro-optimisation. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-09 16:02 +0200 |
| Message-ID | <mnlurh$fk4$1@speranza.aioe.org> |
| In reply to | #65002 |
On 09.07.2015 15:51, Richard Heathfield wrote: > On 09/07/15 14:36, Morten W. Petersen wrote: [...] >> Well, it looks like dumps of for example Wikipedia can be around that >> size. > > Oh, I see. > > You may be interested to hear how I solved that problem. I've managed to > persuade some people to store the Wikipedia data on the other end of a > TCP/IP connection, and I just go and find what I need, when I need it. :-) > > Seriously, if you want a data dump of Wikipedia, fine, but you surely > don't need it all in memory at once, though, do you? > > I must confess that I just wouldn't even *try* to search a data dump of > the entire Wikipedia by sucking the whole lot into memory. In fact, I'd > probably store it in a database and use SQL to search it. Well.. to me it looks like more and more information is made by people and stored about people and whatever events that happen. So database use and files aren't shrinking, to put it that way. MySQL to me is maybe a bit heavy-handed for a lot of common things like for example log files. :) I agree that some things belong in binary files and it would be wasteful to store them in XML. As for Wikipedia on the other end of a magical tube, fine, I also know people who prefer to have it on their phone and update it over a broadband connection instead of mobile internet. :) -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-09 20:48 +0100 |
| Message-ID | <871tghyuvo.fsf@bsb.me.uk> |
| In reply to | #65001 |
"Morten W. Petersen" <morphex@gmail.com> writes: <snip> > My understanding of recursion, functions and looping is that: > > If a function is inlined, the compiler can avoid copying the value of > the arguments and setting up a stack. However, when using recursion, > this effect can't be achieved. > > A loop, some pointers and if-statements can be used to achieve the > same as a recursive setup, working on the same data structures, but > with less overhead. > > Am I wrong in thinking this? Yes. Some of the detail is wrong (for example a compiler can sometimes remove a recursive function call altogether, and inling is often clever than you think) but the main problem is that you are thinking about it at all. Your best bet, by far, is to prototype your parser and do some timings. You can then throw it all away if you need to but you'll have some real data to work with. you may find that other choices (32-bit characters for example) are far more costly than a function call now and then. The joy of a recursive solution is you should be able to knock one up in a day or so and you can start working from data rather than guesses. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-09 09:54 -0400 |
| Message-ID | <mnluc2$448$1@dont-email.me> |
| In reply to | #64995 |
On 07/09/2015 09:15 AM, Morten W. Petersen wrote: > On 09.07.2015 14:49, Richard Heathfield wrote: ... >> Yes, you can, but why go to all that trouble? Recursion gives you that >> for free, and it's a more natural way to think about what's going on. > > Well, speed is an issue, and I'd rather write a large block of > code once than twice. If speed is that important, you should NOT be worried about wasting your time re-writing the code. You should be worried about wasting your time speeding up code before you know whether or not it's slow. You should be worried about wasting your time correcting bugs that you introduced by making it more complicated than it needed to be, before you've collected enough information to justify concluding that it needed to be that complicated. You should be worried about wasting your time speeding up a part of the program that contributes little or nothing to the total run time, time you could have spent speeding up the part of the program that really runs slow. Write it readable, write it correct, run it to determine whether it's fast enough. If it isn't, profile it to identify time hogs - and only then, start re-designing the time hogs (and only the time hogs) for improved speed. Designing for speed at any time prior to that is likely to produce a speed improvement too small to justify the time spent to achieve it. You can cost-effectively apply your time to speeding up your program only if you first have a program to speed up, and measure it's speed to determine which parts deserve your attention. Those usually aren't the parts you thought would need your attention. ... >> Which do you think will be easier to write, read, and maintain? That >> should absolutely be your top priority. > > I think in total, making the right decision between recursion > and looping will save me quite some programming time. Making that decision based upon speed, before you've got any code to measure the speed, will be a bigger waste of your programming time. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-09 15:08 +0100 |
| Message-ID | <mnlv62$6i9$1@dont-email.me> |
| In reply to | #65003 |
On 09/07/15 14:54, James Kuyper wrote: <snip> > Write it readable, write it correct, run it to determine whether it's > fast enough. That sounds familiar. :-) He didn't listen to me, but perhaps he'll listen to you. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-09 16:16 +0200 |
| Message-ID | <mnlvlu$hlt$1@speranza.aioe.org> |
| In reply to | #65005 |
On 09.07.2015 16:08, Richard Heathfield wrote: > On 09/07/15 14:54, James Kuyper wrote: > > <snip> > >> Write it readable, write it correct, run it to determine whether it's >> fast enough. > > That sounds familiar. :-) > > He didn't listen to me, but perhaps he'll listen to you. Heh, well the points you bring up are appreciated. :) Recursion or looping, two different options. I'm familiar with recursion and think it is quite nice. However, my gut-feeling says looping, so I'm going for that, and worst-case is that I spend some extra time and learn more about working with C and stacks. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-09 15:18 +0100 |
| Message-ID | <mnlvpn$8ri$1@dont-email.me> |
| In reply to | #65006 |
On 09/07/15 15:16, Morten W. Petersen wrote: > On 09.07.2015 16:08, Richard Heathfield wrote: >> On 09/07/15 14:54, James Kuyper wrote: >> >> <snip> >> >>> Write it readable, write it correct, run it to determine whether it's >>> fast enough. >> >> That sounds familiar. :-) >> >> He didn't listen to me, but perhaps he'll listen to you. > > Heh, well the points you bring up are appreciated. :) > > Recursion or looping, two different options. I'm familiar > with recursion and think it is quite nice. > > However, my gut-feeling says looping, so I'm going for that, > and worst-case is that I spend some extra time and learn > more about working with C and stacks. Do you recall that I said you should plan to throw one out, because you will anyway? If I were a betting man, at this point I'd be offering pretty good odds. But, as you say, you will learn a lesson from it. In this case, the lesson may well turn out to be that you shouldn't trust your gut-feeling. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-09 16:24 +0200 |
| Message-ID | <mnm04s$ina$1@speranza.aioe.org> |
| In reply to | #65008 |
On 09.07.2015 16:18, Richard Heathfield wrote: > On 09/07/15 15:16, Morten W. Petersen wrote: [...] >> Heh, well the points you bring up are appreciated. :) >> >> Recursion or looping, two different options. I'm familiar >> with recursion and think it is quite nice. >> >> However, my gut-feeling says looping, so I'm going for that, >> and worst-case is that I spend some extra time and learn >> more about working with C and stacks. > > Do you recall that I said you should plan to throw one out, because you > will anyway? If I were a betting man, at this point I'd be offering > pretty good odds. But, as you say, you will learn a lesson from it. In > this case, the lesson may well turn out to be that you shouldn't trust > your gut-feeling. Well, for some time now I've been enjoying a good slice of bacon, an egg and some peas and carrots for lunch or dinner. My gut-feeling feels better now, even if some "knowsters" would recommend otherwise. :) -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-09 20:31 +0100 |
| Message-ID | <87d201yvo2.fsf@bsb.me.uk> |
| In reply to | #65006 |
"Morten W. Petersen" <morphex@gmail.com> writes: <snip> > Recursion or looping, two different options. I'm familiar > with recursion and think it is quite nice. > > However, my gut-feeling says looping, so I'm going for that, When I read your head post, my gut told me you'd already decided and there was not point in replying. That seems to have been the case. All the replies I've seen have said "it's a recursive structure, parse it with recursion" but that has not persuaded you. My gut was right this time. > and worst-case is that I spend some extra time and learn > more about working with C and stacks. There are much worse cases! I hope you avoid them all. But if speed is such an issue (why is it, by the way?) why have you chosen to shuffle around almost two to four times the data that you might expect to have to shuffle around? Don't you worry about that? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-09 21:42 +0200 |
| Message-ID | <mnmip7$1ao$1@speranza.aioe.org> |
| In reply to | #65057 |
On 09.07.2015 21:31, Ben Bacarisse wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: > <snip> >> Recursion or looping, two different options. I'm familiar >> with recursion and think it is quite nice. >> >> However, my gut-feeling says looping, so I'm going for that, > > When I read your head post, my gut told me you'd already decided and > there was not point in replying. That seems to have been the case. All > the replies I've seen have said "it's a recursive structure, parse it > with recursion" but that has not persuaded you. My gut was right this > time. Well, I thought about using just loops for performance reasons. But trees lend themselves very well to recursion, so it looks like recursion is the right way to go when doing a set of tasks with the internal representation. >> and worst-case is that I spend some extra time and learn >> more about working with C and stacks. > > There are much worse cases! I hope you avoid them all. > > But if speed is such an issue (why is it, by the way?) why have you > chosen to shuffle around almost two to four times the data that you might > expect to have to shuffle around? Don't you worry about that? I did "worry" about it, before I decided on it. Some years ago, I thought English was the solution for everything because that would be easier. Now though, I appreciate the differences more and realistically, it might be a very, very long time before we have one language that everyone knows well. And at that point, there will be a lot of data that exists in different languages. And some things do get lost in translation. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-10 00:57 +0100 |
| Message-ID | <87egkgyj9g.fsf@bsb.me.uk> |
| In reply to | #65059 |
"Morten W. Petersen" <morphex@gmail.com> writes: > On 09.07.2015 21:31, Ben Bacarisse wrote: >> "Morten W. Petersen" <morphex@gmail.com> writes: >> <snip> >>> Recursion or looping, two different options. I'm familiar >>> with recursion and think it is quite nice. >>> >>> However, my gut-feeling says looping, so I'm going for that, >> >> When I read your head post, my gut told me you'd already decided and >> there was not point in replying. That seems to have been the case. All >> the replies I've seen have said "it's a recursive structure, parse it >> with recursion" but that has not persuaded you. My gut was right this >> time. > > Well, I thought about using just loops for performance reasons. Sure, but in my experience there are people for whom nothing can trump performance reasons. Now you may not be such a person, but it looks like you might be from previous posts. I was one once, so I recognise the symptoms! > But trees lend themselves very well to recursion, so it looks like > recursion is the right way to go when doing a set of tasks with > the internal representation. Like building it (i.e. parsing it)! >>> and worst-case is that I spend some extra time and learn >>> more about working with C and stacks. >> >> There are much worse cases! I hope you avoid them all. >> >> But if speed is such an issue (why is it, by the way?) why have you >> chosen to shuffle around almost two to four times the data that you might >> expect to have to shuffle around? Don't you worry about that? > > I did "worry" about it, before I decided on it. Some years ago, I > thought English was the solution for everything because that would > be easier. > > Now though, I appreciate the differences more and realistically, > it might be a very, very long time before we have one language that > everyone knows well. And at that point, there will be a lot of data > that exists in different languages. Of course there are and there will be more and more. And if you are prepared to pay that price for documents that are relatively rare, that's fine. It just makes your worry about function calls look a bit odd. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-09 20:39 +0100 |
| Message-ID | <877fq9yvbd.fsf@bsb.me.uk> |
| In reply to | #64991 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 09/07/15 13:15, Morten W. Petersen wrote: >> On 09.07.2015 13:03, Richard Heathfield wrote: >>> On 09/07/15 11:49, Morten W. Petersen wrote: <snip> >>>> As for internal representation, choosing a linked-list >>>> structure seems like the way to go. >>> >>> For a list of lexemes, yes. Normally a tree structure is preferable for >>> the actual parse. >> >> Hm, I'm not sure what you mean here? > > The lexing stage creates a linked list of lexemes (lexical > elements). The parser then processes that list, creating the object > tree. For most modern syntaxes, you need only one (occasionally two) tokens "in hand" for the parse to be done. It's very rare that you need the tokens in a list. The OP is thinking of having a lexing thread, so some sort of buffer between it and the parser is needed (and a linked list is probably as good as any), but you are not, I gather, advocating that design. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-09 21:44 +0100 |
| Message-ID | <mnmmcg$mqf$1@dont-email.me> |
| In reply to | #65058 |
On 09/07/15 20:39, Ben Bacarisse wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > >> The lexing stage creates a linked list of lexemes (lexical >> elements). The parser then processes that list, creating the object >> tree. > > For most modern syntaxes, you need only one (occasionally two) tokens > "in hand" for the parse to be done. It's very rare that you need the > tokens in a list. This is his first parser, so I think he's better off with a simple design that does one job at a time. > The OP is thinking of having a lexing thread, so some sort of buffer > between it and the parser is needed (and a linked list is probably as > good as any), but you are not, I gather, advocating that design. No, I wouldn't advocate threading, but then I never do. :-) -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
Page 1 of 15 [1] 2 3 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web