Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #102431 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2017-01-25 14:30 +0000 |
| Last post | 2017-02-04 10:13 -0800 |
| Articles | 20 on this page of 206 — 18 participants |
Back to article view | Back to comp.lang.c
Preprocessor Overheads BartC <bc@freeuk.com> - 2017-01-25 14:30 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-01-27 15:18 +0000
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-01 11:40 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-01 21:35 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-01 21:02 +0000
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-02 00:35 -0600
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-02 09:00 +0100
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-02 16:41 -0600
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-03 00:11 +0100
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-03 00:56 -0600
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-01 20:49 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-02 00:43 +0000
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-01 17:36 -0800
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-01 17:50 -0800
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-01 18:09 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-02 10:30 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-02 12:13 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-02 13:53 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-02 13:14 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-02 14:42 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-02 15:25 +0000
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 10:19 -0800
Re: Preprocessor Overheads Noob <root@127.0.0.1> - 2017-02-02 22:59 +0100
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-03 06:02 -0800
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-03 14:29 +0000
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 10:00 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-03 08:54 -0800
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 10:03 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 10:15 -0800
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-02 19:29 +0000
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-03 08:32 +1300
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-02 20:44 +0000
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 13:06 -0800
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-02 21:51 +0000
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-02 14:16 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 15:17 -0800
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-03 00:16 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-03 01:09 +0000
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-03 01:04 -0600
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-03 11:34 +0100
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-03 14:54 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-03 15:31 +0000
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-03 19:32 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-03 20:28 +0000
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-03 12:44 -0800
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-03 21:33 +0000
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-03 16:19 -0600
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-03 22:46 +0000
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-03 17:47 -0600
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-04 13:26 +1300
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 01:08 +0000
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-04 18:09 +1300
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 12:14 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-04 17:01 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 18:20 +0000
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-05 20:40 +1300
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 00:08 -0800
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-05 21:10 +1300
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 00:21 -0800
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-05 11:51 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 04:34 -0800
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-06 09:26 +1300
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-05 21:02 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-05 22:39 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 00:21 +0100
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-06 13:10 +1300
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 01:55 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-06 00:57 +0000
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-06 14:08 +1300
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 09:32 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-06 12:22 +0000
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-06 04:40 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 14:04 +0100
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-06 06:08 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 15:42 +0100
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-06 08:10 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-07 09:57 +0100
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-07 11:26 +0000
Re: Preprocessor Overheads raltbos@xs4all.nl (Richard Bos) - 2017-02-06 10:36 +0000
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-07 07:27 +1300
Re: Preprocessor Overheads antispam@math.uni.wroc.pl - 2017-02-04 20:35 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-05 21:16 +0100
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-04 00:51 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 01:20 +0000
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-04 01:48 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 02:10 +0000
Re: Preprocessor Overheads antispam@math.uni.wroc.pl - 2017-02-04 02:56 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-05 01:56 +0000
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-04 11:14 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 12:00 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 12:16 +0000
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-04 13:41 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 14:00 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-04 07:55 -0800
Re: Preprocessor Overheads gazelle@shell.xmission.com (Kenny McCormack) - 2017-02-04 18:15 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-05 21:41 +0100
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-04 16:36 +0000
Re: Preprocessor Overheads bart4858@gmail.com - 2017-02-04 11:24 -0800
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-04 21:08 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-04 13:41 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-04 14:26 -0800
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-04 23:27 +0000
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-05 00:18 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-04 19:56 -0800
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-05 11:01 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 04:04 -0800
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-05 14:03 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 06:56 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-05 09:01 -0800
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-05 20:53 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 13:34 -0800
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-06 11:15 +1300
Re: Preprocessor Overheads fir <profesor.fir@gmail.com> - 2017-02-05 14:30 -0800
Re: Preprocessor Overheads fir <profesor.fir@gmail.com> - 2017-02-05 14:39 -0800
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 14:58 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-05 15:23 -0800
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 15:40 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-05 15:05 -0800
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-06 13:22 +1300
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-09 07:48 -0800
Re: Preprocessor Overheads Thiago Adams <thiago.adams@gmail.com> - 2017-02-09 09:15 -0800
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-10 08:05 +1300
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-06 00:08 +0000
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-08 21:20 -0800
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-05 04:08 -0600
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-05 02:40 -0800
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-09 09:27 -0800
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-09 18:04 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-05 18:07 +0000
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-05 21:55 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-05 23:07 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 01:02 -0800
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-03 22:07 +1300
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-03 11:25 +0100
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 04:26 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 12:36 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 04:59 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 13:09 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 05:24 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 13:41 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 08:29 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 17:00 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 09:24 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 18:31 +0000
Re: Preprocessor Overheads raltbos@xs4all.nl (Richard Bos) - 2017-02-06 10:55 +0000
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-06 03:02 -0800
Re: Preprocessor Overheads Gareth Owen <gwowen@gmail.com> - 2017-02-03 19:55 +0000
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 20:11 +0000
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-03 17:30 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-03 18:00 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-03 21:27 +0100
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-03 21:35 +0000
Re: Preprocessor Overheads raltbos@xs4all.nl (Richard Bos) - 2017-02-06 10:53 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 14:06 +0100
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-06 05:22 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 14:49 +0100
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-06 05:59 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-06 14:12 +0000
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-06 06:13 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 15:22 +0100
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-06 15:27 +0000
Re: Preprocessor Overheads raltbos@xs4all.nl (Richard Bos) - 2017-02-06 15:10 +0000
Re: Preprocessor Overheads BartC <bc@freeuk.com> - 2017-02-06 14:55 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-06 16:57 +0100
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-03 21:17 +0100
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 20:20 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-03 21:29 +0100
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 21:03 +0000
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-03 22:33 +0100
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-04 13:29 +1300
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-04 04:19 -0800
Re: Preprocessor Overheads Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-03 15:18 +0000
Re: Preprocessor Overheads antispam@math.uni.wroc.pl - 2017-02-03 21:17 +0000
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-03 13:39 -0800
Re: Preprocessor Overheads antispam@math.uni.wroc.pl - 2017-02-03 23:38 +0000
Re: printing int64_t objects Noob <root@127.0.0.1> - 2017-02-02 23:40 +0100
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-03 20:20 +1300
Re: Preprocessor Overheads Gareth Owen <gwowen@gmail.com> - 2017-02-03 19:52 +0000
Re: Preprocessor Overheads Ian Collins <ian-news@hotmail.com> - 2017-02-04 14:03 +1300
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-02 14:13 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-02 12:08 -0800
Re: Preprocessor Overheads David Brown <david.brown@hesbynett.no> - 2017-02-02 21:45 +0100
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-02 15:35 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 15:56 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-02 16:23 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-03 12:23 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 20:51 +0000
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-03 14:16 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-03 22:47 +0000
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-03 16:38 -0800
Re: Preprocessor Overheads Richard Heathfield <rjh@cpax.org.uk> - 2017-02-04 00:47 +0000
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-03 18:34 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-04 11:02 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-04 13:18 -0800
Re: Preprocessor Overheads gazelle@shell.xmission.com (Kenny McCormack) - 2017-02-04 21:27 +0000
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 10:04 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 12:46 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-02 14:12 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 15:21 -0800
Re: Preprocessor Overheads supercat@casperkitty.com - 2017-02-02 16:02 -0800
Re: Preprocessor Overheads Keith Thompson <kst-u@mib.org> - 2017-02-02 16:13 -0800
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-02 14:16 -0800
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 05:03 -0800
Re: Preprocessor Overheads Robert Wessel <robertwessel2@yahoo.com> - 2017-02-03 16:41 -0600
Re: Preprocessor Overheads Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-03 16:15 -0800
Re: Preprocessor Overheads Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-04 10:13 -0800
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2017-02-09 09:15 -0800 |
| Message-ID | <e23930d3-dc6c-4f9a-8156-00d76f25ed4a@googlegroups.com> |
| In reply to | #103521 |
On Thursday, February 9, 2017 at 1:48:30 PM UTC-2, Tim Rentsch wrote: > Ian Collins writes: > > > [...] > > > > Type systems aren't the result of the human burden of complexities, > > they are the result of code having to interact with the physical > > world. > > This statement isn't exactly right. The original motivation for > types in programming languages was to distinguish between various > formats for different kinds of data. As the understanding of > what programming entails has progressed, the notion of type has > evolved so that it now encompasses (in some languages) much more > than just representation. To some extent this is true even in C: > an int and a const int have exactly the same representation, but > in some cases const int is a better choice precisely because it > helps developers understand the program more easily. So const is > an example of type system evolution resulting from wanting to > reduce the human burden of complexity. This also applies for _Bool and enuns in C. Others, like char can be interpreted as a char or number 8 bits.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-10 08:05 +1300 |
| Message-ID | <eg3srgF1hapU5@mid.individual.net> |
| In reply to | #103521 |
On 02/10/17 04:48 AM, Tim Rentsch wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> [...] >> >> Type systems aren't the result of the human burden of complexities, >> they are the result of code having to interact with the physical >> world. > > This statement isn't exactly right. The original motivation for > types in programming languages was to distinguish between various > formats for different kinds of data. As the understanding of > what programming entails has progressed, the notion of type has > evolved so that it now encompasses (in some languages) much more > than just representation. To some extent this is true even in C: > an int and a const int have exactly the same representation, but > in some cases const int is a better choice precisely because it > helps developers understand the program more easily. So const is > an example of type system evolution resulting from wanting to > reduce the human burden of complexity. Good point well made. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-06 00:08 +0000 |
| Message-ID | <87mve0dvvc.fsf@bsb.me.uk> |
| In reply to | #103243 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Sunday, February 5, 2017 at 8:53:36 PM UTC, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> > >> > Bit-based programming (my invention, my term, unlike "function" and >> > "array" and all the other things I'm alleged to have invented) doesn't >> > try to hide the bits behind layers of abstraction to solve the problem. >> > Instead the bits are exposed, and the program documents what the bits >> > are and what they mean. Like a portable binary format file like TIFF. >> >> How is that different to programming in, say, BCPL? >> > B64 will be a bit-based programming language and of course it is > an excavation or (proposed) resurrection of B and therefore BCPL. > > However BCPL wasn't typeless because of the human burden of complexities > created by type systems and data abstraction. Bit-based programming > is essentially a reaction to "data hiding". It says "show us the bits, > and tell us what they mean. Don't hide them". I don't understand this difference, but since it's off-topic I won't press the question. I can wait until you publish a design. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-08 21:20 -0800 |
| Message-ID | <kfnk2906iuf.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #103191 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >> On Sunday, February 5, 2017 at 12:18:41 AM UTC, Ben Bacarisse wrote: >>> >>>> The fact that combining runtime format strings, that can't be checked, >>>> and variadic functions is a recipe for disaster isn't important. >>> >>> Isn't it? OK. Seems important to me though. Part of the reason I >>> don't hold the position you attribute to me is because printf formats >>> are not type-safe and I prefer type-safe constructs. >> >> Type-safety is one of those expressions which implies that type- >> safe code is safe and, by corollary, non-type safe code is "unsafe". > > That's unfortunate. Is that misunderstanding common enough that another > term should be used? [...] I would chalk this up just to being more Malcolm-vocabulary. I don't know anyone (other than possibly Malcolm) who thinks code not being type-safe necessarily implies that it is unsafe. Based on past experience what seems most likely is that this is just something he made up (leaving open the possibility that it was a result of misunderstanding rather than a deliberate act).
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-02-05 04:08 -0600 |
| Message-ID | <idtd9cd39npdiflpvhctgd7avjpjqrn2mb@4ax.com> |
| In reply to | #103163 |
On Sat, 4 Feb 2017 11:24:39 -0800 (PST), bart4858@gmail.com wrote:
>Yet, if such a format had been available from the start as well as the usual formats, it would have been hailed as a brilliant bit of design. There wouldn't have been naysayers denigrating it because it only works in 99% of situations.
Your experience may well be different than mine, but I'd estimate that
far fewer than half of our uses of *printf have literal format
strings. Internationalization, and all that.
Perhaps something more like a standard macro-ish* device that can
extract the type, and leaves it as a parameter that *printf can read.
perhaps something like:
printf("%$\n", PRINTFTYPE(v, "05"));
Where the "macro" would exand to something corresponding to type
necessary type. The second parameter would be optional, but in the
case of an int that would expand to:
printf("%$\n", "05d", v);
which printf would then process as if it had been coded:
printf("%05d\n", v);
Clearly there are some issues to work out there (the base, length and
type are all a bit mixed together, for example).
*This could be built around a variation of gcc's typeof extension.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-02-05 02:40 -0800 |
| Message-ID | <b2863c1d-bc7d-482b-89f9-6abeb6432cd7@googlegroups.com> |
| In reply to | #103187 |
On Sunday, February 5, 2017 at 10:07:27 AM UTC, robert...@yahoo.com wrote:
>
> Perhaps something more like a standard macro-ish* device that can
> extract the type, and leaves it as a parameter that *printf can read.
> perhaps something like:
>
> printf("%$\n", PRINTFTYPE(v, "05"));
>
> Where the "macro" would exand to something corresponding to type
> necessary type.
>
Variadic functions are, in my experience, never used for anything other
that implementing or wrapping printf-style format strings.
So if you want printf to behave differently, changing the rules for the variadic
macros is reasonable. There's a very small base of code that you would
break, but it's still probably unacceptable to many people. But deprecating
in favour of the enhanced version is reasonable. printf and family itself
will of course use the updated version.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-09 09:27 -0800 |
| Message-ID | <kfnmvdv46lg.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #103187 |
Robert Wessel <robertwessel2@yahoo.com> writes:
> On Sat, 4 Feb 2017 11:24:39 -0800 (PST), bart4858@gmail.com wrote:
>
>> Yet, if such a format had been available from the start as well as
>> the usual formats, it would have been hailed as a brilliant bit of
>> design. There wouldn't have been naysayers denigrating it because it
>> only works in 99% of situations.
>
> Your experience may well be different than mine, but I'd estimate that
> far fewer than half of our uses of *printf have literal format
> strings. Internationalization, and all that.
>
> Perhaps something more like a standard macro-ish* device that can
> extract the type, and leaves it as a parameter that *printf can read.
> perhaps something like:
>
> printf("%$\n", PRINTFTYPE(v, "05"));
>
> Where the "macro" would exand to something corresponding to type
> necessary type. The second parameter would be optional, but in the
> case of an int that would expand to:
>
> printf("%$\n", "05d", v);
>
> which printf would then process as if it had been coded:
>
> printf("%05d\n", v);
>
> Clearly there are some issues to work out there (the base, length and
> type are all a bit mixed together, for example).
This is an interesting idea. See my reply to your later message
in the thread on extending printf.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-09 18:04 +0000 |
| Message-ID | <o7iari$qv0$1@dont-email.me> |
| In reply to | #103187 |
On 05/02/2017 10:08, Robert Wessel wrote:
> On Sat, 4 Feb 2017 11:24:39 -0800 (PST), bart4858@gmail.com wrote:
>
>> Yet, if such a format had been available from the start as well as the usual formats, it would have been hailed as a brilliant bit of design. There wouldn't have been naysayers denigrating it because it only works in 99% of situations.
>
>
> Your experience may well be different than mine, but I'd estimate that
> far fewer than half of our uses of *printf have literal format
> strings. Internationalization, and all that.
Depends how you do the internationalisation. My apps were expected to
work in different (western European) languages, and while not in C, used
a scheme of their own. In C/printf terms, an English printf line such as
this (and using my %? extension):
printf("Age: %?, Forename: %?, Surname: %?\n",
age, name1, name2);
would be internationalised as:
printf(/"Age: %?, Forename: %?, Surname: %?\n",
age, name1, name2);
So virtually no difference, except that the special operator "/" was
used (this can be a function in C) to transform the format string.
The compiler needs to convert the %? into the appropriate format
specifiers (and would need to recognise the / operator or function).
For English, the output is the same. For Italian (the only other
language I know off-hand), it would be translated via '/' and a lookup
dictionary** into:
"Eta`: %xx, Nome: %xx, Cognome: %xx\n"
The 'xx' are what the compiler has inserted. (The translator I used
preserved leading/trailing whitespace, punctuation, and capitalisation,
and the same would need to be done with embedded format specifiers.)
I believe that extra positional codes can be added in the translation
if, for example, Cognome has to come before Nome.
Anyway this is just an idea for the compiler to still help with format
codes, even with internationalised programs.
(** Generated by scanning the source for /"...." strings, and building a
list to be filled in by a human translator.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-05 18:07 +0000 |
| Message-ID | <o77pi1$o0q$1@dont-email.me> |
| In reply to | #103145 |
On 04/02/2017 16:36, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> And I wish I could understand what you're talking about. > > I don't think it's complicated. I wanted to get you to acknowledge that > language design is more complex than you seem to think. .... > This seems to be a pattern. Your criticisms almost always lack any > appreciation of the wider context. If it's not good for you now, it > must be a bad idea. Perhaps it's time to repost my list of quirks: https://github.com/bartg/langs/blob/master/C%20Quirks.md And how I deal with those issues in my alternate language: https://github.com/bartg/langs/blob/master/C%20Quirks%20in%20M.md These are more quirks then a comprehensive list of bad design examples from C, but is enough I think. > I wanted to get you to acknowledge that > language design is more complex than you seem to think. Yet I managed to effortlessly deal with all those quirky aspects of C. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-05 21:55 +0000 |
| Message-ID | <87shnse210.fsf@bsb.me.uk> |
| In reply to | #103220 |
BartC <bc@freeuk.com> writes: <snip> > Perhaps it's time to repost my list of quirks: > > https://github.com/bartg/langs/blob/master/C%20Quirks.md Just a note to anyone learning C: these notes are not designed to help explain any of the unusual things about C. Sometimes they do the opposite. It is a polemic rather than a technical exposition, as you will see from the tone. <snip> > On 04/02/2017 16:36, Ben Bacarisse wrote: >> I wanted to get you to acknowledge that >> language design is more complex than you seem to think. > > Yet I managed to effortlessly deal with all those quirky aspects of C. But C is one of the most successful designs in the history of programming languages. Would it have been had you been in charge from, say, 1976? It's not hard to "fix" C (though what that means will vary from person to person), what DMR realised is that C should not be fixed (if it was going to have a long life). I'm sure that caused him some pain over the decades, but it paid off. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-05 23:07 +0000 |
| Message-ID | <o78b4h$ue4$1@dont-email.me> |
| In reply to | #103248 |
On 05/02/2017 21:55, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> Yet I managed to effortlessly deal with all those quirky aspects of C. > > But C is one of the most successful designs in the history of > programming languages. There was little competition for that sort of language. I create a few of my own (I'm sure many did), but those were private in-house ones. (I don't think even my boss knew much about them; he only cared about my productivity. And saving money.) > Would it have been had you been in charge from, > say, 1976? I don't know. But it's common for technologies to become popular even when they're not the best. Eg. 8086 series instead of the elegant 32032 (Natsemi) or Z80000 (Zilog device that was abandoned; not the Z8000) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-02-03 01:02 -0800 |
| Message-ID | <ddea45c7-7b2a-4167-aa87-e7ad9e9e0099@googlegroups.com> |
| In reply to | #102998 |
On Friday, February 3, 2017 at 12:16:22 AM UTC, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > > Why do you say that? What evidence is there that the designers of C > thought it was supposed to be used as an intermediate language? Do you > know of any evidence that the C committee made any decisions because it > supposed C would be used like that? > Some scripting languages like Lua omitted goto (we're a modern, structured programming language, this construct is obsolete they said, in a superior kind of way) only to put it back in the language specification to make it easier for automatic tools to generate Lua script. > > If not, it is possible that a whole slew of your complaints about C are > rooted in your bad experience of C not doing what the people involved in > its design never thought it was supposed to do. > C is a natural choice for an intermediate language, and yacc has been around for ages. > > > Which print format should they use? PRId64 is not an option as there > > is no C compiler involved. > > Since they know the integer is 64 bits a format of "%lld" and a cast to > (long long int) will be safe. Of course if they don't know what systems > is being used this is likely to the least of the problems. > Variable integer sizes cause a ridiculous amount of fuss for something so trivial. Once you know you can index any array, you don't need another type, and the problems fall away.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-03 22:07 +1300 |
| Message-ID | <efiviqFh1v7U1@mid.individual.net> |
| In reply to | #103007 |
On 02/ 3/17 10:02 PM, Malcolm McLean wrote: >> > Variable integer sizes cause a ridiculous amount of fuss for something > so trivial. Once you know you can index any array, you don't need another > type, and the problems fall away. Until you encounter the real world. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-03 11:25 +0100 |
| Message-ID | <o71ln5$lfe$1@dont-email.me> |
| In reply to | #103008 |
On 03/02/17 10:07, Ian Collins wrote: > On 02/ 3/17 10:02 PM, Malcolm McLean wrote: >>> >> Variable integer sizes cause a ridiculous amount of fuss for something >> so trivial. Once you know you can index any array, you don't need another >> type, and the problems fall away. > > Until you encounter the real world. > Malcolm doesn't live in the real world. On his planet, numbers are either limited to 3 for things you can think about, or they are array indexes. There is nothing in-between.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-02-03 04:26 -0800 |
| Message-ID | <2c4de71d-8e15-49c9-83c6-da14e15ccde7@googlegroups.com> |
| In reply to | #103013 |
On Friday, February 3, 2017 at 10:25:33 AM UTC, David Brown wrote: > On 03/02/17 10:07, Ian Collins wrote: > > On 02/ 3/17 10:02 PM, Malcolm McLean wrote: > >>> > >> Variable integer sizes cause a ridiculous amount of fuss for something > >> so trivial. Once you know you can index any array, you don't need another > >> type, and the problems fall away. > > > > Until you encounter the real world. > > > > Malcolm doesn't live in the real world. On his planet, numbers are > either limited to 3 for things you can think about, or they are array > indexes. There is nothing in-between. > Tetration is really beyond our capabilities, and of the ability of our machines to handle. So it's one, two, three ... many. Integers (not "scaled integers", which are not integers but representations of real or occasionally rational numbers) almost always end up in an index calculation somewhere, even if it's hidden. Arrays are by far and away the most common data structure.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-02-03 12:36 +0000 |
| Message-ID | <o71tdt$i3r$1@dont-email.me> |
| In reply to | #103017 |
On 03/02/17 12:26, Malcolm McLean wrote: > On Friday, February 3, 2017 at 10:25:33 AM UTC, David Brown wrote: >> On 03/02/17 10:07, Ian Collins wrote: >>> On 02/ 3/17 10:02 PM, Malcolm McLean wrote: >>>>> >>>> Variable integer sizes cause a ridiculous amount of fuss for something >>>> so trivial. Once you know you can index any array, you don't need another >>>> type, and the problems fall away. >>> >>> Until you encounter the real world. >>> >> >> Malcolm doesn't live in the real world. On his planet, numbers are >> either limited to 3 for things you can think about, or they are array >> indexes. There is nothing in-between. >> > Tetration is really beyond our capabilities, and of the ability of our > machines to handle. So it's one, two, three ... many. That may be true of Discworld trolls (and quite possibly Usenet trolls), but it's not true of good programmers. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-02-03 04:59 -0800 |
| Message-ID | <81ec15dd-a9c9-4276-a221-407a1b080e8f@googlegroups.com> |
| In reply to | #103018 |
On Friday, February 3, 2017 at 12:37:00 PM UTC, Richard Heathfield wrote: > On 03/02/17 12:26, Malcolm McLean wrote: > > On Friday, February 3, 2017 at 10:25:33 AM UTC, David Brown wrote: > >> On 03/02/17 10:07, Ian Collins wrote: > >>> On 02/ 3/17 10:02 PM, Malcolm McLean wrote: > >>>>> > >>>> Variable integer sizes cause a ridiculous amount of fuss for something > >>>> so trivial. Once you know you can index any array, you don't need another > >>>> type, and the problems fall away. > >>> > >>> Until you encounter the real world. > >>> > >> > >> Malcolm doesn't live in the real world. On his planet, numbers are > >> either limited to 3 for things you can think about, or they are array > >> indexes. There is nothing in-between. > >> > > Tetration is really beyond our capabilities, and of the ability of our > > machines to handle. So it's one, two, three ... many. > > That may be true of Discworld trolls (and quite possibly Usenet trolls), > but it's not true of good programmers. > No, because it's easy enough to construct something with more than three levels of nesting by coding as you go, like a child making an intricate lego model by adding brick after brick with no real rhyme or reason or set plan. The skill is to write code that appears simple to everyone else reading it.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-02-03 13:09 +0000 |
| Message-ID | <o71vav$p8t$1@dont-email.me> |
| In reply to | #103021 |
On 03/02/17 12:59, Malcolm McLean wrote: > On Friday, February 3, 2017 at 12:37:00 PM UTC, Richard Heathfield wrote: >> On 03/02/17 12:26, Malcolm McLean wrote: >>> On Friday, February 3, 2017 at 10:25:33 AM UTC, David Brown wrote: >>>> On 03/02/17 10:07, Ian Collins wrote: >>>>> On 02/ 3/17 10:02 PM, Malcolm McLean wrote: >>>>>>> >>>>>> Variable integer sizes cause a ridiculous amount of fuss for something >>>>>> so trivial. Once you know you can index any array, you don't need another >>>>>> type, and the problems fall away. >>>>> >>>>> Until you encounter the real world. >>>>> >>>> >>>> Malcolm doesn't live in the real world. On his planet, numbers are >>>> either limited to 3 for things you can think about, or they are array >>>> indexes. There is nothing in-between. >>>> >>> Tetration is really beyond our capabilities, and of the ability of our >>> machines to handle. So it's one, two, three ... many. >> >> That may be true of Discworld trolls (and quite possibly Usenet trolls), >> but it's not true of good programmers. >> > No, because it's easy enough to construct something with more than > three levels of nesting by coding as you go, like a child making an > intricate lego model by adding brick after brick with no real rhyme or > reason or set plan. Is that how you write programs? I hope not. I offer as a proof that it is possible to think about more than three things at once the fact that even my *fingers* can think about 26 things all at once. More, if you include shift states and punctuation. As for your theory of nesting, that's been debunked many times before. > The skill is to write code that appears simple to everyone else reading > it. Now /that/ is true, but "simple" and "no more than three levels of nesting" are not synonyms. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-02-03 05:24 -0800 |
| Message-ID | <a5b549c7-b38c-420d-9b61-4cdf8683318b@googlegroups.com> |
| In reply to | #103026 |
On Friday, February 3, 2017 at 1:09:34 PM UTC, Richard Heathfield wrote: > On 03/02/17 12:59, Malcolm McLean wrote: > > > As for your theory of nesting, that's been debunked many times before. > People have claimed that it is wrong. To be fair, Ben Bacarisse provided a highly contrived example using symmetry and line patterning to show that about twenty levels of nesting could be "eyeballed" under certain circumstances. But actual evidence that I am wrong has been thin, and no-one has offered superior ways of determining the limit. > > > The skill is to write code that appears simple to everyone else reading > > it. > > Now /that/ is true, but "simple" and "no more than three levels of > nesting" are not synonyms. > Nesting that is simple to follow without examination (to illustrate the difference, most people can recognise about seven objects without counting them, though you can count up to twenty of thirty randomly scattered unlabellable objects, and several hundred labellable ones). That's one prerequisite for simple code. But it's not the only factor that can make code hard to follow. There's also the rule of two. Identifiers need to be binary at most (Richard Heathfield, not Richard Archibald Baldwick Charles David Edmund Frederick Gideon Heathfield)
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-02-03 13:41 +0000 |
| Message-ID | <o72169$fr$1@dont-email.me> |
| In reply to | #103027 |
On 03/02/17 13:24, Malcolm McLean wrote: > On Friday, February 3, 2017 at 1:09:34 PM UTC, Richard Heathfield wrote: >> On 03/02/17 12:59, Malcolm McLean wrote: >>> >> As for your theory of nesting, that's been debunked many times before. >> > People have claimed that it is wrong. > To be fair, Ben Bacarisse provided a highly contrived example using symmetry > and line patterning to show that about twenty levels of nesting could be "eyeballed" > under certain circumstances. But actual evidence that I am wrong has been thin, > and no-one has offered superior ways of determining the limit. >> >>> The skill is to write code that appears simple to everyone else reading >>> it. >> >> Now /that/ is true, but "simple" and "no more than three levels of >> nesting" are not synonyms. >> > Nesting that is simple to follow without examination (to illustrate the difference, > most people can recognise about seven objects without counting them, I can recognise all the objects on my desk without counting them. There are dozens, at least. > though you can count up to twenty of thirty randomly scattered unlabellable > objects, and several hundred labellable ones). No, I can count all of them. That's what counting is /for/. > That's one prerequisite for > simple code. But it's not the only factor that can make code hard to follow. > > There's also the rule of two. Identifiers need to be binary at most (Richard Heathfield, > not Richard Archibald Baldwick Charles David Edmund Frederick Gideon Heathfield) Oh dear. I'd better change my name by deed poll, then, because I am burdened with two middle names that contravene your rule. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web