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 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-04 14:26 -0800 |
| Message-ID | <89087ef0-28b2-4c88-a8f9-337cb74af45b@googlegroups.com> |
| In reply to | #103170 |
On Saturday, February 4, 2017 at 3:42:15 PM UTC-6, Malcolm McLean wrote:
> Almost never have I seen variadic functions in C used for anything other
> than implementing printf() style functions. it shows the power and
> convenience of the format string that an entire language feature
> exists to support it, and that very few people suggest removing
> such functionality.
I don't think variadic functions were included from the earliest days of c
(and its predecessor B) for the purpose of supporting printf. Instead,
it follows from the fact that it was easier to have calling code lay out
arguments in a convenient format and let the called code use them as it saw
fit, than for the calling code to keep track of what kinds of arguments
any particular function would be expecting.
Given the code:
int someFunction(x,y)
int x,y;
{
int a,b,c;
...
}
a compiler for the PDP-11 or similar machine with a downward-growing stack
would keep track of the stack pointer value when someFunction was entered
and subtract from it enough space for variables a, b, and c. The stack,
from shallowest to deepest, would look like:
c b a pc x y
where "pc" is the address of the calling code. Code which was supposed to
call someFunction(1,2); would push the values 2 and 1, in that order (push
arguments right-to-left when using a downward-growing stack), call the
function, and then pop two integers from the stack. During its execution,
the function's variable x would coincide with the last argument pushed (if
any), and its variable y with the next-to-last argument (if any). If
fewer than two arguments were pushed and the function used variably y, that
would trash something on the caller's stack. If, however, the function
never used argument y it wouldn't matter if the caller pushed it.
There are some platforms for which this approach to argument passing would
not be practical, and consequently the C Standard does not require it.
Nonetheless, throughout the 1980s there was a very strong tendency that at
least in the microcomputer area, compilers for machines which could use
this convention, did use this convention (such machines include the 8088,
Z80, 68000, 68HC09, 68HC11, etc.) Some people would insist that doesn't
really mean it was any kind of "standard", but the level of consistency
would make it hard to call it anything else. It certainly was not mere
"happenstance".
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-04 23:27 +0000 |
| Message-ID | <o75nub$4ft$1@dont-email.me> |
| In reply to | #103167 |
On 04/02/2017 21:08, Ben Bacarisse wrote:
> bart4858@gmail.com writes:
[Go's %v format]
>> Actually I don't know what it does. Perhaps you can enlighten me as to
>> how it differs from my %? proposal when it comes to printing strings
>> and scalar values.
>
> Go has run-time type information so %v works in all the usual
> situations. Compile (or just run) this
>
> package main
>
> import ("os"; "fmt")
>
> func main() {
> fmt.Printf(os.Args[1] + "\n", 42, 24.24)
> }
>
> with various format strings on the command line to to what's going on.
> Some examples:
>
> $ ./fmt '%d %f'
> 42 24.240000
> $ ./fmt '%v %v'
> 42 24.24
> $ ./fmt '%T %T'
> int float64
> $ ./fmt '%d %d'
> 42 %!d(float64=24.24)
OK. C is a lower level language. Adding automatic runtime type info is
expensive. Even doing it for dedicated language features such as print,
I think is overkill.
The most important and useful thing is to do normal everyday printing of
expressions, not using runtime format strings or using v*printf (I can't
even remember what they do; I'd have to look them up).
But apparently these specialised uses are so important, that you are
happy for the ordinary uses of printf to be compromised (/having/ to get
just the right format, having to maintain it, having to stick ugly great
PRIidi64s in it).
The fact that combining runtime format strings, that can't be checked,
and variadic functions is a recipe for disaster isn't important.
So, what would happen if my %? feature became available overnight?
(1) It could be used to ease the burden of getting formats just right,
or having to keep changing them as types change in a different part
of the program.
(2) For runtime formats or v*printf functions, they can't use %?, so
nothing changes.
(3) Or people could entirely ignore it, as %? is optional
So either nothing happens, or there is a benefit. What's the downside? I
can't see it. You just don't like it because it's not a perfect
solution, and because it can't be as good as Go.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-05 00:18 +0000 |
| Message-ID | <87mve1fq1w.fsf@bsb.me.uk> |
| In reply to | #103173 |
BartC <bc@freeuk.com> writes:
> On 04/02/2017 21:08, Ben Bacarisse wrote:
>> bart4858@gmail.com writes:
>
> [Go's %v format]
>>> Actually I don't know what it does. Perhaps you can enlighten me as to
>>> how it differs from my %? proposal when it comes to printing strings
>>> and scalar values.
>>
>> Go has run-time type information so %v works in all the usual
>> situations. Compile (or just run) this
>>
>> package main
>>
>> import ("os"; "fmt")
>>
>> func main() {
>> fmt.Printf(os.Args[1] + "\n", 42, 24.24)
>> }
>>
>> with various format strings on the command line to to what's going on.
>> Some examples:
>>
>> $ ./fmt '%d %f'
>> 42 24.240000
>> $ ./fmt '%v %v'
>> 42 24.24
>> $ ./fmt '%T %T'
>> int float64
>> $ ./fmt '%d %d'
>> 42 %!d(float64=24.24)
>
> OK. C is a lower level language. Adding automatic runtime type info is
> expensive. Even doing it for dedicated language features such as
> print, I think is overkill.
>
> The most important and useful thing is to do normal everyday printing
> of expressions, not using runtime format strings or using v*printf (I
> can't even remember what they do; I'd have to look them up).
>
> But apparently these specialised uses are so important, that you are
> happy for the ordinary uses of printf to be compromised (/having/ to
> get just the right format, having to maintain it, having to stick ugly
> great PRIidi64s in it).
No. How do you conclude that? (You do this a lot -- you take a
detailed remark and spin from that some whole imagined position that I
must hold.)
> 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.
> So, what would happen if my %? feature became available overnight?
>
> (1) It could be used to ease the burden of getting formats just right,
> or having to keep changing them as types change in a different part
> of the program.
>
> (2) For runtime formats or v*printf functions, they can't use %?, so
> nothing changes.
>
> (3) Or people could entirely ignore it, as %? is optional
>
> So either nothing happens, or there is a benefit. What's the downside?
> I can't see it. You just don't like it because it's not a perfect
> solution, and because it can't be as good as Go.
Why do you think I don't like it?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-02-04 19:56 -0800 |
| Message-ID | <ffbf7766-c6a1-479b-aa1e-7b11103a9484@googlegroups.com> |
| In reply to | #103174 |
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". In fact C, like most programming languages, isn't really type safe becuse there is no easy way of attaching dimensions (units) to variables. So a C compiler will let you add an amount in pounds to and amount in kilograms. It will maybe kick up a fuss if you try to assign an Employee to an EMPLOYEE, but it's stupid, it will do the same thing if you assign a Point2 to a POINT2D. Then one of my current programs has an user interface written in a Javascript-like language. So communication between C++ and the javascript is via JSON strings. Type safety really goes out of the window, even the fact that the JSON strings are strings is in fact unchecked at the point of passing to the Javascript engine. But it's not a huge problem. What I do is I have a JSON parser with a sticky error flag. To fail to find a variable sets the error flag. In theory you could write a flexible function that takes dynamic JSON, like Javascript itself, in fact in every case, failure to provide a field of a compatible type is treated as a runtime error. And you occasionally get them, in the process of developing a GUI to C++ communication. But those errors come out early. As for printf, the compiler checks the arguments and puts a little yellow warning triangle if they don't match the format string. It's a nuisance that many C++ containers (really only the std::vector, that's 95% of stl containers) returns a size_t for contents of contents. If it just returned an int the code would be so much cleaner. But it is something we can live with, and the answer is to replace the size_t with an int, not to add new format specifiers to printf().
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-05 11:01 +0000 |
| Message-ID | <87h948gau8.fsf@bsb.me.uk> |
| In reply to | #103176 |
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? What term would you use instead? Type-checked? > In fact C, like most programming languages, isn't really type > safe becuse there is no easy way of attaching dimensions (units) > to variables. Is that another term of you own devising? A more conventional use of the words would be to say that C's type system can't model (or capture) units (or dimensions). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-02-05 04:04 -0800 |
| Message-ID | <4b750f46-f27f-4f0b-8a8e-63c7ee9b8e51@googlegroups.com> |
| In reply to | #103191 |
On Sunday, February 5, 2017 at 11:02:00 AM UTC, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > 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? What term would you use instead? Type-checked? > Automatic type checking / matching. The term type safety is judgemental. It implies that if you don't use automatic type checking the program is unsafe, and who would do that? Then by corollary, a program which is type safe is "safe" in a more general sense. Like "const correctness", that's true in a way, there certainly are bugs which can be caught by type checking. But it's untrue in another sense, type mismatches aren't likely to take down a project. What will take it down in unmanaged complexity, and type systems contribute to that. That's why B64 will have no types or a very restricted, closed list of types. (Of course it then needs a bit buffer description language, but that's a better way of achieving the same thing, which is knowing what the bits mean). > > > In fact C, like most programming languages, isn't really type > > safe because there is no easy way of attaching dimensions (units) > > to variables. > > Is that another term of you own devising? A more conventional use of > the words would be to say that C's type system can't model (or capture) > units (or dimensions). > The type system can't, the variable system of course can if you torture it enough. Which I would achieve by a process of attachment.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-05 14:03 +0000 |
| Message-ID | <87bmugg2gb.fsf@bsb.me.uk> |
| In reply to | #103193 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Sunday, February 5, 2017 at 11:02:00 AM UTC, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> > 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? What term would you use instead? Type-checked?
>>
> Automatic type checking / matching.
I'm not sure that checking is really a good enough phrase (I know I
suggested it), because it only implies some internal consistency. This
C program:
int *f(void *p) { return p; }
int main(void) { return *f(""); }
could be considered "type checked" in that it conforms to the static
type rules of the language (the only ones that can be checked
automatically).
The rather loose term "type-safe" would rule out this program and, when
applied to the language, would rule out C.
Maybe the more usual strong/weak + static/dynamic distinctions are
better overall, but some phrase that captures the fact that some type
systems (or program constructs) prevent a class of errors based solely
on the types involved seem to me to be useful.
> The term type safety is judgemental.
How can it be judgemental? All it means is a class of errors is ruled
out and, consequently, a class of programs is ruled out as well. That's
helpful of you want to avoid that class of errors and detrimental if you
want to write that class of programs. For most people is a mixture.
> It implies that if you don't
> use automatic type checking the program is unsafe, and who would
> do that? Then by corollary, a program which is type safe is "safe"
> in a more general sense.
I don't think you can throw away a useful term because some people
misunderstand it. It's obvious to any C programmer that constructs that
are not type-safe can be used correctly and therefore safely. In these
cases the term helps to highlight the extra care needed at those places
in the program.
The other half -- that type-safe code is "safe" in a more general sense
is surely not widely believed. Surely anyone with the slightest
experience of programming will know that you can have bugs in any
language no matter what the type system?
I'd argue that strong type systems make it easier to write correct code
but that's a long way from someone thinking that a type-safe program (or
language) inherently safe in any sense other than not having type errors.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-02-05 06:56 -0800 |
| Message-ID | <ab6ab488-fd43-4212-bd4d-84bd82ba78f0@googlegroups.com> |
| In reply to | #103199 |
On Sunday, February 5, 2017 at 2:03:08 PM UTC, Ben Bacarisse wrote:
>
> I don't think you can throw away a useful term because some people
> misunderstand it. It's obvious to any C programmer that constructs that
> are not type-safe can be used correctly and therefore safely. In these
> cases the term helps to highlight the extra care needed at those places
> in the program.
>
Really it's not. Many people think that if it's not type safe it's
not "safe" and if it's not const-correct it's not "correct". Which
can lead to some bizarre phenomena, the famous instance is of
course strchr().
>
> The other half -- that type-safe code is "safe" in a more general sense
> is surely not widely believed. Surely anyone with the slightest
> experience of programming will know that you can have bugs in any
> language no matter what the type system?
>
> I'd argue that strong type systems make it easier to write correct code
> but that's a long way from someone thinking that a type-safe program (or
> language) inherently safe in any sense other than not having type errors.
>
I'd actually agree with you here. It is easier to write code and
easier to write correct code in a strongly typed language. But the
problem is that the type systems can't detect type aliasing. By
that I mean
typedef struct
{
double x;
double y;
} Point2D;
typedef struct
{
double x;
double y;
} POINT2D;
in different areas of the same program. I'd also use the term "type
aliasing" a bit more broadly to refer to different representations
of the same data as well as bit-perfect aliasing. It's impossible
to avoid once you link more than one external library. And it
makes programs hard to read and necessitates a lot of working around.
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.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-05 09:01 -0800 |
| Message-ID | <409c1db4-7d38-429b-94d5-0b493afdb1ec@googlegroups.com> |
| In reply to | #103205 |
On Sunday, February 5, 2017 at 8:56:33 AM UTC-6, Malcolm McLean wrote:
> I'd actually agree with you here. It is easier to write code and
> easier to write correct code in a strongly typed language. But the
> problem is that the type systems can't detect type aliasing. By
> that I mean
>
> typedef struct
> {
> double x;
> double y;
> } Point2D;
>
> typedef struct
> {
> double x;
> double y;
> } POINT2D;
>
> in different areas of the same program. I'd also use the term "type
> aliasing" a bit more broadly to refer to different representations
> of the same data as well as bit-perfect aliasing. It's impossible
> to avoid once you link more than one external library. And it
> makes programs hard to read and necessitates a lot of working around.
>
> 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.
In C74, the behavior of the struct-member-access operators were *defined*
in terms of address offsets. If one needed a function which could operate
upon any type whose first two members were of type "double", there was no
doubt but that two functions which started off with the same members could
be used interchangeability for purposes of accessing those members.
C ended up using the same syntax, then, for two different purposes:
1. Accessing part of a structure whose layout is known to match the
corresponding part of a givens structure type.
2. Accessing part of a structure which is known to be of a certain given
type.
Since the second is a subset of the first (if the structure is known to be
of a certain type, the layout of the whole thing is guaranteed to match
that type), a compiler need not distinguish between the two usage patterns
if it simply assumes all usages follow the first pattern; unless compilers
are going to distinguish between the two usage cases, there's no need to
have the language separate them.
Modern compilers, however, prefer to assume that all usages are of the
second form. C99 seems to attept to distinguish the two forms by saying
that if two structures appear within the same union definition that should
be taken as a sign that code might be relying upon behavior of the first
usage case. The authors didn't explicitly state that intent, however, and
as a consequence gcc and clang both ignore it and do not recognize any
standard syntactical means by which code can state that it is needed.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-05 20:53 +0000 |
| Message-ID | <87zii0e4vs.fsf@bsb.me.uk> |
| In reply to | #103205 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Sunday, February 5, 2017 at 2:03:08 PM UTC, Ben Bacarisse wrote:
>>
>> I don't think you can throw away a useful term because some people
>> misunderstand it. It's obvious to any C programmer that constructs that
>> are not type-safe can be used correctly and therefore safely. In these
>> cases the term helps to highlight the extra care needed at those places
>> in the program.
>>
> Really it's not. Many people think that if it's not type safe it's
> not "safe"
Are we talking about the same thing? Do you think most C programmers
consider printf to be unsafe because it is not type-safe? If so, I'm
not sure what value the term "safe" has.
I said 'can be used correctly and therefore safely'. Your response uses
'"safe"' and I can't tell (because of the scare quotes) what you are
really getting at. To be clear, I'm not bothered if someone thinks a
construct is not "safe" provided they know it can be used correctly and
therefore safely.
> and if it's not const-correct it's not "correct". Which
> can lead to some bizarre phenomena, the famous instance is of
> course strchr().
I'm not sure I know what const-correct means but it can't have anything
to do with the types of strchr since they are simple wrong (for good
historical reasons).
>> The other half -- that type-safe code is "safe" in a more general sense
>> is surely not widely believed. Surely anyone with the slightest
>> experience of programming will know that you can have bugs in any
>> language no matter what the type system?
>>
>> I'd argue that strong type systems make it easier to write correct code
>> but that's a long way from someone thinking that a type-safe program (or
>> language) inherently safe in any sense other than not having type errors.
>>
> I'd actually agree with you here. It is easier to write code and
> easier to write correct code in a strongly typed language. But the
> problem is that the type systems can't detect type aliasing. By
> that I mean
>
> typedef struct
> {
> double x;
> double y;
> } Point2D;
>
> typedef struct
> {
> double x;
> double y;
> } POINT2D;
>
> in different areas of the same program. I'd also use the term "type
> aliasing" a bit more broadly to refer to different representations
> of the same data as well as bit-perfect aliasing. It's impossible
> to avoid once you link more than one external library. And it
> makes programs hard to read and necessitates a lot of working around.
This is a C issue and not a universal property of type systems. You
refer to "the type system" as is there is only one, but I was talking
about the general advantages of strongly-typed languages and not
specifically about C. In fact I would not say that C is strongly typed
at all (at least not statically strongly types), which is not to say
that the rules are not too tight in some areas, just that some of the
statically-checked rules are weak.
C happens to use struct tags to determine type equivalence but that is
by no means universal in type systems.
> 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?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-02-05 13:34 -0800 |
| Message-ID | <808dc4cb-bcd5-425e-8438-72695bfb3ba5@googlegroups.com> |
| In reply to | #103241 |
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". Now someone else may have proposed the same thing, but if so I'm unaware of it.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-06 11:15 +1300 |
| Message-ID | <efpmgpF1anoU1@mid.individual.net> |
| In reply to | #103243 |
On 02/ 6/17 10:34 AM, Malcolm McLean wrote: > 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". Isn't the majority of embedded C programming showing the bits, and telling us what they mean, not hiding them? 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. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-02-05 14:30 -0800 |
| Message-ID | <f96a92ee-706d-486b-9666-6163394a0429@googlegroups.com> |
| In reply to | #103251 |
W dniu niedziela, 5 lutego 2017 23:16:00 UTC+1 użytkownik Ian Collins napisał: > On 02/ 6/17 10:34 AM, Malcolm McLean wrote: > > 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". > > Isn't the majority of embedded C programming showing the bits, and > telling us what they mean, not hiding them? > > 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. > c is showing the bits, problem is a system (i mean windows) who hides large parts of the bits (more worse the interface betwean showed bits and those covered bits is also not so clean*) *it make difference
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-02-05 14:39 -0800 |
| Message-ID | <d33873fb-2ef3-44c1-9d63-8a3bc7b60703@googlegroups.com> |
| In reply to | #103253 |
W dniu niedziela, 5 lutego 2017 23:30:54 UTC+1 użytkownik fir napisał: > W dniu niedziela, 5 lutego 2017 23:16:00 UTC+1 użytkownik Ian Collins napisał: > > On 02/ 6/17 10:34 AM, Malcolm McLean wrote: > > > 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". > > > > Isn't the majority of embedded C programming showing the bits, and > > telling us what they mean, not hiding them? > > > > 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. > > > c is showing the bits, problem is a system (i mean windows) who hides large parts of the bits (more worse the interface betwean showed bits and those covered bits is also not so clean*) > > *it make difference some difference was that that coding on raw machines one really controled physics of this machine, that was great - here, on windows you controll physics of some wirtual environment (if physics of such environment may be called physics anyway) - one may have much more power in this environment and still feel unastisfied not to mention that raw fundaments of machine are usually in fact easier (smaller, more logical) than this virtual environment provided good i was coding on c64 in asm, if not that i would probably dont even know such difference (it is like being closed in artifical world and dreaming on real 'raw' one - terrible situation)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-02-05 14:58 -0800 |
| Message-ID | <cf12a6af-52cf-4c0c-ad63-7efd0c0d39b4@googlegroups.com> |
| In reply to | #103251 |
On Sunday, February 5, 2017 at 10:16:00 PM UTC, Ian Collins wrote: > On 02/ 6/17 10:34 AM, Malcolm McLean wrote: > > > 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". > > Isn't the majority of embedded C programming showing the bits, and > telling us what they mean, not hiding them? > > 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. > At the low-level hardware interface level, yes. But type systems are an attempt to abstract away the bits. To a point it is reasonable, no-one wants to stare at binary digits. Most of the bits mean strings, or integers, or flags, or graph edges, and it's reasonable to have types. Especially if the hardware supports some types directly, as all but the simplest processors do. The fatal step also seems reasonable. We have a routine which can calculate a mean. But instead of rewriting the code for every actual representation of a list of scalars, why not write a generic "mean" which can take a generic collection or sequence of scalars? It sounds so reasonable, so human-friendly, such a powerful way of getting rid of compatibility problems. The actual result is exactly the reverse. The intricate machinery for the generic mean function means that it is burdensome to understand, to use, and to integrate. And it might not even work as expected for integers. Data does represent something in the physical world. And bits do represent something physical in the machine. But the constraints are not tight. We can't easily use 18-bit integers on a typical octet-based machine. And we can't represent numbers that go up to 100,000 easily in sixteen bits. But there's wide latitude, actually we can use 32 or (usually) 64 bits for such numbers, without stressing the machine's capabilities. In the 1970s, yes, processor time was still relatively expensive. Now it's orders of magnitude cheaper, and we've also learned to design chips for higher-level programming languages rather than the other way round. There's much less need for the micro-optimisation of different integer types.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-05 15:23 -0800 |
| Message-ID | <65c62dac-84fa-4f2b-b4ed-0ac09be22cfa@googlegroups.com> |
| In reply to | #103256 |
On Sunday, February 5, 2017 at 4:59:04 PM UTC-6, Malcolm McLean wrote:
> We can't easily use 18-bit integers on a typical
> octet-based machine. And we can't represent numbers that go up
> to 100,000 easily in sixteen bits. But there's wide latitude,
> actually we can use 32 or (usually) 64 bits for such numbers,
> without stressing the machine's capabilities.
If a language let programmers specify what they need, in the level of detail
they require, it would in many cases not be that hard for compilers to supply
the shifts and masks necessary to emulate it. Code generated to emulate such
constructs would be less efficient than code using native types, but could
still be more efficient than the code a compiler would likely generate from
user code that tried to emulate such types.
For example, if there were a type "32-bit unsigned value stored as four
octets, little-endian, with padding bits cleared on write and presumed zero
on read", a compiler for a 36-bit little-endian machine could use whatever
combinations of masks, shifts, and specialized operations would be most
efficient when working with such values. If user code included functions
to pack and unpack integers to/from sequences of bytes, it may be hard for
a compiler to recognize that something like:
stuff32(&foo.x, fetch32(&foo.x)+1u);
might be more efficiently handled by incrementing each byte, wrapping at 255,
and stopping after any byte ends up non-zero or four bytes have been done.
If the platform could process the increments and conditional branches more
efficiently than the packing and unpacking operations, however, a compiler
for that platform could take advantage of that.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-02-05 15:40 -0800 |
| Message-ID | <7920d523-9bb8-4db4-bfaa-e74ed1ff6baf@googlegroups.com> |
| In reply to | #103260 |
On Sunday, February 5, 2017 at 11:23:28 PM UTC, supe...@casperkitty.com wrote: > On Sunday, February 5, 2017 at 4:59:04 PM UTC-6, Malcolm McLean wrote: > > We can't easily use 18-bit integers on a typical > > octet-based machine. And we can't represent numbers that go up > > to 100,000 easily in sixteen bits. But there's wide latitude, > > actually we can use 32 or (usually) 64 bits for such numbers, > > without stressing the machine's capabilities. > > If a language let programmers specify what they need, in the > level of detail they require, it would in many cases not be that > hard for compilers to supply the shifts and masks necessary to > emulate it. Code generated to emulate such constructs would be less > efficient than code using native types, but could still be more > efficient than the code a compiler would likely generate from > user code that tried to emulate such types. > > For example, if there were a type "32-bit unsigned value stored > as four octets, little-endian, with padding bits cleared on write > and presumed zero on read", a compiler for a 36-bit little-endian > machine could use whatever combinations of masks, shifts, and > specialized operations would be most efficient when working with > such values. If user code included functions to pack and unpack > integers to/from sequences of bytes, it may be hard for > a compiler to recognize that something like: > > stuff32(&foo.x, fetch32(&foo.x)+1u); > > might be more efficiently handled by incrementing each byte, wrapping > at 255, and stopping after any byte ends up non-zero or four bytes > have been done. > If the platform could process the increments and conditional branches more > efficiently than the packing and unpacking operations, however, a compiler > for that platform could take advantage of that. > That's essentially my idea for B64. All the variables, the identifiers to which you can apply arithmetical and logical operations, will be 64 bit. But for memory efficiency and interoperability with other languages, it will be possible to create bit buffers with arbitrary bits, described by a bit buffer description language which is a souped-up struct. You'll then have standard library functions for access into the bit buffer. Which will include things like get16le(). It will be possible to attach the wrong bit buffer description to a bit buffer, there won't be that type safety, but in reality such a bug will likely be caught early. However there are still lots of questions. You could for example pass the bit buffer descriptions at runtime, making the language effectively dynamically typed. Whilst a bit buffer "handle" is obviously a 64 bit pointer, there's also the issue of how to represent graph edges in the bit buffer, and if they can refer to foreign bit buffers.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-05 15:05 -0800 |
| Message-ID | <9a294361-3210-4508-b534-b34769926c7c@googlegroups.com> |
| In reply to | #103251 |
On Sunday, February 5, 2017 at 4:16:00 PM UTC-6, Ian Collins wrote: > Isn't the majority of embedded C programming showing the bits, and > telling us what they mean, not hiding them? Unfortunately, some compiler writers don't seem to think that quality compilers--even for embedded systems--need to let programmers *reliably* access the bits without jumping through absurd hoops, and I'm worried that attitude may be contagious. One of the problems I think is that on most systems most constructs in C have exactly one blindingly-obvious meaning, or else have two which would be interchangeable in many situations, that in the absence of optimization compilers would behave predictably and consistently with or without a standard. In the days before aggressive optimizers, there was no need to distinguish between "Interpret two bytes of storage as a 16-bit value and fetch them" from "Fetch the value of a uint16_t", but today there is a need to distinguish those constructs but no standard means in the language to do so.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-06 13:22 +1300 |
| Message-ID | <efptu7F1d9uU3@mid.individual.net> |
| In reply to | #103257 |
On 02/ 6/17 12:05 PM, supercat@casperkitty.com wrote: > On Sunday, February 5, 2017 at 4:16:00 PM UTC-6, Ian Collins wrote: >> Isn't the majority of embedded C programming showing the bits, and >> telling us what they mean, not hiding them? > > Unfortunately, some compiler writers don't seem to think that quality > compilers--even for embedded systems--need to let programmers *reliably* > access the bits without jumping through absurd hoops, and I'm worried > that attitude may be contagious. It isn't contagious because it isn't true... -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-02-09 07:48 -0800 |
| Message-ID | <kfnpoir5pry.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #103251 |
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.
[toc] | [prev] | [next] | [standalone]
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web