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 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-03 14:54 +0000 |
| Message-ID | <87a8a3jpeo.fsf@bsb.me.uk> |
| In reply to | #103001 |
BartC <bc@freeuk.com> writes:
> On 03/02/2017 00:16, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>
>>> On 02/02/2017 21:06, Keith Thompson wrote:
>>>> BartC <bc@freeuk.com> writes:
>>>> [...]
>>>>> I can already write in original source:
>>>>>
>>>>> int64 a
>>>>> print a
>>>>>
>>>>> which I can translate, when I need portable output, to:
>>>>>
>>>>> int64_t a;
>>>>> printf("%lld", a)'
>>>>
>>>> That's not portable output.
>>>
>>> Well, that's the reason I'm generating C code. Otherwise I would just
>>> go the extra mile and generate native code for all my targets (there's
>>> only two or three). Using C as an intermediate language is supposed to
>>> make life easier not harder.
>>
>> Why do you say that? What evidence is there that the designers of C
>> thought it was supposed to be used as an intermediate language? Do you
>> know of any evidence that the C committee made any decisions because it
>> supposed C would be used like that?
>
> I didn't say it was designed that way. But that's how it seems to be
> used. (I know Seed7 generates C; didn't early C++ do so as well?)
So your only evidence that it is "supposed to make like easier" is that
you are not alone in using it that way? I agree that you are not alone,
but I don't think you can conclude from that that it is supposed to help
you in your task. You would be better off accepting that there will be
problems, because C is *not* supposed to be used as you are using it.
<snip>
> I think needing %d %ld %ldd etc just to print a number is bad
> idea.
I think you would get a deeper understanding if you dropped the idea
that any design is simply a "bad idea". The need for a length modifier
cropped up only when a type got introduced that was too wide to promote
to int. What would you have done at that point in C's development?
<snip>
>>> Suppose someone is calling printf as a foreign function from another
>>> language. The want to print an integer known to be 64 bits. They don't
>>> know what system they're using as /they/ want to keep things portable
>>> too.
>>>
>>> Which print format should they use? PRId64 is not an option as there
>>> is no C compiler involved.
>>
>> Since they know the integer is 64 bits a format of "%lld" and a cast to
>> (long long int) will be safe.
>
> Exactly.
I didn't realise it was a rhetorical question. I would not have
answered it had I know.
> But I can't do that because between my code and the library,
> might be a C compiler claiming it doesn't understand "%lld".
So your question was really what should a program use to print a 64-bit
int on a broken C implementation that does not have support for printing
64-bit ints? That's a harder question. Do you know the full range of
broken C implementations that you want to be able to target?
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-03 15:31 +0000 |
| Message-ID | <o727l2$p2s$1@dont-email.me> |
| In reply to | #103034 |
On 03/02/2017 14:54, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > So your only evidence that it is "supposed to make like easier" is that > you are not alone in using it that way? I agree that you are not alone, > but I don't think you can conclude from that that it is supposed to help > you in your task. You would be better off accepting that there will be > problems, because C is *not* supposed to be used as you are using it. It can't be called a high-level assembler then. But as for artificially generating C source, isn't that what the macro processor does all the time? People write impenetrable function macros where usually you don't even see the output source. And there are still plenty of problems in getting the resulting C to work as expected. > <snip> >> I think needing %d %ld %ldd etc just to print a number is bad >> idea. > > I think you would get a deeper understanding if you dropped the idea > that any design is simply a "bad idea". The need for a length modifier > cropped up only when a type got introduced that was too wide to promote > to int. What would you have done at that point in C's development? I would have introduced the "%?" format or some such code, where the compiler modifies the format string by inserting an actual format code that corresponds to the type of the argument. (For hex, a supplementary format would be needed.) That would have taken care of the vast majority of cases. When that is not possible (eg. the format string is not constant), then it would be necessary to properly support the basic types that are being printed. Examples: %ld long int %lld long long int %I64 64-bit int (I think this is used by MS) And not have the situation where you have to display 64-bit ints using either %ld or %lld", or having to use those ugly macros. (I think there's about 130 of them that an implementation has to provide, eg. "PRIuLEAST64" is defined as "llu".) This is all assuming it was necessary to stick closely to the *printf() model. >> But I can't do that because between my code and the library, >> might be a C compiler claiming it doesn't understand "%lld". > > So your question was really what should a program use to print a 64-bit > int on a broken C implementation that does not have support for printing > 64-bit ints? That's a harder question. Do you know the full range of > broken C implementations that you want to be able to target? For a while I had to use sprintf_mingw() instead of sprintf() because the latter didn't support 64-bit formats such as "%lld". That might have been on Windows XP 32-bit; I don't know if the problem is still there. (It usually manifested itself in the 2nd or 3rd generation of a compiler compiling itself and was a nightmare to track down.) That's just one instance. If other people are compiling my code, I've no idea what they might be using. But you would expect that in 2017, it would be possible to print a 64-bit number without much problem. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-03 19:32 +0000 |
| Message-ID | <87r33fhxy6.fsf@bsb.me.uk> |
| In reply to | #103038 |
BartC <bc@freeuk.com> writes: > On 03/02/2017 14:54, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >> So your only evidence that it is "supposed to make like easier" is that >> you are not alone in using it that way? I agree that you are not alone, >> but I don't think you can conclude from that that it is supposed to help >> you in your task. You would be better off accepting that there will be >> problems, because C is *not* supposed to be used as you are using it. > > It can't be called a high-level assembler then. No, it can't be. Misconceptions about C abound. <snip> >>> I think needing %d %ld %ldd etc just to print a number is bad >>> idea. >> >> I think you would get a deeper understanding if you dropped the idea >> that any design is simply a "bad idea". The need for a length modifier >> cropped up only when a type got introduced that was too wide to promote >> to int. What would you have done at that point in C's development? > > I would have introduced the "%?" format or some such code, where the > compiler modifies the format string by inserting an actual format code > that corresponds to the type of the argument. (For hex, a > supplementary format would be needed.) > > That would have taken care of the vast majority of cases. When that is > not possible (eg. the format string is not constant), And the vXprintf functions won't work either. > 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. I asked what you would do *instead* of taking this route. Your suggestion of %? does not work. You said using %ld was a bad idea but here you saying it is what you would do. <snip> >> So your question was really what should a program use to print a 64-bit >> int on a broken C implementation that does not have support for printing >> 64-bit ints? That's a harder question. Do you know the full range of >> broken C implementations that you want to be able to target? > > For a while I had to use sprintf_mingw() instead of sprintf() because > the latter didn't support 64-bit formats such as "%lld". That might > have been on Windows XP 32-bit; I don't know if the problem is still > there. (It usually manifested itself in the 2nd or 3rd generation of a > compiler compiling itself and was a nightmare to track down.) > > That's just one instance. If other people are compiling my code, I've > no idea what they might be using. But you would expect that in 2017, > it would be possible to print a 64-bit number without much problem. This does not answer my question. What range of implementations with broken 64-bit support do you want to be able to target? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-03 20:28 +0000 |
| Message-ID | <o72p26$sr3$1@dont-email.me> |
| In reply to | #103065 |
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. You snipped the I64 format (%I64d actually) which
matches the int64_t type.
At the moment, using %lld for int64_t causes a spurious warning with a
version of gcc (which may be a bug), and using it on Linux generates a
warning because there, int64_t corresponds to 'long' not 'long long'.
This code:
int64_t a=78;
printf("XXX%I64d\n",a);
printf("YYY%ld\n",a);
printf("ZZZ%lld\n",a);
while generating warnings, at least works under Windows (with the msvcrt
of Windows 7 anyway). But the I64d format is ignored under Linux.
Out of interest, how would /you/ write portable code to print a int64_t
value?
I asked what you would do *instead* of taking
> this route. Your suggestion of %? does not work.
%? will work (for decimal output) in exactly the same situations where
the compiler can give warnings about the wrong format.
You might as well say that a compiler will fail to warn about bad
formats when using v*printf, so it's not worth bothering. (I've never
used v*printf functions, and only heard of them recently.)
> You said using %ld
> was a bad idea but here you saying it is what you would do.
If it had to work using *printf functions.
In other languages, I generally just write 'print a', which might be
mapped to an internal function call eg '$print_i64'.
(The implementation of that might make use of *printf, but that can -and
has - suffered from the same problems of mixed i64 support. But then it
is easy enough to write code to convert a digit a time, which is what I
do with some apps.)
> This does not answer my question. What range of implementations with
> broken 64-bit support do you want to be able to target?
If the 64-bit support really is broken, then I would need to find
workarounds (in the case where C is an intermediate language). That
would be nothing new.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-03 12:44 -0800 |
| Message-ID | <lnr33f3syz.fsf@kst-u.example.com> |
| In reply to | #103077 |
BartC <bc@freeuk.com> writes:
[...]
> But not very well. You snipped the I64 format (%I64d actually) which
> matches the int64_t type.
"%I64d" is non-standard. Don't use it if you care about portability.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-03 21:33 +0000 |
| Message-ID | <o72ssc$b2r$1@dont-email.me> |
| In reply to | #103079 |
On 03/02/2017 20:44, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > [...] >> But not very well. You snipped the I64 format (%I64d actually) which >> matches the int64_t type. > > "%I64d" is non-standard. Don't use it if you care about portability. This was about what /I/ would have done to fix some of the printf problems. One of them might be to have introduced %I64d at the same time as int64_t. That's when a compiler can't or is not allowed to modify a literal format string with a new "%?" format.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-02-03 16:19 -0600 |
| Message-ID | <540a9cpdgag09bas7fll08ianoja8sipcs@4ax.com> |
| In reply to | #103077 |
On Fri, 3 Feb 2017 20:28:28 +0000, BartC <bc@freeuk.com> wrote:
>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. You snipped the I64 format (%I64d actually) which
>matches the int64_t type.
>
>At the moment, using %lld for int64_t causes a spurious warning with a
>version of gcc (which may be a bug), and using it on Linux generates a
>warning because there, int64_t corresponds to 'long' not 'long long'.
>
>This code:
>
> int64_t a=78;
>
> printf("XXX%I64d\n",a);
> printf("YYY%ld\n",a);
> printf("ZZZ%lld\n",a);
>
>while generating warnings, at least works under Windows (with the msvcrt
>of Windows 7 anyway). But the I64d format is ignored under Linux.
>
>Out of interest, how would /you/ write portable code to print a int64_t
>value?
Why not use printf with PRId64, which is intended for exactly that
purpose? On Windows, you may have to supply a few of those
definitions yourself, depending on which version of the compiler and
what mode you're running it in.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-03 22:46 +0000 |
| Message-ID | <o73143$p69$1@dont-email.me> |
| In reply to | #103088 |
On 03/02/2017 22:19, Robert Wessel wrote:
> On Fri, 3 Feb 2017 20:28:28 +0000, BartC <bc@freeuk.com> wrote:
>> Out of interest, how would /you/ write portable code to print a int64_t
>> value?
>
>
> Why not use printf with PRId64, which is intended for exactly that
> purpose? On Windows, you may have to supply a few of those
> definitions yourself, depending on which version of the compiler and
> what mode you're running it in.
Out of principle. I've never used those macros myself, and I'm not going
to start using them in generated code, requiring inttypes.h and 150
macros most of which are never going to be needed.
I'd rather just have a routine which converts 64-bit number to strings,
and then use %s which appears to be universally available. But that
means input source such as 'println a' may have to appear as a sequence
of function calls rather than 'printf("%lld\n",a)', if anyone were to
look at the intermediate C.
I mean, just look at this extract of the actual macros (from gcc/mingw's
inttypes.h). What decade are we supposed to be in?
#define PRId8 "d"
#define PRId16 "d"
#define PRId32 "d"
#define PRId64 "I64d"
#define PRIdLEAST8 "d"
#define PRIdLEAST16 "d"
#define PRIdLEAST32 "d"
#define PRIdLEAST64 "I64d"
#define PRIdFAST8 "d"
#define PRIdFAST16 "d"
#define PRIdFAST32 "d"
#define PRIdFAST64 "I64d"
#define PRIdMAX "I64d"
#define PRIi8 "i"
#define PRIi16 "i"
#define PRIi32 "i"
#define PRIi64 "I64i"
#define PRIiLEAST8 "i"
#define PRIiLEAST16 "i"
#define PRIiLEAST32 "i"
#define PRIiLEAST64 "I64i"
#define PRIiFAST8 "i"
#define PRIiFAST16 "i"
#define PRIiFAST32 "i"
#define PRIiFAST64 "I64i"
#define PRIiMAX "I64i"
#define PRIo8 "o"
#define PRIo16 "o"
#define PRIo32 "o"
#define PRIo64 "I64o"
#define PRIoLEAST8 "o"
#define PRIoLEAST16 "o"
#define PRIoLEAST32 "o"
#define PRIoLEAST64 "I64o"
#define PRIoFAST8 "o"
#define PRIoFAST16 "o"
#define PRIoFAST32 "o"
#define PRIoFAST64 "I64o"
#define PRIoMAX "I64o"
#define PRIu8 "u"
#define PRIu16 "u"
#define PRIu32 "u"
#define PRIu64 "I64u"
#define PRIuLEAST8 "u"
#define PRIuLEAST16 "u"
#define PRIuLEAST32 "u"
#define PRIuLEAST64 "I64u"
#define PRIuFAST8 "u"
#define PRIuFAST16 "u"
#define PRIuFAST32 "u"
#define PRIuFAST64 "I64u"
#define PRIuMAX "I64u"
#define PRIx8 "x"
#define PRIx16 "x"
#define PRIx32 "x"
#define PRIx64 "I64x"
#define PRIxLEAST8 "x"
#define PRIxLEAST16 "x"
#define PRIxLEAST32 "x"
#define PRIxLEAST64 "I64x"
#define PRIxFAST8 "x"
#define PRIxFAST16 "x"
#define PRIxFAST32 "x"
#define PRIxFAST64 "I64x"
#define PRIxMAX "I64x"
#define PRIX8 "X"
#define PRIX16 "X"
#define PRIX32 "X"
#define PRIX64 "I64X"
#define PRIXLEAST8 "X"
#define PRIXLEAST16 "X"
#define PRIXLEAST32 "X"
#define PRIXLEAST64 "I64X"
#define PRIXFAST8 "X"
#define PRIXFAST16 "X"
#define PRIXFAST32 "X"
#define PRIXFAST64 "I64X"
#define PRIXMAX "I64X"
#define SCNd16 "hd"
#define SCNd32 "d"
#define SCNd64 "I64d"
#define SCNdLEAST16 "hd"
#define SCNdLEAST32 "d"
#define SCNdLEAST64 "I64d"
#define SCNdFAST16 "hd"
#define SCNdFAST32 "d"
#define SCNdFAST64 "I64d"
#define SCNdMAX "I64d"
#define SCNi16 "hi"
#define SCNi32 "i"
#define SCNi64 "I64i"
#define SCNiLEAST16 "hi"
#define SCNiLEAST32 "i"
#define SCNiLEAST64 "I64i"
#define SCNiFAST16 "hi"
#define SCNiFAST32 "i"
#define SCNiFAST64 "I64i"
#define SCNiMAX "I64i"
#define SCNo16 "ho"
#define SCNo32 "o"
#define SCNo64 "I64o"
#define SCNoLEAST16 "ho"
#define SCNoLEAST32 "o"
#define SCNoLEAST64 "I64o"
#define SCNoFAST16 "ho"
#define SCNoFAST32 "o"
#define SCNoFAST64 "I64o"
#define SCNoMAX "I64o"
#define SCNx16 "hx"
#define SCNx32 "x"
#define SCNx64 "I64x"
#define SCNxLEAST16 "hx"
#define SCNxLEAST32 "x"
#define SCNxLEAST64 "I64x"
#define SCNxFAST16 "hx"
#define SCNxFAST32 "x"
#define SCNxFAST64 "I64x"
#define SCNxMAX "I64x"
#define SCNu16 "hu"
#define SCNu32 "u"
#define SCNu64 "I64u"
#define SCNuLEAST16 "hu"
#define SCNuLEAST32 "u"
#define SCNuLEAST64 "I64u"
#define SCNuFAST16 "hu"
#define SCNuFAST32 "u"
#define SCNuFAST64 "I64u"
#define SCNuMAX "I64u"
#ifdef _WIN64
#define PRIdPTR "I64d"
#define PRIiPTR "I64i"
#define PRIoPTR "I64o"
#define PRIuPTR "I64u"
#define PRIxPTR "I64x"
#define PRIXPTR "I64X"
#define SCNdPTR "I64d"
#define SCNiPTR "I64i"
#define SCNoPTR "I64o"
#define SCNxPTR "I64x"
#define SCNuPTR "I64u"
#else
#define PRIdPTR "d"
#define PRIiPTR "i"
#define PRIoPTR "o"
#define PRIuPTR "u"
#define PRIxPTR "x"
#define PRIXPTR "X"
#define SCNdPTR "d"
#define SCNiPTR "i"
#define SCNoPTR "o"
#define SCNxPTR "x"
#define SCNuPTR "u"
#endif
#if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
#define SCNd8 "hhd"
#define SCNdLEAST8 "hhd"
#define SCNdFAST8 "hhd"
#define SCNi8 "hhi"
#define SCNiLEAST8 "hhi"
#define SCNiFAST8 "hhi"
#define SCNo8 "hho"
#define SCNoLEAST8 "hho"
#define SCNoFAST8 "hho"
#define SCNx8 "hhx"
#define SCNxLEAST8 "hhx"
#define SCNxFAST8 "hhx"
#define SCNu8 "hhu"
#define SCNuLEAST8 "hhu"
#define SCNuFAST8 "hhu"
#endif /* __STDC_VERSION__ >= 199901 */
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-02-03 17:47 -0600 |
| Message-ID | <jq4a9ct3cm899m9pi6pr1gq4c3aims04h4@4ax.com> |
| In reply to | #103090 |
On Fri, 3 Feb 2017 22:46:02 +0000, BartC <bc@freeuk.com> wrote:
>On 03/02/2017 22:19, Robert Wessel wrote:
>> On Fri, 3 Feb 2017 20:28:28 +0000, BartC <bc@freeuk.com> wrote:
>
>>> Out of interest, how would /you/ write portable code to print a int64_t
>>> value?
>>
>>
>> Why not use printf with PRId64, which is intended for exactly that
>> purpose? On Windows, you may have to supply a few of those
>> definitions yourself, depending on which version of the compiler and
>> what mode you're running it in.
>
>Out of principle. I've never used those macros myself, and I'm not going
>to start using them in generated code, requiring inttypes.h and 150
>macros most of which are never going to be needed.
Wait, so where are you getting int64_t from, if not stdint.h?
So we all know C does not specify the size of types. This may be a
mistake in the design of the language, but it's not one we can do
anything about. C99 provides a way to select one of those types that
matches certain parameters (for example, an exactly 64 bit integer,
with int64_t, if such a thing is available). It then provides
matching specifier stings to pass to printf and scanf. Yet on
principle you don't want to use the actual mechanism defined to
provide the function you want. So what do you want that might
reasonably be achieved (assuming that redesigning C is actually off
the table)?
>I'd rather just have a routine which converts 64-bit number to strings,
>and then use %s which appears to be universally available. But that
>means input source such as 'println a' may have to appear as a sequence
>of function calls rather than 'printf("%lld\n",a)', if anyone were to
>look at the intermediate C.
>
>I mean, just look at this extract of the actual macros (from gcc/mingw's
>inttypes.h). What decade are we supposed to be in?
...(PRI and SCN specifier macros snipped)...
As I just pointed out in another message, how are the macros, all of
which follow a very simple pattern, meaningfully less clear than
something like "%lld"? And the fact that the definitions are ugly
doesn't really matter, you don't need to look at them (except, as I
pointed out, when you need to fake up a copy of stdint.h for a
compiler not supporting C99).
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-04 13:26 +1300 |
| Message-ID | <efkldcFh1v7U3@mid.individual.net> |
| In reply to | #103090 |
On 02/ 4/17 11:46 AM, BartC wrote: > On 03/02/2017 22:19, Robert Wessel wrote: >> On Fri, 3 Feb 2017 20:28:28 +0000, BartC <bc@freeuk.com> wrote: > >>> Out of interest, how would /you/ write portable code to print a int64_t >>> value? >> >> >> Why not use printf with PRId64, which is intended for exactly that >> purpose? On Windows, you may have to supply a few of those >> definitions yourself, depending on which version of the compiler and >> what mode you're running it in. > > Out of principle. I've never used those macros myself, and I'm not going > to start using them in generated code, requiring inttypes.h and 150 > macros most of which are never going to be needed. Out of principle, or pigheadedness? If the former, which one? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-04 01:08 +0000 |
| Message-ID | <o739fr$kja$1@dont-email.me> |
| In reply to | #103098 |
On 04/02/2017 00:26, Ian Collins wrote:
> On 02/ 4/17 11:46 AM, BartC wrote:
>> On 03/02/2017 22:19, Robert Wessel wrote:
>>> On Fri, 3 Feb 2017 20:28:28 +0000, BartC <bc@freeuk.com> wrote:
>>
>>>> Out of interest, how would /you/ write portable code to print a int64_t
>>>> value?
>>>
>>>
>>> Why not use printf with PRId64, which is intended for exactly that
>>> purpose? On Windows, you may have to supply a few of those
>>> definitions yourself, depending on which version of the compiler and
>>> what mode you're running it in.
>>
>> Out of principle. I've never used those macros myself, and I'm not going
>> to start using them in generated code, requiring inttypes.h and 150
>> macros most of which are never going to be needed.
>
> Out of principle, or pigheadedness? If the former, which one?
Partly out of aesthetic principles, but also I like things that are
clean, lean and efficient. I don't want 140 mostly pointless macros
cluttering up the inside of the compiler I'm using.
Take this famous C program:
#include <stdio.h>
int main(void) {printf("Hello, World!\n");}
If I compile it with lccwin on Windows, it loads 3 headers and totals
260 lines of processed code.
If I compile it with gcc on Linux, it loads 16 headers (from 22 nested
#includes) and processes 4700 lines.
Is it any wonder that gcc tends to be slower?! (What's inside all those
headers? I've no idea what's going on in there, although #if _cplusplus
seems to figure a lot. So pandering to C++ is likely wasting /my/ time
on longer compilations even when I'm not using it!)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-04 18:09 +1300 |
| Message-ID | <efl609Fh1v7U7@mid.individual.net> |
| In reply to | #103110 |
On 02/ 4/17 02:08 PM, BartC wrote:
> On 04/02/2017 00:26, Ian Collins wrote:
>> On 02/ 4/17 11:46 AM, BartC wrote:
>>> Out of principle. I've never used those macros myself, and I'm not going
>>> to start using them in generated code, requiring inttypes.h and 150
>>> macros most of which are never going to be needed.
>>
>> Out of principle, or pigheadedness? If the former, which one?
>
>
> Partly out of aesthetic principles, but also I like things that are
> clean, lean and efficient. I don't want 140 mostly pointless macros
> cluttering up the inside of the compiler I'm using.
>
> Take this famous C program:
>
> #include <stdio.h>
> int main(void) {printf("Hello, World!\n");}
>
> If I compile it with lccwin on Windows, it loads 3 headers and totals
> 260 lines of processed code.
>
> If I compile it with gcc on Linux, it loads 16 headers (from 22 nested
> #includes) and processes 4700 lines.
You must be doing something odd...
$ cat x.c; gcc -E x.c | grep -v -e '^$' | wc -l
#include <stdio.h>
int main(void) {printf("Hello, World!\n");}
388
So that's 388 (non-blank) lines from
$ gcc -E x.c | grep include | cut -d ' ' -f3 | sort -u | wc -l
16
16 files.
Solaris is a little less frivolous, 174 lines from 9 files.
> Is it any wonder that gcc tends to be slower?! (What's inside all those
> headers? I've no idea what's going on in there,
So have a look with gcc -E, which I assume is how you got your numbers.
> although #if _cplusplus
> seems to figure a lot. So pandering to C++ is likely wasting /my/ time
> on longer compilations even when I'm not using it!)
A total red herring.
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-04 12:14 +0000 |
| Message-ID | <o74gf7$mcc$1@dont-email.me> |
| In reply to | #103119 |
On 04/02/2017 05:09, Ian Collins wrote:
> On 02/ 4/17 02:08 PM, BartC wrote:
>> #include <stdio.h>
>> int main(void) {printf("Hello, World!\n");}
>>
>> If I compile it with lccwin on Windows, it loads 3 headers and totals
>> 260 lines of processed code.
>>
>> If I compile it with gcc on Linux, it loads 16 headers (from 22 nested
>> #includes) and processes 4700 lines.
>
> You must be doing something odd...
I'm counting the number of /processed/ lines, which includes that in the
false branches of #if, #elif, and #else.
-E output won't show those lines, but the compiler still has to deal
with them.
These are the includes I get with gcc's stdio.h from Linux:
#include file: stdio.h
| #include file: features.h
| | #include file: stdc-predef.h
| | #include file: sys/cdefs.h
| | | #include file: bits/wordsize.h
| | #include file: gnu/stubs.h
| | | #include file: gnu/stubs-32.h
| #include file: stddef.h
| #include file: bits/types.h
| | #include file: features.h
| | #include file: bits/wordsize.h
| | #include file: bits/typesizes.h
| #include file: libio.h
| | #include file: _G_config.h
| | | #include file: bits/types.h
| | | #include file: stddef.h
| | | #include file: wchar.h
| | | | #include file: stddef.h
| | #include file: stdarg.h
| #include file: stdarg.h
| #include file: bits/stdio_lim.h
| #include file: bits/sys_errlist.h
This is what I get with Pelles C's stdio.h from Windows:
#include file: stdio.h
| #include file: crtdef.h
>> Is it any wonder that gcc tends to be slower?! (What's inside all those
>> headers? I've no idea what's going on in there,
>
> So have a look with gcc -E, which I assume is how you got your numbers.
Huh? I can have a look with just an editor! I just don't understand the
gobbledygook they seem to be full of.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-04 17:01 +0100 |
| Message-ID | <o74too$4rk$1@dont-email.me> |
| In reply to | #103110 |
On 04/02/17 02:08, BartC wrote:
> On 04/02/2017 00:26, Ian Collins wrote:
>> On 02/ 4/17 11:46 AM, BartC wrote:
>>> On 03/02/2017 22:19, Robert Wessel wrote:
>>>> On Fri, 3 Feb 2017 20:28:28 +0000, BartC <bc@freeuk.com> wrote:
>>>
>>>>> Out of interest, how would /you/ write portable code to print a
>>>>> int64_t
>>>>> value?
>>>>
>>>>
>>>> Why not use printf with PRId64, which is intended for exactly that
>>>> purpose? On Windows, you may have to supply a few of those
>>>> definitions yourself, depending on which version of the compiler and
>>>> what mode you're running it in.
>>>
>>> Out of principle. I've never used those macros myself, and I'm not going
>>> to start using them in generated code, requiring inttypes.h and 150
>>> macros most of which are never going to be needed.
>>
>> Out of principle, or pigheadedness? If the former, which one?
>
>
> Partly out of aesthetic principles, but also I like things that are
> clean, lean and efficient. I don't want 140 mostly pointless macros
> cluttering up the inside of the compiler I'm using.
>
You are happy generating vast numbers of pointless enum types in code
that someone might want to read, but re-using an existing set of macros
hidden away in a standard header that no one needs to see bothers you?
That is either seriously hypocritical, or you haven't the faintest idea
what the cost of the extra macros and extra enum types actually is.
(Hint - the extra enum types are negligible cost, but the extra macros
cost far less.)
> Take this famous C program:
>
> #include <stdio.h>
> int main(void) {printf("Hello, World!\n");}
>
> If I compile it with lccwin on Windows, it loads 3 headers and totals
> 260 lines of processed code.
>
> If I compile it with gcc on Linux, it loads 16 headers (from 22 nested
> #includes) and processes 4700 lines.
All of which means exactly what? That the Linux version takes a few
extra milliseconds of your precious time? That the Linux version has
vastly more features in these headers than the llcwin one - but that
those features are not useful in such a trivial program? That the
llcwin developer has a single platform to support while the Linux
headers support dozens of processors and the gcc developers support
thousands of cpu/OS combinations?
>
> Is it any wonder that gcc tends to be slower?! (What's inside all those
> headers? I've no idea what's going on in there, although #if _cplusplus
> seems to figure a lot. So pandering to C++ is likely wasting /my/ time
> on longer compilations even when I'm not using it!)
>
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?
C++ compilation speed /is/ an issue, because getting the most out of C++
needs a great deal of code in headers. So serious work is being done
there - precompiled headers, link-time optimisation, and modules.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-04 18:20 +0000 |
| Message-ID | <o755v1$2ii$1@dont-email.me> |
| In reply to | #103141 |
On 04/02/2017 16:01, David Brown wrote: > On 04/02/17 02:08, BartC wrote: >> Partly out of aesthetic principles, but also I like things that are >> clean, lean and efficient. I don't want 140 mostly pointless macros >> cluttering up the inside of the compiler I'm using. >> > > You are happy generating vast numbers of pointless enum types in code > that someone might want to read If you mean the ones in that clex.c file, they are /my/ enums, and they are used in the code. The majority of the ones on inttypes.h truly are pointless. > That is either seriously hypocritical, or you haven't the faintest idea > what the cost of the extra macros and extra enum types actually is. > (Hint - the extra enum types are negligible cost, but the extra macros > cost far less.) Thank you for being so patronising. I write compilers; obviously I wouldn't have a clue! All this stuff in header files adds up. One of my apps using 8 headers is 28K lines of C. Compiled with lccwin, it comes to 29.5K lines including standard header stuff. Compiled with gcc, it comes to 48K lines; nearly double the size! Just for the few things I need from those headers. In fact, any program that uses even stdio.h will involving compiling nearly 5000 lines of code before it gets around to the user's code, when gcc is used. > All of which means exactly what? That the Linux version takes a few > extra milliseconds of your precious time? It's more than milliseconds. When compiling just windows.h, lccwin executes 12 includes, gcc/mingw executes 650: http://pastebin.com/KQhQtr6e. Multiply that by dozens of file all with windows.h. But of course this means nothing. *Let* gcc compile 10 or 100 times as many files with a correspondingly bigger number of lines, and let it take 10 times (or 35 times) as long. There must be a good reason for it because this is, after all, gcc. It cannot do anything wrong. > That the Linux version has > vastly more features in these headers than the llcwin one - but that > those features are not useful in such a trivial program? That the > llcwin developer has a single platform to support while the Linux > headers support dozens of processors and the gcc developers support > thousands of cpu/OS combinations? And? Why should someone using platform X suffer just because the tools support a thousand platforms they're not interested in? Why can't all those configuration scripts produce a streamlined version of the standard headers? If I compile a million lines of 'a=ABC;' then: gcc -0 takes 35 seconds lccwin takes 6 seconds Tiny C takes 1 second gcc is just slow, and here it's not even reading any headers. But it means that, combined with more and bigger headers, users are going to suffer. (My own product is a long way from being ready, but in-memory pre-processing of those million lines currently takes 0.09 seconds) > Apart from you, pretty much no one considers C compilation speed to be > an important issue - certainly not with the emphasis you give it. A big selling point of the Go language is its fast compilation and building. They say it was specially designed with that in mind. Obviously for some people, it's important. > 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? Yes. Huge numbers of people are likely wasting too much time waiting for their compilers! With C++, clearly someone has started to notice. (That adding huge amounts of functionality via preludes written in the language itself, is not conducive to getting fast build times.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-05 20:40 +1300 |
| Message-ID | <efo381Fh1v7U10@mid.individual.net> |
| In reply to | #103156 |
On 02/ 5/17 07:20 AM, BartC wrote: > On 04/02/2017 16:01, David Brown wrote: > >> All of which means exactly what? That the Linux version takes a few >> extra milliseconds of your precious time? > > It's more than milliseconds. When compiling just windows.h, lccwin > executes 12 includes, gcc/mingw executes 650: > http://pastebin.com/KQhQtr6e. Multiply that by dozens of file all with > windows.h. That's the cost of an all eggs in one basket header such as windows.h. The benefit is most compilers support pre-compiled headers, so it usually only gets parsed once. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-02-05 00:08 -0800 |
| Message-ID | <5222354c-1db2-41a7-8eb3-430252c6a7f2@googlegroups.com> |
| In reply to | #103178 |
On Sunday, February 5, 2017 at 7:40:57 AM UTC, Ian Collins wrote: > On 02/ 5/17 07:20 AM, BartC wrote: > > That's the cost of an all eggs in one basket header such as windows.h. > The benefit is most compilers support pre-compiled headers, so it > usually only gets parsed once. > But I always turn pre-compiled headers off. At least until recently the system used to kick up a fuss about compiling portable C source unless you added an include for stdafx.h. That include then tended to break the supposedly portable source. It was far more trouble than it was worth
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-05 21:10 +1300 |
| Message-ID | <efo50gFh1v7U11@mid.individual.net> |
| In reply to | #103179 |
On 02/ 5/17 09:08 PM, Malcolm McLean wrote: > On Sunday, February 5, 2017 at 7:40:57 AM UTC, Ian Collins wrote: >> On 02/ 5/17 07:20 AM, BartC wrote: >> >> That's the cost of an all eggs in one basket header such as windows.h. >> The benefit is most compilers support pre-compiled headers, so it >> usually only gets parsed once. >> > But I always turn pre-compiled headers off. At least until recently > the system used to kick up a fuss about compiling portable C source > unless you added an include for stdafx.h. That include then tended > to break the supposedly portable source. > It was far more trouble than it was worth In our environment, they work well with VS2105, clang and gcc. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-02-05 00:21 -0800 |
| Message-ID | <c9781359-bd7e-4677-b222-de99b9e876d9@googlegroups.com> |
| In reply to | #103180 |
On Sunday, February 5, 2017 at 8:11:10 AM UTC, Ian Collins wrote: > On 02/ 5/17 09:08 PM, Malcolm McLean wrote: > > On Sunday, February 5, 2017 at 7:40:57 AM UTC, Ian Collins wrote: > >> On 02/ 5/17 07:20 AM, BartC wrote: > >> > >> That's the cost of an all eggs in one basket header such as windows.h. > >> The benefit is most compilers support pre-compiled headers, so it > >> usually only gets parsed once. > >> > > But I always turn pre-compiled headers off. At least until recently > > the system used to kick up a fuss about compiling portable C source > > unless you added an include for stdafx.h. That include then tended > > to break the supposedly portable source. > > It was far more trouble than it was worth > > In our environment, they work well with VS2105, clang and gcc. > I use XCode for most of my professional programming, and there the incremental compilation is easy to set up. I don't actually know whether it stores headers as pre-compiles. I just press the button and it goes. (The problems with it are in the packaging phases, at both ends, first the demand that graphical tools be used to set up the app skeleton, and then the odd rules for deployment of a program with associated dependencies).
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-05 11:51 +0000 |
| Message-ID | <o773gn$b6h$1@dont-email.me> |
| In reply to | #103178 |
On 05/02/2017 07:40, Ian Collins wrote:
> On 02/ 5/17 07:20 AM, BartC wrote:
>> On 04/02/2017 16:01, David Brown wrote:
>>
>>> All of which means exactly what? That the Linux version takes a few
>>> extra milliseconds of your precious time?
>>
>> It's more than milliseconds. When compiling just windows.h, lccwin
>> executes 12 includes, gcc/mingw executes 650:
>> http://pastebin.com/KQhQtr6e. Multiply that by dozens of file all with
>> windows.h.
>
> That's the cost of an all eggs in one basket header such as windows.h.
> The benefit is most compilers support pre-compiled headers, so it
> usually only gets parsed once.
/Most/ compilers? I doubt it.
But I tried precompiled headers with gcc (it's quite straightforward
according to the instructions, but there were some issues; see below).
I created 10 source files each containing #include <window.h>, and one
main() program with a call to MessageBox to test the program linked
properly. Timings to compile were these (mix of 32 and 64-bits):
Unique/All LoC
Files /#includes
Pelles C 7.8 secs 74/255 147K
lccwin 0.9 secs 11/12 20K
DMC 2.5 secs 105/380 162K
Tiny C 0.9 secs 32/58 27K
gcc/mingw 9.0 secs 146/659 341K
gcc/mingw (PCH) 3.1 secs 146/659 341K
This is for compiling all 10 modules via my IDE (except for gcc/PCH; see
below).
Notice that gcc's timing of 3 seconds, while much faster than the
original 11/12 seconds (eventually settling to 9), is still slower than
some of the other compilers.
Partly this is because those other compilers manage to keep windows.h
small, especially lccwin and Tiny C. (I don't know what, if anything,
has been left out. I have a feeling that gcc never takes anything out;
it just keeps adding stuff!)
Now for the problems I found: I copied windows.h to my current directory
and precompiled it there. But the search logic, while it could find
<windows.h> in that location, can't find precompiled headers there. It
needs to be in a official ...\include path.
Also, after trying those other compilers and then testing gcc again, it
said 'found precompiled header but it's invalid'. I had to precompile it
again, even though nothing had changed.
There's another factor: my IDE compiles modules, even all the modules,
by invoking the compilers one at a time. This doesn't work with
precompiled headers, as there is a big overhead in processing even the
.gch file. Then the timing was nearly as long as not using the
precompiled header.
To get the advantage, all files have to be compiled at the same time
with one invocation of gcc. So when working on a single file, the PCH
doesn't help much.
(I don't have a working parser yet in my project, but preprocessing of
even gcc's 340Kloc windows.h took 0.14 seconds, including loading the
files. Preprocessing lccwin's windows.h took 0.014 seconds.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web