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 14 of 15 — ← Prev page 1 … 12 13 [14] 15 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-20 16:27 -0700 |
| Message-ID | <kfnsi8ijtoh.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65845 |
James Kuyper <jameskuyper@verizon.net> writes: > [snip] > > The key feature of a tail-call is that all memory set aside for the > calling function can be dropped. In a C context, that implies an > additional requirement: setjmp() must not be called in the calling > function prior to the tail call. This confuses the distinction between what constitutes a tail call and when tail-call optimization may be done. A previous call to setjmp() can inhibit tail-call optimization, but the call still be a tail call. Other circumstances can inhibit tail-call optimization, such as there being pointers to local objects. The question of when tail-call optimization can be done depends on these different factors, some of which are implementation specific. So I think it's better to keep the two notions separate.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-18 14:26 +0100 |
| Message-ID | <87io9hbnqs.fsf@bsb.me.uk> |
| In reply to | #65838 |
ram@zedat.fu-berlin.de (Stefan Ram) writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > [tail call] >>In a non-void function its a return statement whose expression is a >>function call. > > So, this is not a tail call? > > return i > 0 ? f() : g(); > > After all, the expression of this return is not a function call! I'd say no, simply because it does not meet my definition. A definition like this is given for a purpose, and without one it's hard to say how good or how bad a definition it is. But if the purpose were to allow a future C standard to say "tail calls will be optimised" there would be some merit in making the definition syntactically simple. You could make it more fiddly by using C's sequence points (or the new terminology about sequencing) to include cases like yours and also return ..., g(); return f() || g(); return f() && g(); but I don't think I would. After all you don't want the definition of one optimisation to preclude the possibility of others that may depend on code re-ordering. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-18 09:58 -0400 |
| Message-ID | <modlvp$ril$1@dont-email.me> |
| In reply to | #65846 |
On 07/18/2015 09:26 AM, Ben Bacarisse wrote: > ram@zedat.fu-berlin.de (Stefan Ram) writes: > >> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> [tail call] >>> In a non-void function its a return statement whose expression is a >>> function call. >> >> So, this is not a tail call? >> >> return i > 0 ? f() : g(); >> >> After all, the expression of this return is not a function call! > > I'd say no, simply because it does not meet my definition. A definition > like this is given for a purpose, and without one it's hard to say how > good or how bad a definition it is. But if the purpose were to allow a > future C standard to say "tail calls will be optimised" there would be > some merit in making the definition syntactically simple. > > You could make it more fiddly by using C's sequence points (or the new > terminology about sequencing) to include cases like yours and also > > return ..., g(); > return f() || g(); > return f() && g(); In those last two cases, the function must do something with the return value before returning itself. I think that fact would inhibit tail-call optimization. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-18 15:24 +0100 |
| Message-ID | <874ml1bl2w.fsf@bsb.me.uk> |
| In reply to | #65850 |
James Kuyper <jameskuyper@verizon.net> writes: > On 07/18/2015 09:26 AM, Ben Bacarisse wrote: >> ram@zedat.fu-berlin.de (Stefan Ram) writes: >> >>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>> [tail call] >>>> In a non-void function its a return statement whose expression is a >>>> function call. >>> >>> So, this is not a tail call? >>> >>> return i > 0 ? f() : g(); >>> >>> After all, the expression of this return is not a function call! >> >> I'd say no, simply because it does not meet my definition. A definition >> like this is given for a purpose, and without one it's hard to say how >> good or how bad a definition it is. But if the purpose were to allow a >> future C standard to say "tail calls will be optimised" there would be >> some merit in making the definition syntactically simple. >> >> You could make it more fiddly by using C's sequence points (or the new >> terminology about sequencing) to include cases like yours and also >> >> return ..., g(); >> return f() || g(); >> return f() && g(); > > In those last two cases, the function must do something with the return > value before returning itself. I think that fact would inhibit tail-call > optimization. I think that depends on other optimisations and on the type of g. The call to f() is obvisouly not a tail call and I intended to change it to ... as I did in the first line, but I forgot. You are taking in abstract -- what might be "the last thing the function does" -- and this is bound to get tied up in details. What matters for programmers is that the language define the cases, which is why I picked the simple definition I did. Taking your correction (that an explicit return is not needed in a void function), I'd still go with what I first said. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-07-18 10:29 -0400 |
| Message-ID | <4ptqx.109543$K%5.84238@fx22.iad> |
| In reply to | #65850 |
On 7/18/15 9:58 AM, James Kuyper wrote:
> On 07/18/2015 09:26 AM, Ben Bacarisse wrote:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> [tail call]
>>>> In a non-void function its a return statement whose expression is a
>>>> function call.
>>>
>>> So, this is not a tail call?
>>>
>>> return i > 0 ? f() : g();
>>>
>>> After all, the expression of this return is not a function call!
>>
>> I'd say no, simply because it does not meet my definition. A definition
>> like this is given for a purpose, and without one it's hard to say how
>> good or how bad a definition it is. But if the purpose were to allow a
>> future C standard to say "tail calls will be optimised" there would be
>> some merit in making the definition syntactically simple.
>>
>> You could make it more fiddly by using C's sequence points (or the new
>> terminology about sequencing) to include cases like yours and also
>>
>> return ..., g();
>> return f() || g();
>> return f() && g();
>
> In those last two cases, the function must do something with the return
> value before returning itself. I think that fact would inhibit tail-call
> optimization.
>
The first needs to do nothing if g() returns the same type as the
current function (or is the current function).
The last two, if g() return bool, and the current function returns bool,
then the result of g() can be directly returned. Note that the
definition of the short circuit binary operator makes the result of the
expression the value of the last evaluated term converted to bool.
For example, the second expression could be directly converted to:
if (f()) {
return true;
}
else if (g()) {
return true;
} else return false;
which could be optimized to
if (f()) {
return true;
}
else return (bool)g();
and if g already returns a bool, the cast is redundant.
Note, this does say that a function that might have had one return point
now has two return points (one which might be reduced to a tail call).
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-07-18 17:32 +0000 |
| Message-ID | <moe2je$ro$1@speranza.aioe.org> |
| In reply to | #65850 |
James Kuyper <jameskuyper@verizon.net> wrote: > On 07/18/2015 09:26 AM, Ben Bacarisse wrote: (snip regarding tail call optimization) >> You could make it more fiddly by using C's sequence points (or the new >> terminology about sequencing) to include cases like yours and also >> return ..., g(); >> return f() || g(); >> return f() && g(); > In those last two cases, the function must do something with the return > value before returning itself. I think that fact would inhibit tail-call > optimization. It does for the first function called, but not for the second (if any). Seems to me that the || case should compile like: if(f()) return 1; return g(); and so is tail recursive on g(), but not f(). -- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-20 15:28 -0700 |
| Message-ID | <kfn8uaalb07.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65859 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> James Kuyper <jameskuyper@verizon.net> wrote:
>> On 07/18/2015 09:26 AM, Ben Bacarisse wrote:
>
> (snip regarding tail call optimization)
>
>>> You could make it more fiddly by using C's sequence points (or the new
>>> terminology about sequencing) to include cases like yours and also
>>>
>>> return ..., g();
>>> return f() || g();
>>> return f() && g();
>>
>> In those last two cases, the function must do something with the return
>> value before returning itself. I think that fact would inhibit tail-call
>> optimization.
>
> It does for the first function called, but not for the second
> (if any).
>
> Seems to me that the || case should compile like:
>
> if(f()) return 1;
> return g();
>
> and so is tail recursive on g(), but not f().
This is wrong because of the semantics in C of the { &&, || }
operators. If f() returns 0 and g() returns 2, then f() || g()
has to produce 1, not 2.
(As I explained in another posting, if g() has _Bool as its
return type, then it is reasonable to treat the call to g() as a
tail call. But that does not hold more generally. Personally I
would like gcc to be better at recognizing functions that could
be optimized in this way, which seems pretty easy in many common
cases, but unfortunately it's still pretty dumb in cases where
the return type is not _Bool.)
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-07-20 22:58 +0000 |
| Message-ID | <mojuff$lg5$1@speranza.aioe.org> |
| In reply to | #66074 |
Tim Rentsch <txr@alumni.caltech.edu> wrote:
(snip regarding tail call optimization)
(snip)
>>>> return ..., g();
>>>> return f() || g();
>>>> return f() && g();
>>> In those last two cases, the function must do something with the return
>>> value before returning itself. I think that fact would inhibit tail-call
>>> optimization.
(snip, then I wrote)
>> It does for the first function called, but not for the second
>> (if any).
>> Seems to me that the || case should compile like:
>> if(f()) return 1;
>> return g();
>> and so is tail recursive on g(), but not f().
> This is wrong because of the semantics in C of the { &&, || }
> operators. If f() returns 0 and g() returns 2, then f() || g()
> has to produce 1, not 2.
I figured this out right after posting, but decided to wait
until there was a reply to say more.
If the compiler knows that the return can only be 0 or 1, then
it can still do the optimization.
> (As I explained in another posting, if g() has _Bool as its
> return type, then it is reasonable to treat the call to g() as a
> tail call. But that does not hold more generally. Personally I
> would like gcc to be better at recognizing functions that could
> be optimized in this way, which seems pretty easy in many common
> cases, but unfortunately it's still pretty dumb in cases where
> the return type is not _Bool.)
Or for self recursion, the compiler might be good enough to remember
that the other returns are only 0 or 1. That might be stretching it
a little, though, but it doesn't seem all that hard for a compiler
to do.
Some time ago, I was doing:
http://practiceit.cs.washington.edu/
which includes some that are required to be recursive. Since
Java has boolean, the problem of 0 or 1 doesn't occur.
Of course, my programs never use values other than 0 or 1 ...
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-23 03:13 -0700 |
| Message-ID | <kfnpp3ji3lz.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66078 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Tim Rentsch <txr@alumni.caltech.edu> wrote:
> (snip regarding tail call optimization)
>
> (snip)
>>>>> return ..., g();
>>>>> return f() || g();
>>>>> return f() && g();
>>>>
>>>> In those last two cases, the function must do something with
>>>> the return value before returning itself. I think that fact
>>>> would inhibit tail-call optimization.
>
> (snip, then I wrote)
>
>>> It does for the first function called, but not for the second
>>> (if any).
>>>
>>> Seems to me that the || case should compile like:
>>>
>>> if(f()) return 1;
>>> return g();
>>>
>>> and so is tail recursive on g(), but not f().
>>
>> This is wrong because of the semantics in C of the { &&, || }
>> operators. If f() returns 0 and g() returns 2, then f() || g()
>> has to produce 1, not 2.
>
> I figured this out right after posting, but decided to wait
> until there was a reply to say more.
>
> If the compiler knows that the return can only be 0 or 1, then
> it can still do the optimization.
Right, but that is a value-based deduction, and still doesn't
make the call to g() a tail call. For example, if we could show
that g() always returned the value 0, then we wouldn't have to
call g() at all (assuming g() has no side effects). In that
case if f() has a _Bool return type then we can optimize the
last expression as just a jump to the start of f.
>> (As I explained in another posting, if g() has _Bool as its
>> return type, then it is reasonable to treat the call to g() as a
>> tail call. But that does not hold more generally. Personally I
>> would like gcc to be better at recognizing functions that could
>> be optimized in this way, which seems pretty easy in many common
>> cases, but unfortunately it's still pretty dumb in cases where
>> the return type is not _Bool.)
>
> Or for self recursion, the compiler might be good enough to
> remember that the other returns are only 0 or 1. That might be
> stretching it a little, though, but it doesn't seem all that hard
> for a compiler to do.
I believe in fact it is almost trivial in essentially all common
cases, which makes it all the more disappointing that it isn't
more widely available.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-18 21:49 +0100 |
| Message-ID | <87wpxx8a2y.fsf@bsb.me.uk> |
| In reply to | #65846 |
ram@zedat.fu-berlin.de (Stefan Ram) writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>ram@zedat.fu-berlin.de (Stefan Ram) writes: >>>Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>>[tail call] >>>>In a non-void function its a return statement whose expression is a >>>>function call. >>> So, this is not a tail call? >>> return i > 0 ? f() : g(); >>> After all, the expression of this return is not a function call! >>I'd say no, simply because it does not meet my definition. A definition >>like this is given for a purpose, and without one it's hard to say how >>good or how bad a definition it is. > > As the designation »TCO« (»tail-call optimization«) says, the purpose > often is optimization. It would be improvable if there is a construct > (»?:«) that is ready for TCO but not optimized due to a definition. > Moreover, in all languages where TCO /is/ defined, the case »?:« /is/ > part of the definition of a tail-call. So, your definition also would > be harder to learn for those who already know the term from other > languages. Yes, I agree. How would you word it for C? Would you just include some particular cases or would you try for something more general? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-20 15:12 -0700 |
| Message-ID | <kfnd1zmlbqu.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65863 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> [tail call]
>>>>> In a non-void function its a return statement whose expression
>>>>> is a function call.
>>>>
>>>> So, this is not a tail call?
>>>> return i > 0 ? f() : g();
>>>> After all, the expression of this return is not a function
>>>> call!
>>>
>>> I'd say no, simply because it does not meet my definition. A
>>> definition like this is given for a purpose, and without one it's
>>> hard to say how good or how bad a definition it is.
>>
>> As the designation >>TCO<< (>>tail-call optimization<<) says, the
>> purpose often is optimization. It would be improvable if there
>> is a construct (>>?:<<) that is ready for TCO but not optimized
>> due to a definition. Moreover, in all languages where TCO /is/
>> defined, the case >>?:<< /is/ part of the definition of a
>> tail-call. So, your definition also would be harder to learn for
>> those who already know the term from other languages.
>
> Yes, I agree. How would you word it for C? Would you just include
> some particular cases or would you try for something more general?
I see my comments on recursion and writing recursive functions
have sparked quite a bit of interest, so much so that it's
hard to know where to start responding. Let me try here.
First I think it is important to distinguish between what is a
tail call and when tail-call optimization might be performed. I
will start with explaining which function calls are tail calls
(and also some that aren't), and then after that go on to talk
about tail-call optimization.
Informally, a function call is a tail call if, after the called
function returns, the calling function doesn't have anything else
to do before the calling function returns. Just slightly more
formally, "something to do" means evaluating a further operation,
where the further operation either combines with the result of
the called function or operates on other independent values. In
cases where the called function is a subexpression of a larger
expression, in cases where the result of the function is the
result of the expression as a whole (ie, without change), that
function call is a tail call, whereas otherwise it is not. Thus
a function call that forms the entire operand of (the selected
arm of) a ?: operator, or of a comma operator, (and is not
otherwise changed for some other reason, explained further below)
is a tail call in cases where the operation in question is the
top-level operation of the ultimate expression evaluated by the
calling function.
To be specific about the case of void functions, a call to a void
function, from a calling function that is itself a void function,
is a tail call if no further operations are evaluated in the
sense described above. So obviously a function call that is an
entire expression statement just before the close brace of a
function definition is a tail call (to emphasize, for void
functions). Perhaps less obviously, a function call that occurs
in a place where subsequent control flow leads unconditionally
to that point is also a tail call. This includes cases like
void
foo_bas_or_bar(){
if( foo ) bar();
else bas();
}
and
void
foo_bas_or_bar(){
if( foo ){
bar();
goto DONE;
}
bas();
DONE: ;
}
the calls to bar() and bas() are tail calls in both cases even
though not syntactically at the end of the calling function, as
no further operations are performed before the calling function
returns. (Obviously a 'return;' statement could be used instead
of 'goto DONE;' in that example - I don't think such things need
explaining.)
Now, how about this case:
void
sample_void_function(){
printf( "okay, it got here.\n" );
}
Is this a tail call or not? Technically it is not: a call to
printf() returns an int value, and there is an implicit
conversion to (void) type as part of the semantics of expression
statements. However if the conversion to (void) type can be
done by "doing nothing" (which I think it commonly the case),
then I think it's understandable to say that even though this
case is techncally not a tail call we can think of it as such
without being too confused.
(Note by the way that in C++ which calls count as tail calls
are different than in C, because of the semantics of destructors
having to run just before the calling function returns.)
For non-void functions - and to be clear we are talking about
both the calling function and the called function - the value
returned by the called function must supply the entire result
that the calling function returns, without further operations
or changes, using the same model described above for operations
like ?: and the comma operator. Thus in a statement like
return something ? foo() : bas();
both the call to foo() and the call to bas() are tail calls (as
clarified below). Similarly in a statement like
return foo(), bas(), bar();
the calls to foo() and bas() are not tail calls, but the call to
bar() is, as the result of bar() forms the entire value of the
expression in the return statement.
I should explain that the descriptions given immediately above
are not quite right. The reason for this is that in some cases
the value of a function call must undergo type conversion before
it is passed along as the return value of the calling function.
Consider again the return statement
return something ? foo() : bas();
Suppose foo() has a return type of signed int, but bas() has a
return type of unsigned int. The rules in C for type conversion
imply that the value returned by foo() must be converted from
(signed) to (unsigned). This conversion counts as a further
operation, so technically the call to foo() is not a tail call
in this case. In implementations that use two's complement the
conversion can be accomplished by "doing nothing", so I hope it
isn't confusing to say we might think of the call to foo() the
same as a tail call (on those implementations) even though
technically it isn't. And now here is another wrinkle. To be
complete the criteria for being a tail call need to take into
account the result type also of the calling function. So if the
return statement above (with the result types of foo() and bas()
as before) were in a function definition like this:
double
foo_or_bas(){
return something ? foo() : bas();
}
then /neither/ foo() nor bas() counts as a tail call, because
the value of the overall expression needs to be converted to
(double) before it can be returned. It is as if we had written
double
foo_or_bas(){
return (double) (something ? foo() : bas());
}
which I think makes it obvious that the function calls are not
tail calls in such cases.
Turning to the question of optimization, why are tail calls
important? The important observation is that, at a basic
machine level (and assuming calls done through a call stack) a
stacking-call immediately followed by a stacking-return is
equivalent to an unconditional jump. Thus the instruction
sequence (in a perhaps-familiar-but-still-hypothetical assembly
language)
PUSHJ FOO
POPJ
can be replaced by a single instruction
BR FOO
because when FOO returns it will just return to this function's
caller, which is just what the calling function would do.
In C the same basic idea applies, but it's more complicated
because there is local stack space to consider, argument
passing, etc. Also as was noted elsethread there are cases
where tail calls in C cannot be optimized because the stack
space cannot be simply thrown away. Furthermore there may be
situations where function definitions that don't have tail calls
get transformed into a form that does as a result of
optimization. So tail-call optimization can take place even
in some cases when the original function definition doesn't
have any tail calls. Here is a kind of dumb but simple
example:
void
something(){
... some elaborate code here, with conditional returns ...
something();
3+4;
}
The call to something() is not a tail call, because the final
expression statement '3+4;' needs to be evaulated afterwards.
But once the optimizer eliminates '3+4;' because it doesn't do
anything useful, what is left looks like a tail call. So we
might expect that the code here would be optmized so that the
final call to something() is accomplished by a branch rather
than a call instruction.
Given all the above, how do you know? Pragmatically this
question has a simple answer - ask the compiler to produce
generated assembly, and look for call instructions (ie, to
the function or functions in question). If there aren't
any, then the tail-call-like optimizations were successful,
and otherwise they were not (at least not completely). It is
hard to give a formal characterization (for C) of just which
function calls may successfuly be transformed using tail-call
optimization. In practice though that isn't necessary; after
some experience one starts to get a feel for which cases will
work and which ones will not. Also it's worth keeping in mind
differences between what is (or is not) technically a tail call
and what is likely to look like (or not look like) a tail call
to an optimizing compiler. An example brought up is the
short-circuiting boolean operators && and ||. Technically
function calls as operands of these operators are not tail
calls. However, if the return type of a function called in
the right side of && or || is type _Bool, then the value
returned by the called function can be returned unchanged by
the calling function (assuming no non-trivial conversion needs
to be done, obviously). So when the return type of the called
function is _Bool such cases look like tail calls even though
technically they are not. With this in mind I tried a simple
experiment, namely, compiling this function:
int
is_prime_tr( unsigned n, unsigned i ){
return
i+7 > n/(i+7) ||
n % (i+ 7) == 0 &&
n % (i+11) == 0 &&
n % (i+13) == 0 &&
n % (i+17) == 0 &&
n % (i+19) == 0 &&
n % (i+23) == 0 &&
n % (i+29) == 0 &&
n % (i+31) == 0 &&
is_prime_tr( n, i+30 );
}
Sure enough, the final call to is_prime_tr() was not optimized
into a loop. However, changing the return type to _Bool
_Bool
is_prime_tr( unsigned n, unsigned i ){
return
i+7 > n/(i+7) ||
n % (i+ 7) == 0 &&
n % (i+11) == 0 &&
n % (i+13) == 0 &&
n % (i+17) == 0 &&
n % (i+19) == 0 &&
n % (i+23) == 0 &&
n % (i+29) == 0 &&
n % (i+31) == 0 &&
is_prime_tr( n, i+30 );
}
did indeed result (done using gcc -O2) in a nice simple loop,
without any call instructions, in the generated assembly.
Does that all make sense to everyone?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <nospam@nospam.nospam> |
|---|---|
| Date | 2015-07-20 15:21 -0700 |
| Message-ID | <mojsa9$hpc$1@speranza.aioe.org> |
| In reply to | #66070 |
> "Tim Rentsch" wrote in message > news:kfnd1zmlbqu.fsf@x-alumni2.alumni.caltech.edu... [...] > Perhaps less obviously, a function call that occurs > in a place where subsequent control flow leads unconditionally > to that point is also a tail call. This includes cases like [...] I am wondering if the following recursive function can be optimized with tail calls? Its JavaScript but to many recursion levels goes really slow. https://groups.google.com/d/topic/comp.lang.javascript/Moi3xdOtofo/discussion Goto this link: http://preview.tinyurl.com/m7hp2c7 (settings for a von Koch in my circle intersection fractal) Goto the site. Click render in the upper left hand corner. See von Koch. ;^)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <nospam@nospam.nospam> |
|---|---|
| Date | 2015-07-20 15:23 -0700 |
| Message-ID | <mojscp$hrh$1@speranza.aioe.org> |
| In reply to | #66072 |
> "Chris M. Thomasson" wrote in message
> news:mojsa9$hpc$1@speranza.aioe.org...
> > "Tim Rentsch" wrote in message
> > news:kfnd1zmlbqu.fsf@x-alumni2.alumni.caltech.edu...
[...]
> > Perhaps less obviously, a function call that occurs
> > in a place where subsequent control flow leads unconditionally
> > to that point is also a tail call. This includes cases like
[...]
> I am wondering if the following recursive function can be optimized with
> tail calls?
This one:
_____________________________________________________________
// Recursivally build the fractal...
function ttr_recurse(i, gctx, c0, c1)
{
if (i > g_I_MAX) return;
var i0 = new ttr_circle(0, 0, 0);
var i1 = new ttr_circle(0, 0, 0);
if (! intersect_circle(c0, c1, i0, i1)) return;
var R = i0.m_r;
if (! (g_html_sqrt_f & 1))
{
R = Math.sqrt(R);
}
i0.m_r = R * g_RATIO;
i1.m_r = R * g_RATIO;
render_circles(gctx, i0, i1);
if (g_SYM & 0x1) ttr_recurse(i + 1, gctx, c0, i0); // 0
if (g_SYM & 0x2) ttr_recurse(i + 1, gctx, c1, i1); // 1
if (g_SYM & 0x4) ttr_recurse(i + 1, gctx, c0, i1); // 2
if (g_SYM & 0x8) ttr_recurse(i + 1, gctx, c1, i0); // 3
// alternate setup...
if (g_SYM & 0x10) ttr_recurse(i + 1, gctx, i0, c0); // 0a 16
if (g_SYM & 0x20) ttr_recurse(i + 1, gctx, i1, c1); // 1a 32
if (g_SYM & 0x40) ttr_recurse(i + 1, gctx, i1, c0); // 2a 64
if (g_SYM & 0x80) ttr_recurse(i + 1, gctx, i0, c1); // 3a 128
}
_____________________________________________________________
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-23 03:46 -0700 |
| Message-ID | <kfnd1zji22n.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66073 |
"Chris M. Thomasson" <nospam@nospam.nospam> writes:
>> "Chris M. Thomasson" wrote in message
>> news:mojsa9$hpc$1@speranza.aioe.org...
>>
>>> "Tim Rentsch" wrote in message >
>>
>> news:kfnd1zmlbqu.fsf@x-alumni2.alumni.caltech.edu...
>
> [...]
>
>>> Perhaps less obviously, a function call that occurs
>>> in a place where subsequent control flow leads unconditionally
>>> to that point is also a tail call. This includes cases like
>
> [...]
>
>> I am wondering if the following recursive function can be optimized
>> with tail calls?
>
> This one:
> _____________________________________________________________
>
> // Recursivally build the fractal...
> function ttr_recurse(i, gctx, c0, c1)
> {
> if (i > g_I_MAX) return;
>
> var i0 = new ttr_circle(0, 0, 0);
> var i1 = new ttr_circle(0, 0, 0);
>
> if (! intersect_circle(c0, c1, i0, i1)) return;
>
> var R = i0.m_r;
>
> if (! (g_html_sqrt_f & 1))
> {
> R = Math.sqrt(R);
> }
>
> i0.m_r = R * g_RATIO;
> i1.m_r = R * g_RATIO;
>
> render_circles(gctx, i0, i1);
>
> if (g_SYM & 0x1) ttr_recurse(i + 1, gctx, c0, i0); // 0
> if (g_SYM & 0x2) ttr_recurse(i + 1, gctx, c1, i1); // 1
> if (g_SYM & 0x4) ttr_recurse(i + 1, gctx, c0, i1); // 2
> if (g_SYM & 0x8) ttr_recurse(i + 1, gctx, c1, i0); // 3
>
> // alternate setup...
> if (g_SYM & 0x10) ttr_recurse(i + 1, gctx, i0, c0); // 0a 16
> if (g_SYM & 0x20) ttr_recurse(i + 1, gctx, i1, c1); // 1a 32
> if (g_SYM & 0x40) ttr_recurse(i + 1, gctx, i1, c0); // 2a 64
> if (g_SYM & 0x80) ttr_recurse(i + 1, gctx, i0, c1); // 3a 128
> }
> _____________________________________________________________
Generally functions like this one, with multiple self-recursive
calls, are not especially amenable to tail recursion.
It looks like the recursion that's here is well-behaved. In
particular, although the function recurses a lot, it never
goes very deep (ie, based on guessing that g_I_MAX is never
more than, say, 50). So probably the recursion itself isn't
hurting too much; probably most of the cost comes just from
doing other computation, and not from recursing.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-23 03:31 -0700 |
| Message-ID | <kfnh9ovi2qu.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66072 |
"Chris M. Thomasson" <nospam@nospam.nospam> writes: >> "Tim Rentsch" wrote in message >> news:kfnd1zmlbqu.fsf@x-alumni2.alumni.caltech.edu... > > [...] > >> Perhaps less obviously, a function call that occurs >> in a place where subsequent control flow leads unconditionally >> to that point is also a tail call. This includes cases like > > [...] > > I am wondering if the following recursive function can be optimized > with tail calls? > > Its JavaScript but to many recursion levels goes really slow. > > https://groups.google.com/d/topic/comp.lang.javascript/Moi3xdOtofo/discussion I have basically given up on google groups. :/ It looks like you posted a followup with the actual code, I will look at that now.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-21 04:08 -0700 |
| Message-ID | <kfnfv4hkbt8.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65668 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, July 15, 2015 at 10:34:47 PM UTC+1, Tim Rentsch wrote:
>> Bartc <bc@freeuk.com> writes:
>>
>>> On 11/07/2015 14:36, Tim Rentsch wrote:
>>>
>>> (I tried this code as an example of something that invites you
>>> to express it recursively, but is really iterative. It ran
>>> under gcc -O3 but crashed with gcc -O0, when given a
>>> million-char string:
>>>
>>> int my_strlen(char* s){
>>> if (*s==0)
>>> return 0;
>>> else
>>> return 1+my_strlen(s+1);
>>> }
>>>
>>> Maybe Ocaml encourages this sort of approach.)
>>
>> This is not an example of tail recursion (and is not encouraged
>> in OCaml for just that reason). AFAIK this result is some sort
>> of special casing in gcc; the function definition is not a good
>> illustration of well-behaved recursion constructs.
>
> Bart's an experienced programmer and a compiler write.
> But he's got it wrong.
Bart didn't get anything wrong. What he said was he tried the
code "as an example of something that invites you to express it
recursively, but is really iterative." And there is nothing
wrong with that statement. Note that he didn't say anything
about whether the function uses tail recursion or not; it
isn't that he was confused about what tail recursion is, it's
that he doesn't (or didn't) know what it is. Ignorance is
not the same as misunderstanding.
> int my_strlen(char *s)
> {
> int answer = 0;
> start:
> if(*s == 0)
> return answer;
> answer++;
> s++;
> goto start;
> }
>
> The recursion removal reveals the problem. As far as I
> can tell. I must admit that I wouldn't have realised that
> the function as written wasn't tail recursive, either.
I spent some time reading through your many postings in
this thread, trying to figure out what to respond to and
how. What I finally decided was to respond here and not
to any of the others.
To start with, you are confused about functional programming,
both what it is and how to do it. The examples and explanations
you give are either wrong or nonsensical. In one posting you
said "It's not that I know nothing.' The problem isn't with
how much you know; the problem is that how much you know is
a lot more than how much you understand. You may have done
some programming in functional languages, but you haven't yet
gotten the functional paradigm. Because of these things you
aren't in position to explain these ideas to other people,
let alone make pronouncements about the efficacy of functional
programming or how suited it is to typical programmers (or
vice versa). Stop trying to act like an expert - you aren't
one (to be specific, in the area of functional programming,
which is the only area I'm considering for these comments).
If you want to try to become an expert, a good way to do that is
to spend a fair amount of time writing in a good functional
language, restricting yourself to the non-imperative parts of the
language. (There is an obvious exception for doing I/O.) I
would recommend against using Lisp, not that Lisp is a bad
language but it isn't a good language for doing pure functional
programming. I guess my top two recommendations are Haskell or
OCaml, both of these having strict typing and good type
inference. Get to the point where writing functions, and
eventually entire programs, using a pure functional style gets to
be natural and automatic. Explore and develop an understanding
for the different ways that functions may be used as values,
including functionals (functions whose sole purpose is to operate
on other functions). When you get to the point where you are
naturally writing in a pure functional style, try learning about
and practicing CPS, aka continuation passing style. If you go
down this path, I think eventually you will get to a point where
iterating seems cumbersome, and you will seek out higher level
intellectual tools for getting things done. It is at that point
that one starts to get an appreciation for the power of
functional programming.
For what it's worth, what I've described is approximately the
experience I had myself with functional programming, more than
thirty years after I started programming. And that earlier
experience included time programming in Lisp and several other
functional languages. It wasn't until I really immersed myself
in "the other way" of doing things that I really started to get
it.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-11 08:50 -0700 |
| Message-ID | <kfna8v2y9qq.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #64979 |
"Morten W. Petersen" <morphex@gmail.com> writes: > 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? Your programming has deeper issues than worrying about threading, recursion and/or iteration. For starters, you should get rid of the fixation on low-level performance issues.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-11 18:43 +0200 |
| Message-ID | <mnrh12$hap$1@speranza.aioe.org> |
| In reply to | #65298 |
On 11.07.2015 17:50, Tim Rentsch wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: > >> 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? > > Your programming has deeper issues than worrying about > threading, recursion and/or iteration. For starters, > you should get rid of the fixation on low-level performance > issues. Maybe I'm a bit too focused on optimization now, but I'm kind of taking it as it comes and what I feel like working on. Being readable, secure and correct are also priorities. If you have an SSD that can deliver data at 500 MB/s, and have a CPU that delivers 3 Ghz on 4 cores, and a 10 GB file, doesn't speed (in particular threading) matter? -Morten
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-11 18:54 +0200 |
| Message-ID | <mnrhn3$ign$1@speranza.aioe.org> |
| In reply to | #65307 |
On 11.07.2015 18:50, Stefan Ram wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: >> Being readable, secure and correct are also priorities. > > If everything is a priority, nothing is a priority. Well, looping and recursion was discussed earlier on comp.lang.c with regard to speed and resource usage. Out of that came the information that exhausting the stack had unpredictable results and could be a security issue. It's more of an "all roads lead to Rome" I think. :) -Morten
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-11 13:06 -0400 |
| Message-ID | <55A14D15.1060907@verizon.net> |
| In reply to | #65309 |
On 07/11/2015 12:54 PM, Morten W. Petersen wrote: > On 11.07.2015 18:50, Stefan Ram wrote: >> "Morten W. Petersen" <morphex@gmail.com> writes: >>> Being readable, secure and correct are also priorities. >> >> If everything is a priority, nothing is a priority. > > Well, looping and recursion was discussed earlier on comp.lang.c with > regard to speed and resource usage. > > Out of that came the information that exhausting the stack had > unpredictable results and could be a security issue. > > It's more of an "all roads lead to Rome" I think. :) Unfortunately, you're trying to get to Rome via a road that goes to Canberra.
[toc] | [prev] | [next] | [standalone]
Page 14 of 15 — ← Prev page 1 … 12 13 [14] 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web