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 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-06 15:27 +0000 |
| Message-ID | <87bmufe3vw.fsf@bsb.me.uk> |
| In reply to | #103297 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Monday, February 6, 2017 at 1:49:13 PM UTC, David Brown wrote: >> On 06/02/17 14:22, Malcolm McLean wrote: >> > >> There is no "rule of two" except in your imagination. Even if it >> existed, and you could actually state it properly, it would not >> "override" anything. No rule that you make up will suddenly make "David >> Brown" a unique identifier. Even if I include my middle name, which I >> rarely use, it is still not unique - a "rule of three" won't work either. >> > We could insist that all C identifiers be globally unique > identifiers. Simply append a > GUID to the identifier id. Or even a human-meaningful string. We don't do that > because it would be humanly intolerable. Instead we use scoping. Have you checked your own code against your rules? It looks to me that these are rule you made up for everyone else. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-02-06 15:10 +0000 |
| Message-ID | <589891b6.18418453@news.xs4all.nl> |
| In reply to | #103295 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Monday, February 6, 2017 at 1:06:11 PM UTC, David Brown wrote: > > On 06/02/17 11:53, Richard Bos wrote: > > > Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > > > > > >> There's also the rule of two. Identifiers need to be binary at most (Richard Heathfield, > > >> not Richard Archibald Baldwick Charles David Edmund Frederick Gideon Heathfield) > > > > > > There are at least two other people called Richard Bos on the 'net, and > > > at least one other of them is also a C programmer. I will keep my middle > > > name, thank you very much. > > > > And just imagine how many David Browns there are out there... > > > But you post as "David Brown". There is a small chance of a name clash, you quite possibly > have been in the same school class as another David Brown or worked in the same office. > > But the rule of two overrrides that. No. No, it doesn't. You've just invented it; it doesn't exist. Quoque, nimium Latinatus es. Richard
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-06 14:55 +0000 |
| Message-ID | <o7a2m0$r0n$1@dont-email.me> |
| In reply to | #103294 |
On 06/02/2017 13:06, David Brown wrote: > On 06/02/17 11:53, Richard Bos wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >> >>> There's also the rule of two. Identifiers need to be binary at most (Richard Heathfield, >>> not Richard Archibald Baldwick Charles David Edmund Frederick Gideon Heathfield) >> >> There are at least two other people called Richard Bos on the 'net, and >> at least one other of them is also a C programmer. I will keep my middle >> name, thank you very much. >> >> Richard >> > > And just imagine how many David Browns there are out there... > AFAIK my own full name, even with just two names, is unique, especially with my proper first name of 'bartolomeo'. And the surname is unusual. That's why I prefer not to post with my full name. (I've only once come across someone else with my full name on google, and that was a character in an on-line fantasy football team. I wished I'd saved the page as when I visited it later, the team had changed!) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-06 16:57 +0100 |
| Message-ID | <o7a69g$90l$1@dont-email.me> |
| In reply to | #103305 |
On 06/02/17 15:55, BartC wrote: > On 06/02/2017 13:06, David Brown wrote: >> On 06/02/17 11:53, Richard Bos wrote: >>> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: >>> >>>> There's also the rule of two. Identifiers need to be binary at most >>>> (Richard Heathfield, >>>> not Richard Archibald Baldwick Charles David Edmund Frederick Gideon >>>> Heathfield) >>> >>> There are at least two other people called Richard Bos on the 'net, and >>> at least one other of them is also a C programmer. I will keep my middle >>> name, thank you very much. >>> >>> Richard >>> >> >> And just imagine how many David Browns there are out there... >> > > AFAIK my own full name, even with just two names, is unique, especially > with my proper first name of 'bartolomeo'. And the surname is unusual. Coincidentally, that also applies to the only other "Bart" that I knew. But I'm guessing that his unusual surname is different from /your/ unusual surname. You would think that at least here in Norway "David Brown" was rare - but there are at least 9 others. Plus a few tractors :-) > > That's why I prefer not to post with my full name. Fair enough - all we need here is a way to identify people inside the newsgroup. > > (I've only once come across someone else with my full name on google, > and that was a character in an on-line fantasy football team. I wished > I'd saved the page as when I visited it later, the team had changed!) >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-03 21:17 +0100 |
| Message-ID | <o72odr$pif$1@dont-email.me> |
| In reply to | #103018 |
On 03/02/17 13:36, Richard Heathfield wrote: > On 03/02/17 12:26, Malcolm McLean wrote: >> On Friday, February 3, 2017 at 10:25:33 AM UTC, David Brown wrote: >>> On 03/02/17 10:07, Ian Collins wrote: >>>> On 02/ 3/17 10:02 PM, Malcolm McLean wrote: >>>>>> >>>>> Variable integer sizes cause a ridiculous amount of fuss for something >>>>> so trivial. Once you know you can index any array, you don't need >>>>> another >>>>> type, and the problems fall away. >>>> >>>> Until you encounter the real world. >>>> >>> >>> Malcolm doesn't live in the real world. On his planet, numbers are >>> either limited to 3 for things you can think about, or they are array >>> indexes. There is nothing in-between. >>> >> Tetration is really beyond our capabilities, and of the ability of our >> machines to handle. So it's one, two, three ... many. > > That may be true of Discworld trolls (and quite possibly Usenet trolls), > but it's not true of good programmers. > Even Discworld trolls can go on with many-and-one, many-and-two, two-manys. But IIRC they had to cool their brains to get that far.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-02-03 20:20 +0000 |
| Message-ID | <o72oj1$qma$1@dont-email.me> |
| In reply to | #103073 |
On 03/02/17 20:17, David Brown wrote: > On 03/02/17 13:36, Richard Heathfield wrote: >> On 03/02/17 12:26, Malcolm McLean wrote: <snip> >>> Tetration is really beyond our capabilities, and of the ability of our >>> machines to handle. So it's one, two, three ... many. >> >> That may be true of Discworld trolls (and quite possibly Usenet trolls), >> but it's not true of good programmers. >> > > Even Discworld trolls can go on with many-and-one, many-and-two, > two-manys. But IIRC they had to cool their brains to get that far. You might want to turn on your cooling fan. It's many-one, many-two, many-*three*, many-many. For the record, it continues in thus wise: Many-many-one, many-many-two, many-many-three, many-many-many. Many-many-many-one, many-many-many-two, many-many-many-three, LOTS! -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-03 21:29 +0100 |
| Message-ID | <o72p3g$sm8$2@dont-email.me> |
| In reply to | #103074 |
On 03/02/17 21:20, Richard Heathfield wrote: > On 03/02/17 20:17, David Brown wrote: >> On 03/02/17 13:36, Richard Heathfield wrote: >>> On 03/02/17 12:26, Malcolm McLean wrote: > > <snip> > >>>> Tetration is really beyond our capabilities, and of the ability of our >>>> machines to handle. So it's one, two, three ... many. >>> >>> That may be true of Discworld trolls (and quite possibly Usenet trolls), >>> but it's not true of good programmers. >>> >> >> Even Discworld trolls can go on with many-and-one, many-and-two, >> two-manys. But IIRC they had to cool their brains to get that far. > > You might want to turn on your cooling fan. It's many-one, many-two, > many-*three*, many-many. > > For the record, it continues in thus wise: > > Many-many-one, many-many-two, many-many-three, many-many-many. > > Many-many-many-one, many-many-many-two, many-many-many-three, LOTS! > I always remembered in being "one, two, many" - with no "three". But perhaps I was asleep when I read that bit of the book late at night.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-02-03 21:03 +0000 |
| Message-ID | <o72r3v$4ls$1@dont-email.me> |
| In reply to | #103078 |
On 03/02/17 20:29, David Brown wrote: <snip> > I always remembered in being "one, two, many" - with no "three". But > perhaps I was asleep when I read that bit of the book late at night. Re-read "Men at Arms". Detritus counts in quaternary. If you could get a laptop to operate at 20 degrees Fahrenheit, he would probably be a very good machine code programmer. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-03 22:33 +0100 |
| Message-ID | <o72ssm$b4m$1@dont-email.me> |
| In reply to | #103081 |
On 03/02/17 22:03, Richard Heathfield wrote: > On 03/02/17 20:29, David Brown wrote: > <snip> > >> I always remembered in being "one, two, many" - with no "three". But >> perhaps I was asleep when I read that bit of the book late at night. > > Re-read "Men at Arms". > > Detritus counts in quaternary. If you could get a laptop to operate at > 20 degrees Fahrenheit, he would probably be a very good machine code > programmer. > I was sure it was base 3. According to Wikipedia, /some/ trolls prefer to count "one, two, many, lots" rather than the standard "one, two, three, many". Maybe that's what confused me. Ah, well - there is always something new to learn in this group!
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-04 13:29 +1300 |
| Message-ID | <efklinFh1v7U4@mid.individual.net> |
| In reply to | #103017 |
On 02/ 4/17 01:26 AM, Malcolm McLean wrote: > On Friday, February 3, 2017 at 10:25:33 AM UTC, David Brown wrote: >> On 03/02/17 10:07, Ian Collins wrote: >>> On 02/ 3/17 10:02 PM, Malcolm McLean wrote: >>>>> >>>> Variable integer sizes cause a ridiculous amount of fuss for something >>>> so trivial. Once you know you can index any array, you don't need another >>>> type, and the problems fall away. >>> >>> Until you encounter the real world. >>> >> >> Malcolm doesn't live in the real world. On his planet, numbers are >> either limited to 3 for things you can think about, or they are array >> indexes. There is nothing in-between. >> > Tetration is really beyond our capabilities, and of the ability of our > machines to handle. So it's one, two, three ... many. > Integers (not "scaled integers", which are not integers but representations > of real or occasionally rational numbers) almost always end up in an > index calculation somewhere, even if it's hidden. Arrays are by far and > away the most common data structure. What does any of this have to do with C in the real world? How does accessing N bit registers or N bit chunks of data streams relate to index calculations? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-02-04 04:19 -0800 |
| Message-ID | <c71035d6-c7c1-4a67-95e7-9f3554e827e7@googlegroups.com> |
| In reply to | #103099 |
On Saturday, February 4, 2017 at 12:29:18 AM UTC, Ian Collins wrote: > On 02/ 4/17 01:26 AM, Malcolm McLean wrote: > > > Tetration is really beyond our capabilities, and of the ability of our > > machines to handle. So it's one, two, three ... many. > > Integers (not "scaled integers", which are not integers but representations > > of real or occasionally rational numbers) almost always end up in an > > index calculation somewhere, even if it's hidden. Arrays are by far and > > away the most common data structure. > > What does any of this have to do with C in the real world? How does > accessing N bit registers or N bit chunks of data streams relate to > index calculations? > C doesn't allow you to access a register or absolute memory address. You have to use an extension. Which is often done and is wholly legitimate. And there your "integers" may not be really integers but collections of flags. There is also a point, when data is actually entering the system, where hardware and software meet, and for a moment we have a datum which is, to the receiving code, a pattern of bits of uncertain meaning. But normally it is pretty soon marshalled and whilst maybe not in absolutely every case put into an array, in the vast majority of cases that is where it ends up.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-02-03 15:18 +0000 |
| Message-ID | <874m0bjob4.fsf@bsb.me.uk> |
| In reply to | #103007 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Friday, February 3, 2017 at 12:16:22 AM UTC, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> > >> Why do you say that? What evidence is there that the designers of C >> thought it was supposed to be used as an intermediate language? Do you >> know of any evidence that the C committee made any decisions because it >> supposed C would be used like that? >> > Some scripting languages like Lua omitted goto (we're a modern, > structured programming language, this construct is obsolete they > said, in a superior kind of way) Did they? I could not find any such attitude in either of the two key design papers about Lua. What is your evidence that they (whoever they are) had such a haughty attitude? > only to put it back in the language > specification to make it easier for automatic tools to generate > Lua script. Does this have anything to do with what I said, or did you being Lua into it simply to insult the designers? >> If not, it is possible that a whole slew of your complaints about C are >> rooted in your bad experience of C not doing what the people involved in >> its design never thought it was supposed to do. >> > C is a natural choice for an intermediate language, and yacc has been > around for ages. YACC is not a programming language. But C is sometimes for as a programming language translation target, but that, I think, is because it is ubiquitous. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2017-02-03 21:17 +0000 |
| Message-ID | <o72s1n$b79$1@z-news.wcss.wroc.pl> |
| In reply to | #102982 |
BartC <bc@freeuk.com> wrote:
>
> In that case I might as well just use long long instead of int64_t. I
> think long long will be 64 bits on all the targets I'm interested in.
Old gcc manuals said that 'long long' is type of size twice the
native machine word. Alpha was 64 bit machine, so on Alpha
that would give 128 bits. When Alpha users complained that
on Alpha 'long long' is only 64-bit instead of fixing
compiler (implementing 128 bit type) gcc folks changed the
manual. But this does not change the fact than on 64
bit machine natural size for 'long long' would be 128 bits.
gcc now has 128 types on 64-bit machines but they are not
eager to change size of 'long long'. But new compiler
may decide they they want more logical system even if
it breaks some old code making unportable assumptions.
I certaninly would like to use C compiler with 128 bits
'long long'.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-03 13:39 -0800 |
| Message-ID | <lnmve33qfc.fsf@kst-u.example.com> |
| In reply to | #103082 |
antispam@math.uni.wroc.pl writes:
> BartC <bc@freeuk.com> wrote:
>>
>> In that case I might as well just use long long instead of int64_t. I
>> think long long will be 64 bits on all the targets I'm interested in.
>
> Old gcc manuals said that 'long long' is type of size twice the
> native machine word. Alpha was 64 bit machine, so on Alpha
> that would give 128 bits. When Alpha users complained that
> on Alpha 'long long' is only 64-bit instead of fixing
> compiler (implementing 128 bit type) gcc folks changed the
> manual. But this does not change the fact than on 64
> bit machine natural size for 'long long' would be 128 bits.
Do you have a basis for that other than "old gcc manuals"?
The oldest one I can find (2.8.1) says that long long is "twice as
long as int". int is typically 32 bits even on 64-bit systems.
[...]
The standard requires long long to be at least 64 bits. It certainly
*can* be 128 bits, or even more, but I know of no implementations that
make it anything other than exactly 64 bits. (gcc's 128-bit integers
are provided as an extension; they're not even treated as "extended
integer types" in the sense described in the standard.)
--
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 | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2017-02-03 23:38 +0000 |
| Message-ID | <o7348u$g3s$1@z-news.wcss.wroc.pl> |
| In reply to | #103086 |
Keith Thompson <kst-u@mib.org> wrote:
> antispam@math.uni.wroc.pl writes:
> > BartC <bc@freeuk.com> wrote:
> >>
> >> In that case I might as well just use long long instead of int64_t. I
> >> think long long will be 64 bits on all the targets I'm interested in.
> >
> > Old gcc manuals said that 'long long' is type of size twice the
> > native machine word. Alpha was 64 bit machine, so on Alpha
> > that would give 128 bits. When Alpha users complained that
> > on Alpha 'long long' is only 64-bit instead of fixing
> > compiler (implementing 128 bit type) gcc folks changed the
> > manual. But this does not change the fact than on 64
> > bit machine natural size for 'long long' would be 128 bits.
>
> Do you have a basis for that other than "old gcc manuals"?
>
> The oldest one I can find (2.8.1) says that long long is "twice as
> long as int". int is typically 32 bits even on 64-bit systems.
2.8.1 is relatively late. From gcc-2.0.0 gcc.info, node Long Long:
GNU C supports data types for integers that are twice as long as
`long int'. Simply write `long long int' for a signed integer, or
`unsigned long long int' for an unsigned integer.
Concerning Alpha: I repeat from my memory. I have read text
by guy claiming to be bug reporter. I suppose one could try
to dig this in gcc bug database (but I do not know if they
stil keep reports from relevant period).
> The standard requires long long to be at least 64 bits. It certainly
> *can* be 128 bits, or even more, but I know of no implementations that
> make it anything other than exactly 64 bits. (gcc's 128-bit integers
> are provided as an extension; they're not even treated as "extended
> integer types" in the sense described in the standard.)
Yes. Having 128-bit integeres as standard type would make its
use easier.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Noob <root@127.0.0.1> |
|---|---|
| Date | 2017-02-02 23:40 +0100 |
| Subject | Re: printing int64_t objects |
| Message-ID | <o70cem$hdr$1@dont-email.me> |
| In reply to | #102978 |
On 02/02/2017 21:44, BartC wrote:
> Except that that "ll" causes problems on gcc [...] on the Linux,
> because there are too many l's.
"ll" (ell-ell) is for... wait for it... long long.
On Linux/amd64, int64_t is a typedef for long int.
You're supposed to use the PRId64 format specifier.
It's only been standard for 18 years.
#include <stdio.h>
#include <inttypes.h>
void foo(int64_t a)
{
printf("%" PRId64, a);
}
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-03 20:20 +1300 |
| Message-ID | <efipamFh1v9U1@mid.individual.net> |
| In reply to | #102978 |
On 02/ 3/17 09:44 AM, BartC wrote:
> On 02/02/2017 19:32, Ian Collins wrote:
>> On 02/ 3/17 08:29 AM, BartC wrote:
>>> On 02/02/2017 18:15, Keith Thompson wrote:
>>>>
>>>> I just tried compiling some similar code with gcc 2.8.1, which was
>>>> released in
>>>> 1998.
>>>>
>>>> long long n = 42;
>>>> printf("%lld\n", n);
>>>>
>>>> By default, it doesn't complain about the "%lld" format. If I use
>>>> "-ansi -pedantic -Wformat", it warns:
>>>>
>>>> c.c:3: warning: ANSI C does not support `long long'
>>>> c.c:4: warning: ANSI C does not support the `ll' length modifier
>>>>
>>>> BartC: Exactly what version of gcc are you using that prints "warning:
>>>> unknown conversion type character 'l' in format"? What is the output of
>>>> "gcc --version"?
>>>
>>> gcc (tdm64-1) 5.1.0
>>>
>>> But the resulting program works with "%lld" so the library supports it.
>>>
>>> I've always had misgivings about C's format specifiers, when they have
>>> to be used to impart type information, and this shows some of the
>>> problems that come up.
>>
>> If you want C++, you know where to find it...
>
> I don't understand; how would C++ help here?
>
> Are you suggesting that I should instead generate C++ and use 'cout'? My
> experience is that even if that solves one problem, it introduces dozens
> more.
Yep. C++ streams don't have any issues with format specifiers. As for
the dozens more problems, you'll have to identify them.
> I also have far less choice of compilers, and code will take
> longer to compile.
Yes to the first and probably no to the second. Even with fewer
compilers, the C compilers you mentioned that aren't also C++ compilers
were the ones that failed to diagnose your other problems, which would
rule them out for serious work.
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-02-03 19:52 +0000 |
| Message-ID | <87wpd78325.fsf@gmail.com> |
| In reply to | #103006 |
Ian Collins <ian-news@hotmail.com> writes: > Yep. C++ streams don't have any issues with format specifiers. As > for the dozens more problems, you'll have to identify them. I'll identify one, albeit a fairly minor one ... I find it a hell of a lot simpler to control the exact format printed with printf() than with std::setw() std::setfill() etc, and the fact that some of those carry state around is awful. Boost.format is a lot saner.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-02-04 14:03 +1300 |
| Message-ID | <efknidFh1v7U6@mid.individual.net> |
| In reply to | #103068 |
On 02/ 4/17 08:52 AM, Gareth Owen wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> Yep. C++ streams don't have any issues with format specifiers. As >> for the dozens more problems, you'll have to identify them. > > I'll identify one, albeit a fairly minor one ... I find it a hell of a > lot simpler to control the exact format printed with printf() than with > std::setw() std::setfill() etc, and the fact that some of those carry > state around is awful. > > Boost.format is a lot saner. Or simply using a variadic template to write an extendable printf(). -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-02-02 14:13 -0800 |
| Message-ID | <32e6470f-c9a8-4ba5-8d2f-146bb34bf46d@googlegroups.com> |
| In reply to | #102974 |
On Thursday, February 2, 2017 at 7:29:58 PM UTC, Bart wrote: > On 02/02/2017 18:15, Keith Thompson wrote: > > > BartC: Exactly what version of gcc are you using that prints "warning: > > unknown conversion type character 'l' in format"? What is the output of > > "gcc --version"? > > gcc (tdm64-1) 5.1.0 > > But the resulting program works with "%lld" so the library supports it. > > I've always had misgivings about C's format specifiers, when they have > to be used to impart type information, and this shows some of the > problems that come up. > > I'm writing a 20-40Kloc application, but the most pressing portability > issue is going to be being able to print a number to the console? That > is probably the next beginner program after Hello World! > I f you are printing out a number to a console, integers should be 64 bits. Presumably you are rasterising a sequence of decimal digit characters, then scrolling the console window by a line of 19 or so pixels. So any overhead in 64 bits is completely buried. But 64 bits can count anything legitimate, 32 bits can't quite, and 16 bits is very often not enough.
[toc] | [prev] | [next] | [standalone]
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web