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 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2017-02-04 20:35 +0000 |
| Message-ID | <o75dv7$pmj$1@z-news.wcss.wroc.pl> |
| In reply to | #103141 |
David Brown <david.brown@hesbynett.no> wrote:
>
> Apart from you, pretty much no one considers C compilation speed to be
> an important issue - certainly not with the emphasis you give it. Yes,
> gcc is slower than lccwin. And yet for every lccwin user, there are
> probably a thousand gcc users - not including those that use gcc without
> realising it (such as behind the scene during software installation).
> Does that not tell you something?
There are people who consider compilation speed to be important.
I am among them. True, I am not writing my own compiler.
IMO there is place for fast C compiler -- one that is
significantly faster than gcc and stil generates reasonable
object code. Beside compilation speed and speed of object
code there are other qualites that compiler should have.
So the task is not easy and it is interesting to see
what Bart can achieve.
Concerning use of gcc (and other software): normally users
get the worst software they still tolerate. Worst meaning
quality factors and not features. That is really
bad software is rejected, but once software passes above
acceptance level improvements in quality give limited
benefits to the makers. Instead either software is
shipped (giving better time to market) or features
are added. But fact that features and short time to
market win marketshare does not mean that it is good.
In fact features may be bad, but once feature use
reaches a critical mass there are strong compatibility
factors which basically force everybody to have the
feature. And critical mass may be qute small:
if users of a viewer program complain that 0.1%
files do not show properly vendor may feel compeled
to add support for new feature.
To put this differently: technical and market forces
make a complex system which evolves in its own
way, sometimes against wishes of participants.
Given constraints we may live in best possible
world, but it makes sense to search for better
ways. And fact that given state of software
is accepted does not prove that it is best one
(or even good one).
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-05 21:16 +0100 |
| Message-ID | <o7814b$m7e$1@dont-email.me> |
| In reply to | #103166 |
On 04/02/17 21:35, antispam@math.uni.wroc.pl wrote: > David Brown <david.brown@hesbynett.no> wrote: >> >> Apart from you, pretty much no one considers C compilation speed to be >> an important issue - certainly not with the emphasis you give it. Yes, >> gcc is slower than lccwin. And yet for every lccwin user, there are >> probably a thousand gcc users - not including those that use gcc without >> realising it (such as behind the scene during software installation). >> Does that not tell you something? > > There are people who consider compilation speed to be important. > I am among them. True, I am not writing my own compiler. > IMO there is place for fast C compiler -- one that is > significantly faster than gcc and stil generates reasonable > object code. Beside compilation speed and speed of object > code there are other qualites that compiler should have. > So the task is not easy and it is interesting to see > what Bart can achieve. Certainly no one ever complained about a compiler that is /too/ fast! But Bart is the only person I know who seems to judge compilers solely on the basis of compiler speed. Everything else appears to be irrelevant to him. (As I have mentioned before, compile times for C++ are much more relevant and much more of an issue for users.) > > Concerning use of gcc (and other software): normally users > get the worst software they still tolerate. Worst meaning > quality factors and not features. That is really > bad software is rejected, but once software passes above > acceptance level improvements in quality give limited > benefits to the makers. Instead either software is > shipped (giving better time to market) or features > are added. But fact that features and short time to > market win marketshare does not mean that it is good. That's an interesting point. For a while, gcc development suffered from that - features were added, but certain "quality factors" did not improve. Compile speed dropped with each version, and while new versions got more warnings, they became less decipherable. I've noticed a change since clang began to get popular with key points being its faster compilation speed, and clearer error and warning messages. gcc has caught up on both accounts - meanwhile, clang has improved its optimisation (but got slower at compilation). And the two projects have cooperated on advanced features such as the sanitisers. The friendly competition and cooperation between them has helped both projects. > In fact features may be bad, but once feature use > reaches a critical mass there are strong compatibility > factors which basically force everybody to have the > feature. And critical mass may be qute small: > if users of a viewer program complain that 0.1% > files do not show properly vendor may feel compeled > to add support for new feature. > > To put this differently: technical and market forces > make a complex system which evolves in its own > way, sometimes against wishes of participants. > Given constraints we may live in best possible > world, but it makes sense to search for better > ways. And fact that given state of software > is accepted does not prove that it is best one > (or even good one). > >
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-04 00:51 +0000 |
| Message-ID | <87a8a2ixs5.fsf@bsb.me.uk> |
| In reply to | #103077 |
BartC <bc@freeuk.com> writes: > On 03/02/2017 19:32, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> I would have introduced the "%?" format or some such code > >>> That would have taken care of the vast majority of cases. > >> And the vXprintf functions won't work either. > > "...in the vast majority of cases...". > >>> then it would be >>> necessary to properly support the basic types that are being >>> printed. Examples: >>> >>> %ld long int >>> %lld long long int >> >> This is what C does now. > > But not very well. What do you mean? It does it just fine as far as I'm aware. > You snipped the I64 format (%I64d actually) which > matches the int64_t type. Of course I did -- it's got nothing to do with my question: What would you have done when a length modifier first became needed? Your only workable suggestion so far is to do it exactly the way C did it -- the design you described as a bad idea. <snip> > Out of interest, how would /you/ write portable code to print a > int64_t value? What mysterious meaning for "portable" do you have in mind that would make the answer any different from the obvious one -- to use the standard macro? Your problem appears to be that you have a buggy C implementation. You don't need a portable solution, you need a magic one. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-04 01:20 +0000 |
| Message-ID | <o73a5p$mci$1@dont-email.me> |
| In reply to | #103107 |
On 04/02/2017 00:51, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> But not very well. > > What do you mean? It does it just fine as far as I'm aware. The subthread started with the requirement to eliminate warnings, after a compiler has been asked to show extra warnings. >> You snipped the I64 format (%I64d actually) which >> matches the int64_t type. > > Of course I did -- it's got nothing to do with my question: What would > you have done when a length modifier first became needed? Your only > workable suggestion so far is to do it exactly the way C did it -- the > design you described as a bad idea. My suggestion was to have a format code exactly matching int64_t. That means using I64d on all implementations. That's not how C does it because it only exists on Windows implementations of C. The C way is to use only %ld or %lld (putting aside where it's not recognised) and relying on the user giving up on using a conventional format string, and choosing from an unwieldy set of MACRO NAMES to break up the format. > <snip> >> Out of interest, how would /you/ write portable code to print a >> int64_t value? > > What mysterious meaning for "portable" do you have in mind that would > make the answer any different from the obvious one -- to use the > standard macro? All the open source C I've seen, I've never come across a PRIxxxx macro being used. Or maybe none of it was portable. I don't want to be the first... -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-04 01:48 +0000 |
| Message-ID | <87wpd6hgkr.fsf@bsb.me.uk> |
| In reply to | #103111 |
BartC <bc@freeuk.com> writes: > On 04/02/2017 00:51, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> But not very well. >> >> What do you mean? It does it just fine as far as I'm aware. > > The subthread started with the requirement to eliminate warnings, > after a compiler has been asked to show extra warnings. But again, that's got nothing to do with this sub-sub-thread. You said %ld was a "bad idea" so I asked specifically what you would have done when a length modifier first became needed as C evolved. As part of you non-answer you said "it would be necessary to properly support the basic types that are being printed" and gave the examples: %ld long int %lld long long int This is what C does and it does it well. These formats properly support the basic types that are being printed. Any compiler warnings are just a distraction in this particular exchange because *any* solution could give rise to daft warnings from a silly or broken compiler. >>> You snipped the I64 format (%I64d actually) which >>> matches the int64_t type. >> >> Of course I did -- it's got nothing to do with my question: What would >> you have done when a length modifier first became needed? Your only >> workable suggestion so far is to do it exactly the way C did it -- the >> design you described as a bad idea. > > My suggestion was to have a format code exactly matching int64_t. That > means using I64d on all implementations. That's not how C does it > because it only exists on Windows implementations of C. Then you did not understand my question. I64d would have been wrong when a length modifier became needed. What would you have done instead of the "bad idea" of using %ld? <snip> >>> Out of interest, how would /you/ write portable code to print a >>> int64_t value? >> >> What mysterious meaning for "portable" do you have in mind that would >> make the answer any different from the obvious one -- to use the >> standard macro? > > All the open source C I've seen, I've never come across a PRIxxxx > macro being used. Or maybe none of it was portable. I don't want to be > the first... The need for int64_t is quite specialised. Most people are perfectly happy with long long int, so the very specific type macros are, indeed, rarely used. (I'm wondering why you need it, but that's a whole other can of worms.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-04 02:10 +0000 |
| Message-ID | <o73d32$t7s$1@dont-email.me> |
| In reply to | #103112 |
On 04/02/2017 01:48, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > But again, that's got nothing to do with this sub-sub-thread. You said > %ld was a "bad idea" so I asked specifically what you would have done > when a length modifier first became needed as C evolved. I gave some ideas, some extending the *printf scheme and others with a different approach (adding special print features but that would have been too radical for C). >> All the open source C I've seen, I've never come across a PRIxxxx >> macro being used. Or maybe none of it was portable. I don't want to be >> the first... > > The need for int64_t is quite specialised. Most people are perfectly > happy with long long int, so the very specific type macros are, indeed, > rarely used. (I'm wondering why you need it, but that's a whole other > can of worms.) If you're implementing a statically typed language, then it needs to know what the sizes of those types are. Plus, a related aspect, the offsets and alignment needs of struct members. But it you then choose as a target, an intermediate language which is reluctant for you to specify the width of primitive types, or the precise offset of a struct member, then you're going to get problems. That's why I use int64_t (as well as int32-t, pack(1) and the rest), but then they apparently are not without their problems. (However I also redefine types such as int64_t as the typedef int64, which Keith picked me up on. But the reason is it's then easier to change the definition of int64, as it's in one place.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2017-02-04 02:56 +0000 |
| Message-ID | <o73fsv$mcq$1@z-news.wcss.wroc.pl> |
| In reply to | #103114 |
BartC <bc@freeuk.com> wrote:
> On 04/02/2017 01:48, Ben Bacarisse wrote:
> >
> > The need for int64_t is quite specialised. Most people are perfectly
> > happy with long long int, so the very specific type macros are, indeed,
> > rarely used. (I'm wondering why you need it, but that's a whole other
> > can of worms.)
>
> If you're implementing a statically typed language, then it needs to
> know what the sizes of those types are. Plus, a related aspect, the
> offsets and alignment needs of struct members.
Wrong. You can do static type checking without knowing sizes.
The right anwer is that you want to provide fixed size types
and want to have fixed mapping from your types to C types.
Effectively you want to turn C into your language. And you
have problem because principles behind C are different than
principles that you want for your language.
> But it you then choose as a target, an intermediate language which is
> reluctant for you to specify the width of primitive types, or the
> precise offset of a struct member, then you're going to get problems.
Well, _code generator_ needs to know sizes. If you use C compiler
as stage of your code generator, then it is enough that C ompiler
knows sizes. If you want to provide fixed size types that
easy too: either generate nonportable compiler dependent C or
use macros from standard header files. I know that you do not want
macros, but if you reject solutions offered by C that is your problem
and not C problem.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-05 01:56 +0000 |
| Message-ID | <o760kl$slu$1@dont-email.me> |
| In reply to | #103118 |
On 04/02/2017 02:56, antispam@math.uni.wroc.pl wrote: > BartC <bc@freeuk.com> wrote: >> On 04/02/2017 01:48, Ben Bacarisse wrote: >>> >>> The need for int64_t is quite specialised. Most people are perfectly >>> happy with long long int, so the very specific type macros are, indeed, >>> rarely used. (I'm wondering why you need it, but that's a whole other >>> can of worms.) >> >> If you're implementing a statically typed language, then it needs to >> know what the sizes of those types are. Plus, a related aspect, the >> offsets and alignment needs of struct members. > > Wrong. You can do static type checking without knowing sizes. > The right anwer is that you want to provide fixed size types > and want to have fixed mapping from your types to C types. > Effectively you want to turn C into your language. And you > have problem because principles behind C are different than > principles that you want for your language. > >> But it you then choose as a target, an intermediate language which is >> reluctant for you to specify the width of primitive types, or the >> precise offset of a struct member, then you're going to get problems. > > Well, _code generator_ needs to know sizes. If you use C compiler > as stage of your code generator, then it is enough that C ompiler > knows sizes. If you want to provide fixed size types that > easy too: either generate nonportable compiler dependent C or > use macros from standard header files. I know that you do not want > macros, but if you reject solutions offered by C that is your problem > and not C problem. I think a compiler would be badly handicapped if it can't found out the sizes of types, lengths of arrays, sizes of structs, offsets of elements, and values of enums, not even in the code generator if C is being produced. Because many of those will depend on things not known until a C compiler is invoked on the output. It's not impossible but the quality is going to suffer. And it makes the structure harder because for a native code target, those things need to be known before it gets to the code generator. So you need two rather different compilers. And suppose the original source has conditional code that does different things depending on the target pointer size? Now you need to translate the original language's conditional construct into the target. But it will also have to translate both branches of the conditional at the same time, so it might have two versions of code and/or declarations coexisting. It starts to get hairy. It's a problem when two compilers have to fight it out between them for who gets to do what. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-04 11:14 +0000 |
| Message-ID | <87r33egqcz.fsf@bsb.me.uk> |
| In reply to | #103114 |
BartC <bc@freeuk.com> writes: > On 04/02/2017 01:48, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >> But again, that's got nothing to do with this sub-sub-thread. You said >> %ld was a "bad idea" so I asked specifically what you would have done >> when a length modifier first became needed as C evolved. > > I gave some ideas, some extending the *printf scheme and others with a > different approach (adding special print features but that would have > been too radical for C). I've seen nothing workable being suggested. My point should be clear: you can't reasonably say a design decision is a bad one unless you understand the context and the design space in which it is made. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-04 12:00 +0000 |
| Message-ID | <o74fl0$jj6$1@dont-email.me> |
| In reply to | #103126 |
On 04/02/2017 11:14, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
>> On 04/02/2017 01:48, Ben Bacarisse wrote:
>>> BartC <bc@freeuk.com> writes:
>>
>>> But again, that's got nothing to do with this sub-sub-thread. You said
>>> %ld was a "bad idea" so I asked specifically what you would have done
>>> when a length modifier first became needed as C evolved.
>>
>> I gave some ideas, some extending the *printf scheme and others with a
>> different approach (adding special print features but that would have
>> been too radical for C).
>
> I've seen nothing workable being suggested.
What's unworkable about "%?" ? That would solve all the problems /I/ am
having and this debate would not be taking place.
You seem determined to want to prove me wrong, by bringing up the 1 in
100 or 1 in 1000 scenario where that couldn't be used. But that would be
the same with any solution.
(I've been looking at the code which generates those format-specifiers
for me, in the same way a compiler implementing "%?" would have to do. I
was surprised to see array- and struct-handling in there too. So if you
have a variable 'd' of this C struct:
typedef struct {unsigned char day, month; short year;} date;
and I say 'print d', then I get this output:
printf("(%u,%u,%d)\n",d.d,d.m,d.y);
Some things are just so easy. But no doubt the equivalent can be done in
the preprocessor...)
> My point should be clear:
> you can't reasonably say a design decision is a bad one unless you
> understand the context and the design space in which it is made.
The problems with printf are real.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-04 12:16 +0000 |
| Message-ID | <o74gjr$mcc$2@dont-email.me> |
| In reply to | #103127 |
On 04/02/2017 12:00, BartC wrote:
> typedef struct {unsigned char day, month; short year;} date;
>
> and I say 'print d', then I get this output:
>
> printf("(%u,%u,%d)\n",d.d,d.m,d.y);
Obviously, this is the output I got before I decided to expand those
member names to avoid the confusion of 'd' with member 'd'. Which didn't
work ...
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-04 13:41 +0000 |
| Message-ID | <87d1eygjk7.fsf@bsb.me.uk> |
| In reply to | #103127 |
BartC <bc@freeuk.com> writes: > On 04/02/2017 11:14, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 04/02/2017 01:48, Ben Bacarisse wrote: >>>> BartC <bc@freeuk.com> writes: >>> >>>> But again, that's got nothing to do with this sub-sub-thread. You said >>>> %ld was a "bad idea" so I asked specifically what you would have done >>>> when a length modifier first became needed as C evolved. >>> >>> I gave some ideas, some extending the *printf scheme and others with a >>> different approach (adding special print features but that would have >>> been too radical for C). >> >> I've seen nothing workable being suggested. > > What's unworkable about "%?" ? That would solve all the problems /I/ > am having and this debate would not be taking place. You have succinctly stated the problem I have with most of your criticisms of C in just a few words. I could not hope to to better. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-04 14:00 +0000 |
| Message-ID | <o74mma$bld$1@dont-email.me> |
| In reply to | #103134 |
On 04/02/2017 13:41, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > >> On 04/02/2017 11:14, Ben Bacarisse wrote: >>> BartC <bc@freeuk.com> writes: >>> >>>> On 04/02/2017 01:48, Ben Bacarisse wrote: >>>>> BartC <bc@freeuk.com> writes: >>>> >>>>> But again, that's got nothing to do with this sub-sub-thread. You said >>>>> %ld was a "bad idea" so I asked specifically what you would have done >>>>> when a length modifier first became needed as C evolved. >>>> >>>> I gave some ideas, some extending the *printf scheme and others with a >>>> different approach (adding special print features but that would have >>>> been too radical for C). >>> >>> I've seen nothing workable being suggested. >> >> What's unworkable about "%?" ? That would solve all the problems /I/ >> am having [with printf] and this debate would not be taking place. > > You have succinctly stated the problem I have with most of your > criticisms of C in just a few words. I could not hope to to better. And I wish I could understand what you're talking about. As I said, you seem determined to shoot down anything I suggest. But that doesn't seem to be anything new in this group. Isn't is funny that those who from time to time post links to substantial personal projects of their own are also those who seem to attract flak? Yet I rarely if ever see similar offerings from those doing the attacking. Some like to criticise - often for good reason - while others want to criticise those who criticise. As though the Language and its Standard are sacrosanct. (BTW, what does the "%v" format code do in the Go language...?) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-02-04 07:55 -0800 |
| Message-ID | <b57e345f-438b-4ae5-bca9-19e22bdbf12f@googlegroups.com> |
| In reply to | #103135 |
On Saturday, February 4, 2017 at 2:00:26 PM UTC, Bart wrote: > > Isn't is funny that those who from time to time post links to > substantial personal projects of their own are also those who seem to > attract flak? Yet I rarely if ever see similar offerings from those > doing the attacking. > This is it, Bart, myself and, to be fair, Rick have personal programming projects we work on. So we tend to understand dependency hell, the importance of keeping code clean and simple, the sheer nuisance caused by adding things like new integer types to standards. The other posters may write code professionally, but those who do generally do so for embedded projects, where the rules are a bit different.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2017-02-04 18:15 +0000 |
| Message-ID | <o755oc$7kq$1@news.xmission.com> |
| In reply to | #103139 |
In article <b57e345f-438b-4ae5-bca9-19e22bdbf12f@googlegroups.com>, Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >On Saturday, February 4, 2017 at 2:00:26 PM UTC, Bart wrote: >> >> Isn't is funny that those who from time to time post links to >> substantial personal projects of their own are also those who seem to >> attract flak? Yet I rarely if ever see similar offerings from those >> doing the attacking. >> >This is it, Bart, myself and, to be fair, Rick have personal programming >projects we work on. So we tend to understand dependency hell, the >importance of keeping code clean and simple, the sheer nuisance >caused by adding things like new integer types to standards. > >The other posters may write code professionally, but those who do >generally do so for embedded projects, where the rules are a bit >different. I have always thought it was clear that the people who are actually doing something (people like you [Malcolm], Jacob [Navia], BartC, and one or two others I can't think of ATM) are precisely the ones who get sh*t from the regs. It sounds like plain old jealousy, pure & simple. Or, to put it another way: he who can, does; he who can't teaches, although in the case of this newsgroup, "bitches" would be more accurate than "teaches". Or, to try to put it charitably, it could just be that this is intended as a theoretical newsgroup, and anything that smacks of real-world use or real-world sensibilities, must be crushed. Finally, note that I doubt many of the regs here are actually writing code for a living. They're mostly fossils trying to re-live high school glory. (I kid when I say "high school", but the analogy is likely apt. I get the impression that these people are the computer-age equivalent of the high school jock who lives his adult life re-living his high school days.) Anyway, that's my 2 cents... -- The plural of "anecdote" is _not_ "data".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-05 21:41 +0100 |
| Message-ID | <o782hr$rmj$1@dont-email.me> |
| In reply to | #103155 |
On 04/02/17 19:15, Kenny McCormack wrote: > In article <b57e345f-438b-4ae5-bca9-19e22bdbf12f@googlegroups.com>, > Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >> On Saturday, February 4, 2017 at 2:00:26 PM UTC, Bart wrote: >>> >>> Isn't is funny that those who from time to time post links to >>> substantial personal projects of their own are also those who seem to >>> attract flak? Yet I rarely if ever see similar offerings from those >>> doing the attacking. >>> >> This is it, Bart, myself and, to be fair, Rick have personal programming >> projects we work on. So we tend to understand dependency hell, the >> importance of keeping code clean and simple, the sheer nuisance >> caused by adding things like new integer types to standards. >> >> The other posters may write code professionally, but those who do >> generally do so for embedded projects, where the rules are a bit >> different. > > I have always thought it was clear that the people who are actually doing > something (people like you [Malcolm], Jacob [Navia], BartC, and one or two > others I can't think of ATM) are precisely the ones who get sh*t from the > regs. It sounds like plain old jealousy, pure & simple. > > Or, to put it another way: he who can, does; he who can't teaches, although > in the case of this newsgroup, "bitches" would be more accurate than > "teaches". > > Or, to try to put it charitably, it could just be that this is intended as > a theoretical newsgroup, and anything that smacks of real-world use or > real-world sensibilities, must be crushed. > > Finally, note that I doubt many of the regs here are actually writing code > for a living. They're mostly fossils trying to re-live high school glory. > > (I kid when I say "high school", but the analogy is likely apt. I get the > impression that these people are the computer-age equivalent of the high > school jock who lives his adult life re-living his high school days.) > > Anyway, that's my 2 cents... > And it would be worth every penny, with a 2 cent discount. I can't speak for other people here, but I suspect that most actually write C code for a living, or have done so in the past. There are some that I suspect /do/ write C code professionally, but I really wish they would not. Most people in this group are fond of C. I doubt if anyone thinks it is perfect, but most find it works well enough the way it is, and enjoy working with it. And they enjoy talking about it, preferably in terms that make sense to C programmers. Personally, I have a lot of respect for the achievements of Malcolm, Bart, and (especially) Jacob. But when they write something that is completely nonsense - and usually, exactly the same nonsense that they have written dozens of times before - I see nothing wrong with pointing it out. There is going to be an inevitable bias in postings - when someone makes a point that is clearly correct, it is unlikely to draw much attention. But when they write something that is clearly wrong, people will reply to correct it. And when people post in a newsgroup with the right attitude, that's good - when someone corrects me, it is a chance to learn. I might not agree with them, and then after the discussion I have learned that other people can quite reasonably hold a different opinion on the issue. Or I might find I /do/ agree with them, and change my own habits. (At least, that's the theory...) For some people, however, corrections or different opinions apparently mean that the world is out to drag them down, and learning is out of the question.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-04 16:36 +0000 |
| Message-ID | <871svdhq12.fsf@bsb.me.uk> |
| In reply to | #103135 |
BartC <bc@freeuk.com> writes: > On 04/02/2017 13:41, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 04/02/2017 11:14, Ben Bacarisse wrote: >>>> BartC <bc@freeuk.com> writes: >>>> >>>>> On 04/02/2017 01:48, Ben Bacarisse wrote: >>>>>> BartC <bc@freeuk.com> writes: >>>>> >>>>>> But again, that's got nothing to do with this sub-sub-thread. You said >>>>>> %ld was a "bad idea" so I asked specifically what you would have done >>>>>> when a length modifier first became needed as C evolved. >>>>> >>>>> I gave some ideas, some extending the *printf scheme and others with a >>>>> different approach (adding special print features but that would have >>>>> been too radical for C). >>>> >>>> I've seen nothing workable being suggested. >>> >>> What's unworkable about "%?" ? That would solve all the problems /I/ >>> am having [with printf] and this debate would not be taking place. >> >> You have succinctly stated the problem I have with most of your >> criticisms of C in just a few words. I could not hope to to better. > > 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. When %ld became necessary you say you would have provided %?. But that only works on literal formats. You explain, here, that that would solve all *your* problems. No doubt it would, but to criticise C's evolution you need to accept that yours are not the only problems. %? does not solve the problem in any general way, just the problem you are currently concerned about where the formats are literal strings. 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. > As I said, you seem determined to shoot down anything I suggest. But > that doesn't seem to be anything new in this group. You seriously think that %? which only works with literal formats would have been the right way to handle the new types that don't promote to int (or double)? > Isn't is funny that those who from time to time post links to > substantial personal projects of their own are also those who seem to > attract flak? Yet I rarely if ever see similar offerings from those > doing the attacking. What is the point of this remark? You can not possibly be suggesting that only people who have posted personal project code have the right to comment on what you write? But if that is what you are saying, don't be so oblique about it -- come right out with it. <snip> > (BTW, what does the "%v" format code do in the Go language...?) You know what it does. I know what it does. We both know it does not do what your %? does and (I think) we both know it is not (sadly) an option for C. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bart4858@gmail.com |
|---|---|
| Date | 2017-02-04 11:24 -0800 |
| Message-ID | <618f97e1-a131-46f7-bf07-7275b40e0871@googlegroups.com> |
| In reply to | #103145 |
On Saturday, 4 February 2017 16:36:16 UTC, 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. Well, it's a bit harder when you have to jump in and fix someone else's existing language. But I've had some practice in that with C. (If and when my C translator project is at the right point (and if my health holds up), then I'll show you how %? would work.) > %? does not solve the > problem in any general way, just the problem you are currently concerned > about where the formats are literal strings. 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. > 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. > > > As I said, you seem determined to shoot down anything I suggest. But > > that doesn't seem to be anything new in this group. > > You seriously think that %? which only works with literal formats would > have been the right way to handle the new types that don't promote to > int (or double)? There are other issues with the choice of a variadic function which I won't go into here. (That also causes me grief when I call printf as a foreign function.) > > > Isn't [it] funny that those who from time to time post links to > > substantial personal projects of their own are also those who seem to > > attract flak? Yet I rarely if ever see similar offerings from those > > doing the attacking. > > What is the point of this remark? You can not possibly be suggesting > that only people who have posted personal project code have the right to > comment on what you write? I'm saying those who post projects are making suggestions and criticisms based on direct practical experience. > > (BTW, what does the "%v" format code do in the Go language...?) > > You know what it does. I know what it does. We both know it does not > do what your %? does and (I think) we both know it is not (sadly) an > option for C. 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.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-04 21:08 +0000 |
| Message-ID | <87shntfyv6.fsf@bsb.me.uk> |
| In reply to | #103163 |
bart4858@gmail.com writes:
> On Saturday, 4 February 2017 16:36:16 UTC, Ben Bacarisse wrote:
<snip>
>> %? does not solve the
>> problem in any general way, just the problem you are currently concerned
>> about where the formats are literal strings.
>
> 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.
I think you are just making that up. Do you really want to conduct a
technical discussion in that way?
>> 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.
>>
>> > As I said, you seem determined to shoot down anything I suggest. But
>> > that doesn't seem to be anything new in this group.
>>
>> You seriously think that %? which only works with literal formats would
>> have been the right way to handle the new types that don't promote to
>> int (or double)?
>
> There are other issues with the choice of a variadic function which I
> won't go into here. (That also causes me grief when I call printf as a
> foreign function.)
See below.
>> > Isn't [it] funny that those who from time to time post links to
>> > substantial personal projects of their own are also those who seem to
>> > attract flak? Yet I rarely if ever see similar offerings from those
>> > doing the attacking.
>>
>> What is the point of this remark? You can not possibly be suggesting
>> that only people who have posted personal project code have the right to
>> comment on what you write?
>
> I'm saying those who post projects are making suggestions and
> criticisms based on direct practical experience.
But you don't seem to be able (or maybe willing) to go beyond your
direct experience. There's another case above: rather than consider the
consequences for the language, as it was at the time, of introducing a
format that only works in some situations, you bring in yet another
problem those pesky C designers have thrown at you -- variadic
functions. It's all about how it's wrong for you now -- there is no
consideration of the context of the design.
Please consider it a possibility that had C been designed to be perfect
for you current use-case, it might have failed entirely.
>> > (BTW, what does the "%v" format code do in the Go language...?)
>>
>> You know what it does. I know what it does. We both know it does not
>> do what your %? does and (I think) we both know it is not (sadly) an
>> option for C.
>
> 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)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-02-04 13:41 -0800 |
| Message-ID | <fa36f765-1c0d-4b85-ac8b-3c7664630727@googlegroups.com> |
| In reply to | #103167 |
On Saturday, February 4, 2017 at 9:08:19 PM UTC, Ben Bacarisse wrote: > > But you don't seem to be able (or maybe willing) to go beyond your > direct experience. There's another case above: rather than consider the > consequences for the language, as it was at the time, of introducing a > format that only works in some situations, you bring in yet another > problem those pesky C designers have thrown at you -- variadic > functions. It's all about how it's wrong for you now -- there is no > consideration of the context of the design. > 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. However if you wish to convert a stream of bits to a stream of human-readable characters, there are many ways of doing that without any fancy programming constructs. The format string has caught on, because it;s easy to read and manipulate at the line level. Even in C++ which tried the overloaded << operator, you often see printf style format string used. So when someone messes with them, you become concerned.
[toc] | [prev] | [next] | [standalone]
Page 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web