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 13 of 15 — ← Prev page 1 … 11 12 [13] 14 15 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-20 17:24 +1200 |
| Message-ID | <d13evtF9itpU6@mid.individual.net> |
| In reply to | #65953 |
Malcolm McLean wrote:
> 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;
> }
<snip>
> 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 */
Hang on, your "30 lines of code" don't include the most complex part of
the previous example: solving the Bezier arc paramaterisation.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-19 22:36 -0700 |
| Message-ID | <6d08f642-c5a1-4fec-8e5b-a72bfee3dd6a@googlegroups.com> |
| In reply to | #65954 |
On Monday, July 20, 2015 at 6:24:27 AM UTC+1, Ian Collins wrote:
> Malcolm McLean wrote:
> > 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;
> > }
>
> <snip>
>
> > 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 */
>
> Hang on, your "30 lines of code" don't include the most complex part of
> the previous example: solving the Bezier arc paramaterisation.
>
Because we don't need to do it, because we don't actually need
to support the "Path" interface. We need to move an alien along
a Bezier at roughly constant speed.
Whilst I've written it in a specific way, if it turns into a
huge problem we can generalise it
/*
get the t-value needed to move along the Bezier from t by
delta, with epsilon accuracy
*/
double getTforDelta(Bezier *bez, double t, double delta, double epsilon)
{
}
that function's not too hard to write, especially if you can fail
for catastrophic Beziers.
Then it plugs and plays. You can use it in a lot of C code that
uses beziers. Except for the object-oriented feature, the definition
of the Bezier structure. You can't be defining a "Bezier" specially
for this little routine. In reality you'll have to go through it
replacing all the CP1s with v[1]'s to match whatever Bezier
structure the new program defines.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-20 21:07 +1200 |
| Message-ID | <d13s2fF9itpU8@mid.individual.net> |
| In reply to | #65956 |
Malcolm McLean wrote:
> On Monday, July 20, 2015 at 6:24:27 AM UTC+1, Ian Collins wrote:
>>
>> Hang on, your "30 lines of code" don't include the most complex part of
>> the previous example: solving the Bezier arc paramaterisation.
>>
> Because we don't need to do it, because we don't actually need
> to support the "Path" interface. We need to move an alien along
> a Bezier at roughly constant speed.
But you still need to do calculate the next position, so the code to
calculate that position has to be written. Then there's the question of
how do you change the path to some random (or simple) trajectory once
you have the Bezier coefficients and call embedded in your tick function.
> Whilst I've written it in a specific way, if it turns into a
> huge problem we can generalise it
>
> /*
> get the t-value needed to move along the Bezier from t by
> delta, with epsilon accuracy
> */
> double getTforDelta(Bezier *bez, double t, double delta, double epsilon)
> {
> }
>
> that function's not too hard to write, especially if you can fail
> for catastrophic Beziers.
It wasn't had to write in the OO solution either.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-20 02:51 -0700 |
| Message-ID | <634e039c-de09-47da-b155-fd29ae80427d@googlegroups.com> |
| In reply to | #65965 |
On Monday, July 20, 2015 at 10:07:37 AM UTC+1, Ian Collins wrote:
> Malcolm McLean wrote:
> > On Monday, July 20, 2015 at 6:24:27 AM UTC+1, Ian Collins wrote:
> >>
> >> Hang on, your "30 lines of code" don't include the most complex part of
> >> the previous example: solving the Bezier arc paramaterisation.
> >>
> > Because we don't need to do it, because we don't actually need
> > to support the "Path" interface. We need to move an alien along
> > a Bezier at roughly constant speed.
>
> But you still need to do calculate the next position, so the code to
> calculate that position has to be written. Then there's the question of
> how do you change the path to some random (or simple) trajectory once
> you have the Bezier coefficients and call embedded in your tick function.
>
Yes, but that's a lot easier than trying to write a stable conversion between
an arc-length t and a curve-space t. It's not impossibly hard, I've got a routine
that does just that, which, to be fair, is a C++ class. But it's a normal length
C++ source file, it's got forwards differencing to get the arcs efficiently,
then a lookup table and a binary search, it took quite a bit of getting right.
> >
> > /*
> > get the t-value needed to move along the Bezier from t by
> > delta, with epsilon accuracy
> > */
> > double getTforDelta(Bezier *bez, double t, double delta, double epsilon)
> > {
> > }
> >
> > that function's not too hard to write, especially if you can fail
> > for catastrophic Beziers.
>
> It wasn't had to write in the OO solution either.
>
You can't use it in the OO solution, because you have to return x,y for any t. That's
what the Path interface specifies. I should have made clear that getTforDelta is only
going to work if the curve is essentially flat over the interval in question, if we
insist that delta genuinely represents curve space we're back to the intractable arc
length problem.
The points is that there's an easy answer which is almost certainly good enough,
which is to take small but not too tiny steps along the curve until you hit the
right distance, and there's a difficult answer, which is to try to arc-length parameterise
your curve. The OOP interface forces you into the difficult answer.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-07-19 10:12 -0500 |
| Message-ID | <mogele$e61$1@dont-email.me> |
| In reply to | #65889 |
Malcolm McLean wrote: > 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. > One of the things I like about Tcl is that it seems to be a cross-pollination of the "list" part of LISP with 'C' like imperative semantics. It helps that the team for Tcl is very good and it never quote caught the attention of the punters in the same way, say, Perl did. Eric Raymond's slander of Tcl probably saved it. > 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. > C++ was hugely successful but in a very constrained way. OO just developed a huge "no true Scotsman" problem. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-07-19 16:54 -0500 |
| Message-ID | <ua6oqalm0vo7chp0q5la6k16gfril1ibm2@4ax.com> |
| In reply to | #65897 |
On 19 Jul 2015 16:16:15 GMT, ram@zedat.fu-berlin.de (Stefan Ram) wrote: >Les Cargill <lcargill99@comcast.com> writes: >>Malcolm McLean wrote: >>C++ was hugely successful but in a very constrained way. OO >>just developed a huge "no true Scotsman" problem. > > C++ got better in recent years and its TIOBE rankings > now start to reflect this. > > OO has failed only in the sense that WYSIWYG or DTP have > failed: Nobody talks about it anymore because everybody uses > it, it's not new anymore and has become the mainstream. > Programming today means OOP. When one uses a purely > procedural language without OO constructs, /that/ is the > exception. I fully agree. OOP has "failed" so badly that it's now part of the assumed background for any serious language, excepting those that have a specific reason to avoid it. We don't talk about programming languages supporting structured programming much either anymore. What has gone away is some of the over enthusiasm from the early days (and some of it was really over the top), especially the early love of trying to turn everything in to an immense hierarchy of classes. Well, that works for some things, not so much for others (IOW, not all the world's a GUI). Things like inheritance and polymorphism are clearly susceptible to overuse, but then what isn't? Some maturity and experience to manage where those should be used has improved things greatly. And obviously people have been doing OOP long before languages supported it explicitly, but that's no reason to avoid languages that do have explicit support. And that C++ has issues is not really up for debate either, but they have nothing really to do with OOP. OTOH, I will get on my hobby horse and complain about your citing of TIOBE. TIOBE, at best, measures the level of chatter on the internet about various languages. What little, if anything, that has to do with the actual popularity and use of those languages is unclear (to be generous). OTTH, it's a measurement of something, so we have something to talk about, I guess...
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2015-07-20 12:34 -0500 |
| Message-ID | <mojbb2$adm$1@dont-email.me> |
| In reply to | #65897 |
ram@zedat.fu-berlin.de (Stefan Ram) wrote: > Les Cargill <lcargill99@comcast.com> writes: >> Malcolm McLean wrote: >> C++ was hugely successful but in a very constrained way. OO >> just developed a huge "no true Scotsman" problem. > > C++ got better in recent years and its TIOBE rankings > now start to reflect this. > I have to wonder whether TIOBE is all that useful. But it would not surprise me if C++ is "better" now. My point stands - there was a significant level of deontological* outrage in favor of C++ for a very long time. In the embedded space, this may or may not have been justified. *should for should's sake. We also have had people like Alan Kay more or less deprecating C++. So there's probably still considerable disagreement about what OO even means - being a flexible paradigm. this is to be expected. > OO has failed only in the sense that WYSIWYG or DTP have > failed: Nobody talks about it anymore because everybody uses > it, Dunno about that. There are many domains in which it makes sense, but there are arguably many more where it does not. I do almost nothing in a "procedural" fashion in 'C' - I still build up objects with closely defined interfaces and fairly strict adherence to very limited use cases of them. Sometimes these interfaces are *crude*, but the rules are still obeyed. > it's not new anymore and has become the mainstream. > Programming today means OOP. I think you'll find that at least partially false. I was rather surprised, too. > When one uses a purely > procedural language without OO constructs, /that/ is the > exception. > Given that an awful of of software is .NET or Java, probably so. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-23 07:28 -0700 |
| Message-ID | <kfn8ua7hrrp.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66028 |
Les Cargill <lcargill99@comcast.com> writes: > ram@zedat.fu-berlin.de (Stefan Ram) wrote: >> Les Cargill <lcargill99@comcast.com> writes: >>> Malcolm McLean wrote: >>> C++ was hugely successful but in a very constrained way. OO >>> just developed a huge "no true Scotsman" problem. >> >> C++ got better in recent years and its TIOBE rankings >> now start to reflect this. > > I have to wonder whether TIOBE is all that useful. But it > would not surprise me if C++ is "better" now. > > My point stands - there was a significant level of deontological* > outrage in favor of C++ for a very long time. In the > embedded space, this may or may not have been justified. > > *should for should's sake. It's hard to say why C++ is more popular now than it used to be, assuming of course that it is. Whether that is so or not, C++ != OOP. > We also have had people like Alan Kay more or less > deprecating C++. So there's probably still considerable > disagreement about what OO even means - being a flexible > paradigm. this is to be expected. I wouldn't call it disagreement, since he invented both the term and the concept (or paradigm, if someone wants to use that term instead). A lot of people who came afterwards copied the term without understanding the concept. What resulted is not disagreement but just the term having been co-opted to mean something other than what it meant originally (and probably I should have said "somethings" since clearly it means different things to different people now). >> OO has failed only in the sense that WYSIWYG or DTP have >> failed: Nobody talks about it anymore because everybody uses >> it, > > Dunno about that. There are many domains in which it makes sense, > but there are arguably many more where it does not. > > I do almost nothing in a "procedural" fashion in 'C' - I > still build up objects with closely defined interfaces and > fairly strict adherence to very limited use cases of them. > > Sometimes these interfaces are *crude*, but the rules are still > obeyed. > > >> it's not new anymore and has become the mainstream. >> Programming today means OOP. > > I think you'll find that at least partially false. I > was rather surprised, too. > >> When one uses a purely >> procedural language without OO constructs, /that/ is the >> exception. > > Given that an awful of of software is .NET or Java, probably > so. I speculate that in many cases a class construct is added to a programming language just because it isn't hard to do and is thought to be necessary for the language to appeal to a wider "audience". Whether "object orientation" is an effective tool or not (or in which applications), it is popular, and therefore it is supported (one way or another) in many or most contemporary programming languages.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-07-27 11:08 +0200 |
| Message-ID | <mp4sep$eun$1@speranza.aioe.org> |
| In reply to | #66253 |
On 23.07.2015 16:28, Tim Rentsch wrote: > Les Cargill <lcargill99@comcast.com> writes: [...] >> I think you'll find that at least partially false. I >> was rather surprised, too. >> >>> When one uses a purely >>> procedural language without OO constructs, /that/ is the >>> exception. >> >> Given that an awful of of software is .NET or Java, probably >> so. > > I speculate that in many cases a class construct is added to a > programming language just because it isn't hard to do and is > thought to be necessary for the language to appeal to a wider > "audience". Whether "object orientation" is an effective tool or > not (or in which applications), it is popular, and therefore it > is supported (one way or another) in many or most contemporary > programming languages. I think OOP is good for grouping and organizing code & data, as well as enabling code re-use. After many years of programming in an object- oriented fashion, it isn't much of a struggle to map that over to structs and functions. Inheritance (overriding methods) and "natural" namespaces (self, class, parent class(es)) are those who spring to mind first. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-30 15:45 -0700 |
| Message-ID | <kfnwpxhb6z1.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66438 |
"Morten W. Petersen" <morphex@gmail.com> writes: > On 23.07.2015 16:28, Tim Rentsch wrote: >> Les Cargill <lcargill99@comcast.com> writes: > > [...] > >>> I think you'll find that at least partially false. I >>> was rather surprised, too. >>> >>>> When one uses a purely >>>> procedural language without OO constructs, /that/ is the >>>> exception. >>> >>> Given that an awful of of software is .NET or Java, probably >>> so. >> >> I speculate that in many cases a class construct is added to a >> programming language just because it isn't hard to do and is >> thought to be necessary for the language to appeal to a wider >> "audience". Whether "object orientation" is an effective tool or >> not (or in which applications), it is popular, and therefore it >> is supported (one way or another) in many or most contemporary >> programming languages. > > I think OOP is good for grouping and organizing code & data, as well as > enabling code re-use. After many years of programming in an object- > oriented fashion, it isn't much of a struggle to map that over > to structs and functions. If the objects are as polymorphic as they should be, it is.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-02 14:59 +0200 |
| Message-ID | <mplb96$h14$1@speranza.aioe.org> |
| In reply to | #66589 |
On 31.07.2015 00:45, Tim Rentsch wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: [...] >> I think OOP is good for grouping and organizing code & data, as well as >> enabling code re-use. After many years of programming in an object- >> oriented fashion, it isn't much of a struggle to map that over >> to structs and functions. > > If the objects are as polymorphic as they should be, it is. OK. Could you elaborate on that? -Morten
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-08-04 08:40 -0700 |
| Message-ID | <kfnr3nj6ozz.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #66701 |
"Morten W. Petersen" <morphex@gmail.com> writes: > On 31.07.2015 00:45, Tim Rentsch wrote: >> "Morten W. Petersen" <morphex@gmail.com> writes: > > [...] > >>> I think OOP is good for grouping and organizing code & data, as well as >>> enabling code re-use. After many years of programming in an object- >>> oriented fashion, it isn't much of a struggle to map that over >>> to structs and functions. >> >> If the objects are as polymorphic as they should be, it is. > > OK. Could you elaborate on that? Very briefly: in a well-developed object system, different classes share both lots of messages (aka interfaces) and lots of methods (aka implementations), numbering at least in double digits and in some cases triple digits. Doing this by hand is possible (I know, I've done it) but tedious and somewhat error-prone. Also there is the matter of type. The C type system isn't a good fit for the needs of a full-scale object system (which actually presents some significant challenges even for advanced type systems, but that is another level beyond what I'm talking about here). Basically that means we are left with two choices: one, use a generic type like 'Object *' for everything, and rely on catching things dynamically, or two, use more specific types (ie, on message/method definitions), and shoehorn that into the C type system by selected use of type-safe conversions and/or casting. Neither of these choices is really satisfactory: either can be made to work, to a degree, but it isn't easy and it isn't fun, or to say it another way it's a thankless administrative chore, and not a trivial one. So this is why I say doing an OO "overlay" on structs and so forth is something of a struggle, when trying to do it on any sort of reasonable scale. For very limited object systems, perhaps a dozen classes or two, it's not too bad, but it doesn't scale up without a much larger increase in the administrative overhead.
[toc] | [prev] | [next] | [standalone]
| From | "Morten W. Petersen" <morphex@gmail.com> |
|---|---|
| Date | 2015-08-04 23:05 +0200 |
| Message-ID | <mpr9ee$q23$1@speranza.aioe.org> |
| In reply to | #66862 |
On 04.08.2015 17:40, Tim Rentsch wrote: > "Morten W. Petersen" <morphex@gmail.com> writes: > >> On 31.07.2015 00:45, Tim Rentsch wrote: >>> "Morten W. Petersen" <morphex@gmail.com> writes: >> >> [...] >> >>>> I think OOP is good for grouping and organizing code & data, as well as >>>> enabling code re-use. After many years of programming in an object- >>>> oriented fashion, it isn't much of a struggle to map that over >>>> to structs and functions. >>> >>> If the objects are as polymorphic as they should be, it is. >> >> OK. Could you elaborate on that? > > Very briefly: in a well-developed object system, different > classes share both lots of messages (aka interfaces) and > lots of methods (aka implementations), numbering at least > in double digits and in some cases triple digits. Doing > this by hand is possible (I know, I've done it) but tedious > and somewhat error-prone. Also there is the matter of > type. The C type system isn't a good fit for the needs of > a full-scale object system (which actually presents some > significant challenges even for advanced type systems, but > that is another level beyond what I'm talking about here). > Basically that means we are left with two choices: one, > use a generic type like 'Object *' for everything, and rely > on catching things dynamically, or two, use more specific > types (ie, on message/method definitions), and shoehorn > that into the C type system by selected use of type-safe > conversions and/or casting. Neither of these choices is > really satisfactory: either can be made to work, to a > degree, but it isn't easy and it isn't fun, or to say it > another way it's a thankless administrative chore, and not > a trivial one. So this is why I say doing an OO "overlay" > on structs and so forth is something of a struggle, when > trying to do it on any sort of reasonable scale. For very > limited object systems, perhaps a dozen classes or two, > it's not too bad, but it doesn't scale up without a much > larger increase in the administrative overhead. Ah yes, OK. I was thinking of seeing a struct and functions as an OK way to represent an object and its methods. What I'm reading from you now is that you're thinking of mapping actual code to/from OOP/C, and yes I can imagine that with lots of classes that is a chore. Although it would for example be interesting and fun to create some glue between for example C and Python that does a lot of "smart conversions". But that's the over-engineering geek in me speaking. -Morten
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-19 12:46 -0700 |
| Message-ID | <ln1tg4gcce.fsf@kst-u.example.com> |
| In reply to | #65889 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> 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.
This newsgroup isn't predicated on any idea about C++. it's about
discussing C.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-19 12:57 -0700 |
| Message-ID | <912f7d3c-2a52-43e3-b5af-3ec965af378d@googlegroups.com> |
| In reply to | #65914 |
On Sunday, July 19, 2015 at 8:46:22 PM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > This newsgroup isn't predicated on any idea about C++. it's about > discussing C. > If you accept that C++ is a better C, then there's no point using C any more. Plenty of people take that view. Generally you find that the very best programmers, like Linus Torvalds or the writers of the ffmpeg library, prefer C, as do beginners, and the people in between like C++.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2015-07-19 21:16 +0100 |
| Message-ID | <87wpxvrjh9.fsf@gmail.com> |
| In reply to | #65915 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Sunday, July 19, 2015 at 8:46:22 PM UTC+1, Keith Thompson wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> This newsgroup isn't predicated on any idea about C++. it's about >> discussing C. >> > If you accept that C++ is a better C, then there's no point using C > any more. Plenty of people take that view. Generally you find that the > very best programmers, like Linus Torvalds or the writers of the > ffmpeg library, What ffmpeg and Linux have in common, is i) they're very very performance centric. ii) they're full of bit twiddling. If you want that, yeah damn right C + ASM is going to be your thing. The other 99.9999999% will be happy for some abstraction. > prefer C, as do beginners, and the people in between like C++. [citation needed]
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-07-20 15:50 -0700 |
| Message-ID | <kfnzj2qjvff.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #65887 |
Robert Wessel <robertwessel2@yahoo.com> writes: > 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. > > Going from C to Haskell is much harder than going from C to Java, for > example. But functional languages are not actually harder to learn > than imperative languages in the first place. IOW, teaching a > non-programmer Haskell is about as difficult as teaching them C or > Java. So the "general programmer" is pretty much just as capable of > learning to program in a functional language as they we able to learn > to program in C, or whatever. It's just that the pain is more like > learning to program in the first place, rather than learning yet > another ~imperative language. I pretty much agree with what you're saying here, but I want to add just a little something. There's a lot more to functional programming than just learning how to write well-behaved recursive functions. The stuff I've been talking about is a much easier skill to acquire than it is to get all of functional programming and the mindset that goes with it. Drawing a conclusion about the difficulty of writing good recursive functions, based on an impression about how difficult functional programming is in full generality, is a further indicator that the original statement is suspect.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-18 09:13 -0400 |
| Message-ID | <modjb6$j6d$1@dont-email.me> |
| In reply to | #65838 |
On 07/18/2015 05:44 AM, Ben Bacarisse wrote: > ram@zedat.fu-berlin.de (Stefan Ram) writes: ["it" below refers to a tail-call] ... >> If this is so easy and obvious for you, than give the definition of >> it. > > In a non-void function its a return statement whose expression is a > function call. In a void function it's an expression statement that > consists of nothing but a function call immediately preceding a return > statement. My understanding is that a tail call occurs whenever the very last thing given subroutine does is call another subroutine. You've given two ways this can happen in C, but it seems to me that there are a few more. In a function returning a value, the expression in the return statement doesn't have to be a function call, it could merely contain a function call as it's last-executed sub-expression - but it must do nothing with the return value of that function except use it as it's own return value. It could be the second operand of a comma-expression, or the second or third operand of a ?: - I don't think there's. The same applies to the final expression executed before returning from a void function. Also, an explicit return statement is not needed for such functions. 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. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-07-18 15:04 +0100 |
| Message-ID | <87a8utbm0b.fsf@bsb.me.uk> |
| In reply to | #65845 |
James Kuyper <jameskuyper@verizon.net> writes: > On 07/18/2015 05:44 AM, Ben Bacarisse wrote: >> ram@zedat.fu-berlin.de (Stefan Ram) writes: > ["it" below refers to a tail-call] > ... >>> If this is so easy and obvious for you, than give the definition of >>> it. >> >> In a non-void function its a return statement whose expression is a >> function call. In a void function it's an expression statement that >> consists of nothing but a function call immediately preceding a return >> statement. > > My understanding is that a tail call occurs whenever the very last thing > given subroutine does is call another subroutine. You've given two ways > this can happen in C, but it seems to me that there are a few more. In a > function returning a value, the expression in the return statement > doesn't have to be a function call, it could merely contain a function > call as it's last-executed sub-expression - but it must do nothing with > the return value of that function except use it as it's own return > value. It could be the second operand of a comma-expression, or the > second or third operand of a ?: - I don't think there's. > > The same applies to the final expression executed before returning from > a void function. Also, an explicit return statement is not needed for > such functions. Yes, it was always going to be fool's errand to try to be exact in C! But you don't have to define all cases that match some more abstract notion if the purpose is to say what will and what will not be optimised. As I said in another reply, I think you could use C's notion of sequence points to get a very tight definition (a tail call being one where nothing is done between the sequence points at the end of the called and the calling function?) but that might preclude other optimisations. > 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. I don't think that need affect the definition of a tail call. You could say that a tail call changes all the local objects, and you'd be covered by the clause in the definition of longjmp that makes the values of such objects indeterminate. But in order to break fewer programs one would have to say that tail calls in functions that use setjmp are never optimised. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-18 12:40 -0400 |
| Message-ID | <55AA816C.3030100@verizon.net> |
| In reply to | #65851 |
On 07/18/2015 10:04 AM, Ben Bacarisse wrote: > James Kuyper <jameskuyper@verizon.net> writes: ... >> 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. > > I don't think that need affect the definition of a tail call. You could > say that a tail call changes all the local objects, and you'd be covered > by the clause in the definition of longjmp that makes the values of such > objects indeterminate. ... That only applies to non-volatile objects (7.13.2.1p3). Calling setjmp() during the lifetime of a volatile object local to the same function would force the retention of at least enough of the function's memory to store the value of that object. > ... But in order to break fewer programs one would > have to say that tail calls in functions that use setjmp are never > optimised. That will work, too.
[toc] | [prev] | [next] | [standalone]
Page 13 of 15 — ← Prev page 1 … 11 12 [13] 14 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web