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 12 of 15 — ← Prev page 1 … 10 11 [12] 13 14 15 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-08-10 21:03 +1200 |
| Message-ID | <d2r7mbFo61lU3@mid.individual.net> |
| In reply to | #67055 |
Malcolm McLean wrote: > > The the trivial data reformatting is grandiously named "proper > abstractions and thinking". Not really. It's just a recognition that > essentially the same data may be in different formats. To be fair, > you do sometimes have a taxonomy, but that's rare - sometimes > the real world objects you are modelling are structured with > hierarchical "is a" relationships, but not all that often. More often than you realise. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-10 03:16 -0700 |
| Message-ID | <9803380e-58dd-40f0-bea5-d89c0adbe6a8@googlegroups.com> |
| In reply to | #67056 |
On Monday, August 10, 2015 at 10:03:17 AM UTC+1, Ian Collins wrote: > Malcolm McLean wrote: > > > > The the trivial data reformatting is grandiously named "proper > > abstractions and thinking". Not really. It's just a recognition that > > essentially the same data may be in different formats. To be fair, > > you do sometimes have a taxonomy, but that's rare - sometimes > > the real world objects you are modelling are structured with > > hierarchical "is a" relationships, but not all that often. > > More often than you realise. > I got a C++ compiler almost as soon as the first ones became available for the PC, so of course I've been exposed to the OO mantra for all my professional life. I've seen plenty of object hierarchies in my time. Sometimes I've seen them done well. But only a subset of programming problems naturally falls into an "objects with is-a relationships structuring the interactions" paradigm. If your problem is in that subset, then use OO. But don't try to force type hierarchies where it's not actually tackling the underlying data, and don't confuse the data reformatting problem with the derived type problem.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-10 12:16 +0200 |
| Message-ID | <mq9tl7$vl5$1@speranza.aioe.org> |
| In reply to | #67055 |
On 10.08.2015 10:40, Malcolm McLean wrote:
> On Monday, August 10, 2015 at 4:39:30 AM UTC+1, Morten W. Petersen wrote:
>>
>> Take for example the task of counting the digit 1 in a text.. Now
>> with the most recent version of Python, the internal storage format
>> of a string depends on what characters are used. But this is hidden
>> from the average programmer so that regardless of whether the string
>> contents is English and ASCII characters or Chinese with Chinese
>> characters, calling text.count('1') will do the right thing.
>>
>> With the proper abstractions and thinking, a set of structs and
>> increasingly abstracted functions could do the same as OOP, but I guess
>> the taxonomy-style thinking of OOP is something that comes naturally to
>> a lot of people.
>>
> A lot of high-level languages automate a bit of trivial reformatting
> of data. Such as converting strings between different representations.
>
> However the example actually breaks down in real life. In Arabic,
> there's an Arabic glyph for one, which is used for everyday Arabic
> numbers. But in texts written in Arabic, you also quite often see
> Western numerals being used, particularly for scientific or
> technical data. So if you search for digit '1' what do you actually
> mean?
>
> The the trivial data reformatting is grandiously named "proper
> abstractions and thinking". Not really. It's just a recognition that
> essentially the same data may be in different formats. To be fair,
> you do sometimes have a taxonomy, but that's rare - sometimes
> the real world objects you are modelling are structured with
> hierarchical "is a" relationships, but not all that often.
What kind of shit talk is this? The statement is that with the proper
data structures and abstractions in C, one can get the same effect as
with OOP. And that makes perfect sense.
-Morten
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-10 03:36 -0700 |
| Message-ID | <38607663-f5da-4fca-9e96-88a10fa8e02b@googlegroups.com> |
| In reply to | #67059 |
On Monday, August 10, 2015 at 11:16:18 AM UTC+1, Morten W. Petersen wrote:
> On 10.08.2015 10:40, Malcolm McLean wrote:
> > On Monday, August 10, 2015 at 4:39:30 AM UTC+1, Morten W. Petersen wrote:
> >>
> >> Take for example the task of counting the digit 1 in a text.. Now
> >> with the most recent version of Python, the internal storage format
> >> of a string depends on what characters are used. But this is hidden
> >> from the average programmer so that regardless of whether the string
> >> contents is English and ASCII characters or Chinese with Chinese
> >> characters, calling text.count('1') will do the right thing.
> >>
> >> With the proper abstractions and thinking, a set of structs and
> >> increasingly abstracted functions could do the same as OOP, but I guess
> >> the taxonomy-style thinking of OOP is something that comes naturally to
> >> a lot of people.
> >>
> > A lot of high-level languages automate a bit of trivial reformatting
> > of data. Such as converting strings between different representations.
> >
> > However the example actually breaks down in real life. In Arabic,
> > there's an Arabic glyph for one, which is used for everyday Arabic
> > numbers. But in texts written in Arabic, you also quite often see
> > Western numerals being used, particularly for scientific or
> > technical data. So if you search for digit '1' what do you actually
> > mean?
> >
> > The the trivial data reformatting is grandiously named "proper
> > abstractions and thinking". Not really. It's just a recognition that
> > essentially the same data may be in different formats. To be fair,
> > you do sometimes have a taxonomy, but that's rare - sometimes
> > the real world objects you are modelling are structured with
> > hierarchical "is a" relationships, but not all that often.
>
> What kind of shit talk is this? The statement is that with the proper
> data structures and abstractions in C, one can get the same effect as
> with OOP. And that makes perfect sense.
>
You can do OOP in C. It's a programming paradigm, not a feature of a language.
However if you try to go too far down the OOP path, C syntax becomes
unwieldy. You should move to C++. That's what C++ is for.
However often it's easier and better to do data reformatting than to implement
abstraction.
For example say we want to do a simple statistical test - a Student T-test to
see if two samples are drawn from the same, or different distributions.
Sometimes the data will be real, sometimes it will be integral, often it will be
quantised. But Student's T-test doesn't have any correction term for artificially
quantised data, you've just got to ignore that slight inaccuracy. So a specialisation
for "fixed point" won't really be a specialisation in the statistical sense, it will
just be a wrapper for passing fixed point observations to an algorithm that
takes reals.
So whilst you can set up templates or some sort of 'scalar observation"
class, it's probably easier all round to simply say that the function takes two
arrays of doubles. You put that data into that format, call the T-test, get a
double back, and convert it to whatever makes sense (often 4-valued no star,
one star, two star or three star result to present to the user).
Here "proper abstraction and thinking" just means "automatic avoidance of trivial
data reformatting". And that's a very common situation.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-10 12:45 +0200 |
| Message-ID | <mq9vbt$3t9$1@speranza.aioe.org> |
| In reply to | #67061 |
On 10.08.2015 12:36, Malcolm McLean wrote:
> On Monday, August 10, 2015 at 11:16:18 AM UTC+1, Morten W. Petersen wrote:
>> On 10.08.2015 10:40, Malcolm McLean wrote:
>>> On Monday, August 10, 2015 at 4:39:30 AM UTC+1, Morten W. Petersen wrote:
>>>>
>>>> Take for example the task of counting the digit 1 in a text.. Now
>>>> with the most recent version of Python, the internal storage format
>>>> of a string depends on what characters are used. But this is hidden
>>>> from the average programmer so that regardless of whether the string
>>>> contents is English and ASCII characters or Chinese with Chinese
>>>> characters, calling text.count('1') will do the right thing.
>>>>
>>>> With the proper abstractions and thinking, a set of structs and
>>>> increasingly abstracted functions could do the same as OOP, but I guess
>>>> the taxonomy-style thinking of OOP is something that comes naturally to
>>>> a lot of people.
>>>>
>>> A lot of high-level languages automate a bit of trivial reformatting
>>> of data. Such as converting strings between different representations.
>>>
>>> However the example actually breaks down in real life. In Arabic,
>>> there's an Arabic glyph for one, which is used for everyday Arabic
>>> numbers. But in texts written in Arabic, you also quite often see
>>> Western numerals being used, particularly for scientific or
>>> technical data. So if you search for digit '1' what do you actually
>>> mean?
>>>
>>> The the trivial data reformatting is grandiously named "proper
>>> abstractions and thinking". Not really. It's just a recognition that
>>> essentially the same data may be in different formats. To be fair,
>>> you do sometimes have a taxonomy, but that's rare - sometimes
>>> the real world objects you are modelling are structured with
>>> hierarchical "is a" relationships, but not all that often.
>>
>> What kind of shit talk is this? The statement is that with the proper
>> data structures and abstractions in C, one can get the same effect as
>> with OOP. And that makes perfect sense.
>>
> You can do OOP in C. It's a programming paradigm, not a feature of a language.
> However if you try to go too far down the OOP path, C syntax becomes
> unwieldy. You should move to C++. That's what C++ is for.
OK, that was the point I was making, that C is a low level language
which others can be built on top of.
(C)Python is written in C for example, and illustrates the point that
OOP is done with C, functions and different data structures.
I think it would be a good idea to ask what a poster means before
labeling it as for example grandiose which can be offensive.
-Morten
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-08-22 14:07 +0000 |
| Message-ID | <55d88219.19456546@news.xs4all.nl> |
| In reply to | #67061 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Monday, August 10, 2015 at 11:16:18 AM UTC+1, Morten W. Petersen wrote: > > What kind of shit talk is this? The statement is that with the proper > > data structures and abstractions in C, one can get the same effect as > > with OOP. And that makes perfect sense. > > > You can do OOP in C. It's a programming paradigm, not a feature of a language. > However if you try to go too far down the OOP path, C syntax becomes > unwieldy. You should move to C++. That's what C++ is for. Ish. It's certainly what Objective-C is for. Richard
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-08-22 14:07 +0000 |
| Message-ID | <55d87c55.17979687@news.xs4all.nl> |
| In reply to | #67041 |
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > raltbos@xs4all.nl (Richard Bos) writes: > > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > > > >> Functional programming is often called "declarative programming", and > >> that style does occur in real life -- all the time in fact. The > >> "declarative" answer to the problem "what is the EU flag" is "twelve > >> gold stars in a ring on top of a 3 by 2 blue rectangle": > >> > >> euFlag = stars 12 `atop` rect 3 2 # fc blue # lw none > > When you ask for the process of how to _make_ an EU flag, you get a lot > > closer to imperative style programming: > > - take a piece of cloth 1.5 times as wide as high; > > - paint this cloth aquamarine blue; > > - take twenty-four yellow, five-pointed stars of size x; > > - lightly mark a circle on the flag, 2/3 the height of the flag; > > - mark twelve points on the flag, situated equidistantly along this > > circle, starting at the top; > > - sew two stars to each point, one in front, one in back; > > - erase the circle. > > Yes, of course. But the point I was responding to was that a functional > style is not used in real life. I think it very often is. I'll grant that it is - but not that it is used in similar circumstances as a computer program is. Functional-style instructions in real life are, IME, usually like computer _data_ (stylesheets, for example), not like computer _code_. > >> You can get the same sort of answer about recipes if you ask the > >> right questions. What is a your favourite fish pie? It's smoked > >> haddock, cod and prawns cooked with onion, garlic, tomatoes and capers > >> with a grilled mashed potato topping. > > > > Again, that's a description of the pie, _not_ a recipe. > > Only because of your (correct but modern) definition. Old recipes were > often exactly like the one above. Erm. Gourdes in Potage Take young Gowrdes, pare hem and kerve hem on pecys. Cast hem in gode broth, and do ther to a gode pertye of Onyouns mynced. Take Pork soden, grynd it and alye it ther with and with yolkes of ayren. Do ther to safroun and salt, and messe it forth with powdour douce. From the 15th century. If anything, it's _more_ imperative and _less_ declarative, since it doesn't even tell you how many gourds, broth, onions, pork, egg-yolks and spices to take, only what to do with them: it's like the code without even the initialisation of the data! Richard
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-19 02:47 -0700 |
| Message-ID | <67040e58-9bde-4ad4-835f-b870f50bf90d@googlegroups.com> |
| In reply to | #65887 |
On Sunday, July 19, 2015 at 9:15:09 AM UTC+1, robert...@yahoo.com wrote: > On Sat, 18 Jul 2015 14:28:25 -0700 (PDT), Malcolm McLean > <malcolm.mclean5@btinternet.com> wrote: > > >And certainly I think it's time to admit that this stuff is too > >complicated for the general programmer > > > I certainly disagree. Functional programming is sufficiently > different from more imperative models that there's a quite steep > learning curve if all you know is on the imperative side of the world. > Functional programming isn't new. Lisp has been around since before even C. It never really caught on, and you can argue about the reasons for that, but on the face of it, the functional paradigm seems to be a major factor. Javascript has had some functional programming constructs added, though it's still essentially in the C family of languages. That seems to have been the spark that reignited interest. The other factor is the failure of OOP - the consensus is coming round that we on comp.lang.c were right all along, whilst few people here are anti-C++ (my favourite example of a good C++ interface is the plugin system for 3D Studio max), the newsgroup is predicated on the idea that C++ shouldn't be used in many situations. So functional programming is the next fad.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-19 22:23 +1200 |
| Message-ID | <d11c5qF9itpU1@mid.individual.net> |
| In reply to | #65889 |
Malcolm McLean wrote: > > Javascript has had some functional programming constructs added, > though it's still essentially in the C family of languages. That seems to > have been the spark that reignited interest. The other factor is the > failure of OOP - the consensus is coming round that we on comp.lang.c > were right all along, whilst few people here are anti-C++... People were writing good OO C long before C++ came along. There is nothing inherently long with OOP, it is a good fit for many problems. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-19 05:01 -0700 |
| Message-ID | <f96ecb2c-dac7-48a1-b04a-b88b3eeaa7da@googlegroups.com> |
| In reply to | #65890 |
On Sunday, July 19, 2015 at 11:24:09 AM UTC+1, Ian Collins wrote: > Malcolm McLean wrote: > > > > Javascript has had some functional programming constructs added, > > though it's still essentially in the C family of languages. That seems to > > have been the spark that reignited interest. The other factor is the > > failure of OOP - the consensus is coming round that we on comp.lang.c > > were right all along, whilst few people here are anti-C++... > > People were writing good OO C long before C++ came along. There is > nothing inherently long with OOP, it is a good fit for many problems. > I agree with what you mean, but not with what you literally said. There is something inherently wrong with OOP, which is that the interfaces are too complex, the interdependencies too intricate, and the programs as a result brittle.However that doesn't always matter, and it can be overcome with care. In the case of 3DS Max, the code has to interface to the 3DS Max concept of a 3D model. An "object" maps very intuitively to what the user thinks of as an "object" in the world he is creating. And the code will never be ported to any other environment, it's designed to manipulate that particular model. So enthuse circumstances OOP works well. Similarly with GUIs, they've got the same characteristics - an "object" has an intuitive meaning, and the code is usually very dependent on the particular application and the particular GUI library, it's not meant to be portable or reusable. If you need robust code that won't break, it's far better to write it in C.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-20 09:55 +1200 |
| Message-ID | <d12kn1F9itpU2@mid.individual.net> |
| In reply to | #65893 |
Malcolm McLean wrote: > On Sunday, July 19, 2015 at 11:24:09 AM UTC+1, Ian Collins wrote: >> Malcolm McLean wrote: >>> >>> Javascript has had some functional programming constructs added, >>> though it's still essentially in the C family of languages. That seems to >>> have been the spark that reignited interest. The other factor is the >>> failure of OOP - the consensus is coming round that we on comp.lang.c >>> were right all along, whilst few people here are anti-C++... >> >> People were writing good OO C long before C++ came along. There is >> nothing inherently long with OOP, it is a good fit for many problems. >> > I agree with what you mean, but not with what you literally said. > There is something inherently wrong with OOP, which is that the interfaces are > too complex, the interdependencies too intricate, and the programs as a result > brittle.However that doesn't always matter, and it can be overcome with > care. From where do you draw that conclusion? Why should an OO solution to a problem have complex interfaces? > In the case of 3DS Max, the code has to interface to the 3DS Max concept of > a 3D model. An "object" maps very intuitively to what the user thinks of as > an "object" in the world he is creating. And the code will never be ported to > any other environment, it's designed to manipulate that particular model. > So enthuse circumstances OOP works well. Similarly with GUIs, they've got the > same characteristics - an "object" has an intuitive meaning, and the code is > usually very dependent on the particular application and the particular GUI > library, it's not meant to be portable or reusable. KDE anyone? > If you need robust code that won't break, it's far better to write it in C. Says who? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-19 23:13 +0100 |
| Message-ID | <moh7b8$ett$1@dont-email.me> |
| In reply to | #65934 |
On 19/07/2015 22:55, Ian Collins wrote: > Malcolm McLean wrote: >> On Sunday, July 19, 2015 at 11:24:09 AM UTC+1, Ian Collins wrote: >>> People were writing good OO C long before C++ came along. There is >>> nothing inherently long with OOP, it is a good fit for many problems. >>> >> I agree with what you mean, but not with what you literally said. >> There is something inherently wrong with OOP, which is that the >> interfaces are >> too complex, the interdependencies too intricate, and the programs as >> a result >> brittle.However that doesn't always matter, and it can be overcome with >> care. > > From where do you draw that conclusion? Why should an OO solution to a > problem have complex interfaces? It just does. You find out how complex when trying to use the interface from a non-OO language. From C for example, but people using DIY languages have it tougher - just trying to make use of a complex C library is bad enough. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-20 10:19 +1200 |
| Message-ID | <d12m42F9itpU3@mid.individual.net> |
| In reply to | #65939 |
Bartc wrote: > On 19/07/2015 22:55, Ian Collins wrote: >> Malcolm McLean wrote: >>> On Sunday, July 19, 2015 at 11:24:09 AM UTC+1, Ian Collins wrote: > >>>> People were writing good OO C long before C++ came along. There is >>>> nothing inherently long with OOP, it is a good fit for many problems. >>>> >>> I agree with what you mean, but not with what you literally said. >>> There is something inherently wrong with OOP, which is that the >>> interfaces are >>> too complex, the interdependencies too intricate, and the programs as >>> a result >>> brittle.However that doesn't always matter, and it can be overcome with >>> care. >> >> From where do you draw that conclusion? Why should an OO solution to a >> problem have complex interfaces? > > It just does. Where is your evidence? I first learned OO working with the excellent XView GUI toolkit and one of the things that stood out with XView was the simplicity of its interface, especially when compared to its contemporaries. > You find out how complex when trying to use the interface > from a non-OO language. From C for example, but people using DIY > languages have it tougher - just trying to make use of a complex C > library is bad enough. XView was 100% C. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-07-19 17:21 -0500 |
| Message-ID | <ad8oqadsi419j450uqaacrm0cv9bi0u129@4ax.com> |
| In reply to | #65939 |
On Sun, 19 Jul 2015 23:13:22 +0100, Bartc <bc@freeuk.com> wrote: >On 19/07/2015 22:55, Ian Collins wrote: >> Malcolm McLean wrote: >>> On Sunday, July 19, 2015 at 11:24:09 AM UTC+1, Ian Collins wrote: > >>>> People were writing good OO C long before C++ came along. There is >>>> nothing inherently long with OOP, it is a good fit for many problems. >>>> >>> I agree with what you mean, but not with what you literally said. >>> There is something inherently wrong with OOP, which is that the >>> interfaces are >>> too complex, the interdependencies too intricate, and the programs as >>> a result >>> brittle.However that doesn't always matter, and it can be overcome with >>> care. >> >> From where do you draw that conclusion? Why should an OO solution to a >> problem have complex interfaces? > >It just does. You find out how complex when trying to use the interface >from a non-OO language. From C for example, but people using DIY >languages have it tougher - just trying to make use of a complex C >library is bad enough. That's a pretty silly reason. Two languages that *don't* share enough common philosophy are going to be a clumsy to interface no matter what. Try passing a typical Cobol "01" structure definition to a C program some time, and tell me how easy it is to deal with (although you'll actually discover a use case for strncpy).
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-20 00:25 +0100 |
| Message-ID | <mohbi3$r13$1@dont-email.me> |
| In reply to | #65941 |
On 19/07/2015 23:21, Robert Wessel wrote: > On Sun, 19 Jul 2015 23:13:22 +0100, Bartc <bc@freeuk.com> wrote: > >> On 19/07/2015 22:55, Ian Collins wrote: >>> From where do you draw that conclusion? Why should an OO solution to a >>> problem have complex interfaces? >> >> It just does. You find out how complex when trying to use the interface >>from a non-OO language. From C for example, but people using DIY >> languages have it tougher - just trying to make use of a complex C >> library is bad enough. > > > That's a pretty silly reason. Two languages that *don't* share enough > common philosophy are going to be a clumsy to interface no matter > what. Try passing a typical Cobol "01" structure definition to a C > program some time, and tell me how easy it is to deal with (although > you'll actually discover a use case for strncpy). That sounds easy: I assume a Cobol struct is just a number of fixed length alphanumeric fields. You can quickly get to the low-level binary information that is needed. Similarly with C: it is possible to follow typedefs and macros to the underlying primitive type (although you might have execute some tests to find the actual size of an int or long!). Sometimes the docs will help. With C++ with the extra layers of abstraction that are possible, it's not really practical unless the interface is really a C one but called C++ (as happens with MS' old Win32 libraries, but the newer ones use hard-core C++). There are ways to use such libraries, involving creating an extra buffer layer with a simple-to-use Bart-friendly interface on one side, and which talks to the complex C++ API on the other. (But even that won't work with some complex libraries such as those from MS - I could never work with COM for example since I simply haven't got a clue where to start (or what it is or whether I need to use it at all!). To take an API, I do need to understand what it can do.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-20 11:45 +1200 |
| Message-ID | <d12r4kF9itpU4@mid.individual.net> |
| In reply to | #65942 |
Bartc wrote: > On 19/07/2015 23:21, Robert Wessel wrote: >> On Sun, 19 Jul 2015 23:13:22 +0100, Bartc <bc@freeuk.com> wrote: >> >>> On 19/07/2015 22:55, Ian Collins wrote: > >>>> From where do you draw that conclusion? Why should an OO solution to a >>>> problem have complex interfaces? >>> >>> It just does. You find out how complex when trying to use the interface >> >from a non-OO language. From C for example, but people using DIY >>> languages have it tougher - just trying to make use of a complex C >>> library is bad enough. >> >> >> That's a pretty silly reason. Two languages that *don't* share enough >> common philosophy are going to be a clumsy to interface no matter >> what. Try passing a typical Cobol "01" structure definition to a C >> program some time, and tell me how easy it is to deal with (although >> you'll actually discover a use case for strncpy). > > That sounds easy: I assume a Cobol struct is just a number of fixed > length alphanumeric fields. You can quickly get to the low-level binary > information that is needed. > > Similarly with C: it is possible to follow typedefs and macros to the > underlying primitive type (although you might have execute some tests to > find the actual size of an int or long!). Sometimes the docs will help. > > With C++ with the extra layers of abstraction that are possible, it's > not really practical unless the interface is really a C one but called > C++ (as happens with MS' old Win32 libraries, but the newer ones use > hard-core C++). If you read up the thread, you will see the discussion was about whether an OO solution is necessarily too complex. This applies just as much to C as C++. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-07-20 02:34 -0500 |
| Message-ID | <jg7pqatouhldjrpkacej2gprrbt0t4nv2j@4ax.com> |
| In reply to | #65942 |
On Mon, 20 Jul 2015 00:25:17 +0100, Bartc <bc@freeuk.com> wrote: >On 19/07/2015 23:21, Robert Wessel wrote: >> On Sun, 19 Jul 2015 23:13:22 +0100, Bartc <bc@freeuk.com> wrote: >> >>> On 19/07/2015 22:55, Ian Collins wrote: > >>>> From where do you draw that conclusion? Why should an OO solution to a >>>> problem have complex interfaces? >>> >>> It just does. You find out how complex when trying to use the interface >>>from a non-OO language. From C for example, but people using DIY >>> languages have it tougher - just trying to make use of a complex C >>> library is bad enough. >> >> >> That's a pretty silly reason. Two languages that *don't* share enough >> common philosophy are going to be a clumsy to interface no matter >> what. Try passing a typical Cobol "01" structure definition to a C >> program some time, and tell me how easy it is to deal with (although >> you'll actually discover a use case for strncpy). > >That sounds easy: I assume a Cobol struct is just a number of fixed >length alphanumeric fields. You can quickly get to the low-level binary >information that is needed. Ignoring that most of the data types will not map naturally into (say) a C version* and that you have some interesting alignment and padding issues**. Structurally there are interesting union types (fortunately not to often used these days) what don't match the normal structure directly. Those can obviously be simulated with a union on a bigger scale with appropriate monkeying about with offsets. Although you quickly end up with a morass of nested structs and unions. Cobol record definitions can contain variable length arrays - and the items *after* the variable length arrays move based on the size. And you can have several of those. There are a few other interesting gotchas. Also while conversions to something C-ish are possible, the way attributes and such trickle down the structure makes that a non-trivial exercise. *You have fixed length strings, decimal types of various representations and sizes, and while you have binary and (rarely) floating types, you'll also need to support 128 bit binaries (and roughly similar length decimal items), and you'll need to deal with scaling factors, plus various layout options. **Remember that these are intended for external use as well, and while you can request "natural" alignment, it's certainly not the default. >Similarly with C: it is possible to follow typedefs and macros to the >underlying primitive type (although you might have execute some tests to >find the actual size of an int or long!). Sometimes the docs will help. > >With C++ with the extra layers of abstraction that are possible, it's >not really practical unless the interface is really a C one but called >C++ (as happens with MS' old Win32 libraries, but the newer ones use >hard-core C++). > >There are ways to use such libraries, involving creating an extra buffer >layer with a simple-to-use Bart-friendly interface on one side, and >which talks to the complex C++ API on the other. > >(But even that won't work with some complex libraries such as those from >MS - I could never work with COM for example since I simply haven't got >a clue where to start (or what it is or whether I need to use it at >all!). To take an API, I do need to understand what it can do.) It's actually not *that* hard to call most COM stuff from C, but you are going to start by poking your way through vtables. Someone even did a tutorial: http://www.codeproject.com/Articles/13601/COM-in-plain-C But certainly if your objects contain other objects that you don't normally see in the innards of (say an STL container), you clearly are going to have issues. But that's hardly the fault of OOP, or even C++. If you're going to create an interface for use between two languages, you generally have to make some effort to stick to a common subset. And heck, doing that makes the Cobol problem a lot more tractable too. The reason people create relatively straight-forward C-like interfaces is that approximately everyone supports that in some fashion. If the creators of some package have neglected to do that (or provide some other easy to use interface), that's not the fault of OOP, or Cobol, or whatever.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-20 10:52 +0100 |
| Message-ID | <moig97$u00$1@dont-email.me> |
| In reply to | #65958 |
On 20/07/2015 08:34, Robert Wessel wrote: > On Mon, 20 Jul 2015 00:25:17 +0100, Bartc <bc@freeuk.com> wrote: >> That sounds easy: I assume a Cobol struct is just a number of fixed >> length alphanumeric fields. You can quickly get to the low-level binary >> information that is needed. > > > Ignoring that most of the data types will not map naturally into (say) > a C version* and that you have some interesting alignment and padding > issues**. > Structurally there are interesting union types (fortunately not to > often used these days) what don't match the normal structure directly. > Those can obviously be simulated with a union on a bigger scale with > appropriate monkeying about with offsets. Although you quickly end up > with a morass of nested structs and unions. I assume the analogy here is using Cobol-style data structures to define an API. If the information is available, then it is feasible to do, a little like writing a specific file format. But what C++ does with OO is on a different level. >> (But even that won't work with some complex libraries such as those from >> MS - I could never work with COM for example since I simply haven't got >> a clue where to start (or what it is or whether I need to use it at >> all!). To take an API, I do need to understand what it can do.) > > > It's actually not *that* hard to call most COM stuff from C, but you > are going to start by poking your way through vtables. Someone even > did a tutorial: > > http://www.codeproject.com/Articles/13601/COM-in-plain-C The author disagrees: "That's all there is to it?? That was easy!" Hold on. IExample is getting closer, but there's much more to it. It's not that easy." But yeah, I remember going along this route before, and using someone else's actual C code as a layer on top of GDI+ or DirectDraw or whatever it might have been. I couldn't get it to work and didn't know enough to debug it. > The reason people create relatively straight-forward > C-like interfaces is that approximately everyone supports that in some > fashion. If the creators of some package have neglected to do that > (or provide some other easy to use interface), that's not the fault of > OOP, or Cobol, or whatever. People who design packages tend not to make them simple. In fact they seem to think it is a bonus to make them as large and comprehensive as possible! They also tend to assume they will be used from the same language. My APIs tend to be small and very simple. But what you say is true: when I needed to implement 'tooltips' for a GUI, Win32 provided a C API consisting of dozens of functions, macros, structs and messages. And even after two days' effort trying, I couldn't get it to work. The new C++ version now has dozens of methods, constructors, properties and events instead! The difference is, I can't now spend the two days trying even if I wanted to. There's an entry barrier due to the use of C++. (I later added tooltips myself to my own graphics library. The API consisted of a *single* function. It also worked. And it worked for *any* button unlike MS' highly restrictive version. That's how you write a small and friendly API.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-20 05:31 -0700 |
| Message-ID | <7850734a-02f2-47b3-8984-b30584528569@googlegroups.com> |
| In reply to | #65968 |
On Monday, July 20, 2015 at 10:52:10 AM UTC+1, Bart wrote: > > People who design packages tend not to make them simple. In fact they > seem to think it is a bonus to make them as large and comprehensive as > possible! They also tend to assume they will be used from the same language. > > My APIs tend to be small and very simple. > > But what you say is true: when I needed to implement 'tooltips' for a > GUI, Win32 provided a C API consisting of dozens of functions, macros, > structs and messages. And even after two days' effort trying, I couldn't > get it to work. The new C++ version now has dozens of methods, > constructors, properties and events instead! > I'm currently writing a tiff reader. Its initial use will be in the Baby X resource compiler, but of course it should be usable elsewhere. it will have a very simple interface - loading a tiff as a 32 bit rgba. But whilst that's what a lot of people will want, really it's only relevant for those to whom tiff is a nuisance. Really such images should be saved as png. Tiff comes into its own for really high end graphics. A simple API isn't so easy to design.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-19 22:16 -0700 |
| Message-ID | <b0366d34-7610-4584-aadb-b9407ec66b7d@googlegroups.com> |
| In reply to | #65934 |
On Sunday, July 19, 2015 at 10:55:54 PM UTC+1, Ian Collins wrote:
> Malcolm McLean wrote:
>
> > I agree with what you mean, but not with what you literally said.
> > There is something inherently wrong with OOP, which is that the
> > interfaces are too complex, the interdependencies too intricate,
> > and the programs as a result brittle.However that doesn't always
> > matter, and it can be overcome with care.
>
> From where do you draw that conclusion? Why should an OO solution to a
> problem have complex interfaces?
>
Let's take a simple OOP interface.
We've got an alien base class. All aliens can attack taking a "Path"
parameter. "Path" is defined thus
class Path
{
public:
virtual double length();
virtual Point getPoint(double t);
virtual bool isClosed(void);
};
The alien has a startAttack() member function
void Alien::startAttack(Path &attackPath)
{
this->mPath = attackPath;
}
Then it also had a tick() function which is called every frame
void Alien::tick()
{
if(onAttack)
{
double d = mVelocity * tickInterval();
double t = mLastt + d/mPath.length();
this->moveTo(mPath.getPoint(t));
}
}
So I haven't given you the full functionality, but you've got enough
information.
So How do you set this thing up? Well, obviously, you need to derive
something from Path. let's say we want the alien to attack along a
Bezier curve. We've now got to pull in the Point class, almost
certainly something pretty trivial. But is it x, y or v, h? Fixed
for floating? We've got to look at that class to find out.
Now we need to define the class
class Bezier : public Path
{
Point v[4];
double length;
public:
Bezier(Point &P0, Point &C1, Point &C2, Point &P3);
double length()
{
}
Point getPoint(double t)
{
}
bool isClosed(void)
{
}
}
Now we've got to implement those functions. Which is where our problems
start. Length() is called on every tick, so it needs to be cached.
However how do you know that? Obviously, the Alien is documented
somewhere as saying "path length member called frequently, please
implement efficiently". Ha ha. What's the chance of that? By
reading the code, we can of course work it out. But you can't calculate
an exact path length for a Bezier curve. However it's an alien in
a space game, it doesn't need to know the length to a mathematical
exactness, just the rough length. But how rough? Let's look back
at the code.
Now we've written out length function, onto getPoint(). The snag with
Beziers is that t doesn't vary constantly with arc length. But
again, it's a video game, it doesn't matter if the alien is a
pixel out. Or does it? Will that cause temporal aliasing as it slides
around the screen? We're going to have to do some experiments here,
to see if we need to arc length paramaterise our Bezier or not.
Finally, on the last frame, t, might go over 1.0. Normally that won't
matter - the Bezier just extends a pixel. But, some people like to
desribe straight lines by Beziers with P0 == C1 and C2 == P3. Now
we'll maybe get a problem. The alien will judder backwards on the
last frame of its attack. Which might be a serendipitous nice
little tough, but that's the game designer's call.
So you see the complexity in this little interface?
Now let's look at the non-OO way of doing things.
struct alien
{
double x, y; /* alien location */
int attacktype;
double t;
}
tick()
{
/* move aliens here */
if(alien.attacktype == BEZIER)
{
double v[8]; /* Bezier coefficients */
double newt;
double newx, newy;
getbezier(v); /* somehow we need to know the bezier */
newt = t + 0.0001;
newx = alien.x;
newy = alien.y;
while( (alien.x-newx)*(alien.x-newx) +(alien.y-newy)*(alien.y-newy) <
alien.velocity && newt < 1.0)
{
newx = v[0]*(1-newt)*(1-newt)*(1-newt)+
v[2]*3*(1-newt)*(1-newt)*newt+
v[4]*3*(1-newt)*newt*newt+
v[6]*newt*newt*newt;
newy = v[1]*(1-newt)*(1-newt)*(1-newt)+
v[3]*3*(1-newt)*(1-newt)*newt+
v[5]*3*(1-newt)*newt*newt+
v[7]*newt*newt*newt;
}
alien.x = newx;
alien.y = newy;
newt += 0.0001;
}
}
}
We've done it. It's about 30 lines of code, with only one subroutine
call.
Now there's a possible weakness, which is that out magic constant
of 0.0001 is either too fine or not fine enough. But all the complexity
is in one place. If it's no good, we just update it.
Now the OOP method has other advantages, of course. But ease of setting
up isn't one of them. We can get an alien moving along a Bezier in
a few minutes with C, with C++, we're finding ourselves pushed
down the path of solving the Bezier arc paramaterisation problem,
when we don't need to do that - it's just a path for an alien to
move down.
[toc] | [prev] | [next] | [standalone]
Page 12 of 15 — ← Prev page 1 … 10 11 [12] 13 14 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web