Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #56134 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2015-01-10 13:11 -0800 |
| Last post | 2015-01-20 00:12 -0800 |
| Articles | 20 on this page of 261 — 38 participants |
Back to article view | Back to comp.lang.c
faster than c fir <profesor.fir@gmail.com> - 2015-01-10 13:11 -0800
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-10 14:26 -0800
Re: faster than c Chad <cdalten@gmail.com> - 2015-01-10 14:43 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-10 15:20 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-10 15:39 -0800
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-11 09:23 +0000
Re: faster than c asetofsymbols@gmail.com - 2015-01-11 02:17 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-11 06:00 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-12 06:46 -0800
Re: faster than c Morris Dovey <mrdovey@iedu.com> - 2015-01-12 15:01 -0600
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-12 13:44 -0800
Re: faster than c Morris Dovey <mrdovey@iedu.com> - 2015-01-12 16:59 -0600
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-12 15:25 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-13 04:56 -0800
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-12 23:26 +0000
Re: faster than c jt@toerring.de (Jens Thoms Toerring) - 2015-01-13 01:10 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-13 05:16 -0800
faster than c Chad <cdalten@gmail.com> - 2015-01-10 14:42 -0800
Re: faster than c Cooler_x0a <c00f3r@gmail.com> - 2015-01-10 15:51 -0800
Re: faster than c Geoff <geoff@invalid.invalid> - 2015-01-11 00:21 -0800
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-11 02:27 -0800
Re: faster than c gamo <gamo@telecable.es> - 2015-01-11 12:17 +0100
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-11 21:02 +0100
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-21 03:44 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-21 05:08 -0800
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-21 13:53 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-21 06:03 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-22 15:06 +0100
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-22 06:57 -0800
Re: faster than c mark.bluemel@gmail.com - 2015-01-22 07:27 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-22 07:36 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-22 07:45 -0800
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 22:36 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-11 21:16 +0100
Re: faster than c Tim Prince <tprince@computer.org> - 2015-01-11 15:42 -0500
Re: faster than c Michael Angelo Ravera <maravera@prodigy.net> - 2015-01-14 12:25 -0800
Re: faster than c Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-01-17 13:29 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 05:32 -0800
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-17 14:42 +0100
Re: faster than c Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-01-17 19:29 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 11:55 -0800
Re: faster than c "Osmium" <r124c4u102@comcast.net> - 2015-01-17 08:00 -0600
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-17 10:15 -0800
Re: faster than c wssimms@gmail.com - 2015-01-17 10:31 -0800
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-17 19:10 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 11:21 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 11:13 -0800
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-01-17 12:32 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 11:01 +0100
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-01-19 08:24 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 22:52 +0100
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-20 00:04 -0600
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-01-19 10:12 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 23:05 +0100
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-01-19 16:23 -0800
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 09:32 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-03-24 19:08 +0100
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 12:31 -0700
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-25 12:45 -0700
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-03-25 12:58 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-03-25 21:22 +0100
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 16:30 -0700
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-03-26 00:50 +0100
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 09:20 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-03-26 00:55 +0100
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-03-26 01:06 +0100
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-03-26 11:34 +0100
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-03-25 20:29 -0700
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 16:34 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-03-26 13:53 +1300
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 15:08 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-03-29 11:28 +1300
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-30 12:42 -0700
Re: faster than c Kaz Kylheku <kaz@kylheku.com> - 2015-03-30 20:06 +0000
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-03-31 16:37 +1300
Re: faster than c Kaz Kylheku <kaz@kylheku.com> - 2015-03-31 05:13 +0000
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-15 15:23 -0700
Re: faster than c Martin Shobe <martin.shobe@yahoo.com> - 2015-04-16 10:02 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-17 10:58 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-18 08:26 +1200
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-04-17 13:51 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-18 11:24 +1200
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-04-18 12:11 -0700
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-19 08:29 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-18 13:08 +0200
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-18 23:33 +1200
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-18 14:19 +0200
Re: faster than c raltbos@xs4all.nl (Richard Bos) - 2015-04-19 14:43 +0000
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-04-19 13:46 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-19 23:33 +0200
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-22 10:25 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-23 00:37 +0200
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-23 00:25 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-23 19:36 +1200
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-23 09:10 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-24 09:19 +0200
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-23 13:41 +0200
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-23 10:36 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-24 09:25 +0200
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-24 04:45 -0700
Re: faster than c Bartc <bc@freeuk.com> - 2015-04-24 13:36 +0100
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-04-27 06:16 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-24 14:44 +0200
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-24 07:10 -0700
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-24 07:03 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-04-24 16:22 +0200
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-19 08:18 -0700
Re: faster than c Martin Shobe <martin.shobe@yahoo.com> - 2015-04-17 16:58 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-19 09:21 -0700
Re: faster than c Martin Shobe <martin.shobe@yahoo.com> - 2015-04-20 12:51 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-22 10:47 -0700
Re: faster than c Martin Shobe <martin.shobe@yahoo.com> - 2015-04-22 17:20 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-24 07:51 -0700
Re: faster than c Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-04-17 23:10 +0000
Re: faster than c raltbos@xs4all.nl (Richard Bos) - 2015-04-19 14:46 +0000
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-19 08:56 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-03-31 16:33 +1300
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-15 22:56 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-16 20:06 +1200
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-17 08:44 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-16 20:21 +1200
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-17 09:55 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-18 15:43 +1200
Re: faster than c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-18 11:33 +0100
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-19 12:36 +1200
Re: faster than c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-19 11:24 +0100
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-18 20:07 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-19 15:59 +1200
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-22 14:04 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-04-19 16:52 +1200
Re: faster than c Paavo Helde <myfirstname@osa.pri.ee> - 2015-04-19 09:27 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-15 23:04 -0700
Re: faster than c Philip Lantz <prl@canterey.us> - 2015-03-31 00:14 -0700
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-04-16 00:18 -0700
Re: faster than c wssimms@gmail.com - 2015-01-17 10:33 -0800
Re: faster than c Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-17 20:03 +0000
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 11:07 +0100
Re: faster than c wpihughes@gmail.com - 2015-01-26 13:30 -0800
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-01-18 16:36 +1300
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-17 19:02 +0000
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 19:14 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 11:41 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 12:06 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 20:36 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 13:01 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 21:18 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 13:36 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 11:17 +0100
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-19 10:40 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 03:29 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 03:41 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 12:45 +0100
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 04:00 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 04:31 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 04:48 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 15:23 +0100
Re: faster than c mark.bluemel@gmail.com - 2015-01-19 07:25 -0800
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-19 08:56 -0800
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-19 17:01 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 09:08 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 09:19 -0800
Re: faster than c Bartc <bc@freeuk.com> - 2015-01-19 17:46 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 10:19 -0800
Re: faster than c Geoff <geoff@invalid.invalid> - 2015-01-19 10:56 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 11:30 -0800
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-01-19 14:22 -0800
Re: faster than c mark.bluemel@gmail.com - 2015-01-20 00:45 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-20 01:20 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 08:25 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-20 00:57 -0800
Re: faster than c fmassei@gmail.com - 2015-01-19 03:58 -0800
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-20 00:05 -0600
Re: faster than c fmassei@gmail.com - 2015-01-20 02:11 -0800
Re: faster than c asetofsymbols@gmail.com - 2015-01-20 02:18 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-20 02:30 -0800
Re: faster than c asetofsymbols@gmail.com - 2015-01-20 05:16 -0800
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-20 14:18 +0100
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-20 15:29 -0600
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-20 21:53 +0000
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-20 17:37 -0600
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-21 00:05 +0000
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-21 01:38 -0600
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-21 07:46 +0000
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-21 03:23 -0800
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-21 13:52 +0000
Re: faster than c Morris Dovey <mrdovey@iedu.com> - 2015-01-21 08:53 -0600
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-21 01:18 +0100
Re: faster than c fmassei@gmail.com - 2015-01-20 16:41 -0800
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-21 01:58 +0100
Re: faster than c fmassei@gmail.com - 2015-01-20 17:11 -0800
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-21 02:18 +0100
Re: faster than c fmassei@gmail.com - 2015-01-20 17:38 -0800
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-01-21 08:48 -0800
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-20 15:24 -0600
Re: faster than c fmassei@gmail.com - 2015-01-20 13:38 -0800
Re: faster than c Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-21 16:43 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-21 10:09 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-24 01:15 -0800
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-21 23:59 -0600
Re: faster than c fmassei@gmail.com - 2015-01-22 01:17 -0800
Re: faster than c wssimms@gmail.com - 2015-01-22 05:16 -0800
Re: faster than c fmassei@gmail.com - 2015-01-22 05:27 -0800
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-22 05:36 -0800
Re: faster than c fmassei@gmail.com - 2015-01-22 05:54 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-22 05:55 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-22 15:18 +0100
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-23 00:53 -0600
Re: faster than c fmassei@gmail.com - 2015-01-23 00:36 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-23 01:09 -0800
Re: faster than c fmassei@gmail.com - 2015-01-23 01:33 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-23 01:55 -0800
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-01-23 22:44 +1300
Re: faster than c fmassei@gmail.com - 2015-01-23 01:56 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-22 15:11 +0100
Re: faster than c fmassei@gmail.com - 2015-01-22 06:21 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-22 16:46 +0100
Re: faster than c fmassei@gmail.com - 2015-01-22 07:58 -0800
Re: faster than c Lowell Gilbert <lgusenet@be-well.ilk.org> - 2015-01-22 12:29 -0500
Re: faster than c fmassei@gmail.com - 2015-01-22 10:09 -0800
Re: faster than c "Chris M. Thomasson" <no@spam.invalid> - 2015-01-22 14:07 -0800
Re: faster than c asetofsymbols@gmail.com - 2015-01-24 00:40 -0800
Re: faster than c "Chris M. Thomasson" <no@spam.invalid> - 2015-01-24 12:53 -0800
Re: faster than c Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-22 15:09 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-22 01:59 -0800
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 09:46 -0700
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-03-25 02:15 -0500
Re: faster than c asetofsymbols@gmail.com - 2015-03-25 02:45 -0700
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 11:30 -0700
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-03-26 00:42 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 11:35 -0700
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-01-17 14:42 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 22:53 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 15:13 -0800
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-17 22:02 +0000
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-17 16:21 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-18 01:27 +0000
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-18 01:41 +0000
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-18 00:11 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-18 11:23 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-18 05:55 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-18 20:11 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-18 13:12 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-18 23:11 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-18 15:49 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-18 16:06 -0800
Re: faster than c Bartc <bc@freeuk.com> - 2015-01-19 01:03 +0000
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-19 08:13 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 01:39 -0800
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-18 13:52 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-18 23:36 +0000
Re: faster than c Walter Banks <walter@bytecraft.com> - 2015-01-20 14:01 -0500
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-20 11:18 -0800
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-17 22:30 +0100
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-01-18 16:49 +1300
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 05:55 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 14:30 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 07:32 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 15:56 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 08:33 -0800
Re: faster than c fmassei@gmail.com - 2015-01-19 02:26 -0800
faster than c asetofsymbols@gmail.com - 2015-01-20 00:12 -0800
Page 5 of 14 — ← Prev page 1 … 3 4 [5] 6 7 … 14 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-17 13:51 -0700 |
| Message-ID | <877ftaqy02.fsf@kst-u.example.com> |
| In reply to | #60263 |
Ian Collins <ian-news@hotmail.com> writes:
[...]
> VLAs would interfere with where C++ is. A simple example:
>
> const size_t bufferSize = 42;
>
> void f()
> {
> char buffer[bufferSize];
> }
>
> declares an array in C++ and a VLA in C!
Yes, but only because C++ has different rules for constant expressions.
If VLAs were added to C++, then your example would continue to be an
ordinary array, but C++ would gain the ability to do things like:
void f(size_t len) {
char buffer[len];
}
I'm not necessarily advocating this (most uses of VLAs might be better
handled in C++ by using one of the standard library container classes),
but the minor difference you mention is not an obstacle.
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-04-18 11:24 +1200 |
| Message-ID | <cpdj0gFl1o8U1@mid.individual.net> |
| In reply to | #60267 |
Keith Thompson wrote:
> Ian Collins <ian-news@hotmail.com> writes:
> [...]
>> VLAs would interfere with where C++ is. A simple example:
>>
>> const size_t bufferSize = 42;
>>
>> void f()
>> {
>> char buffer[bufferSize];
>> }
>>
>> declares an array in C++ and a VLA in C!
>
> Yes, but only because C++ has different rules for constant expressions.
> If VLAs were added to C++, then your example would continue to be an
> ordinary array, but C++ would gain the ability to do things like:
>
> void f(size_t len) {
> char buffer[len];
> }
My example would continue to be an ordinary array until someone lost the
const in the the size definition and then the programme's would change
in unforeseen ways. VLAs are a disaster waiting to happen in C, in C++
there would be more opportunities for a disaster!
> I'm not necessarily advocating this (most uses of VLAs might be better
> handled in C++ by using one of the standard library container classes),
> but the minor difference you mention is not an obstacle.
This (better existing solutions) is the main reason they'll never get
added. I think most on the C++ community consider the absence of VLAs
to be a big plus....
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-18 12:11 -0700 |
| Message-ID | <87383xqmj7.fsf@kst-u.example.com> |
| In reply to | #60278 |
Ian Collins <ian-news@hotmail.com> writes:
> Keith Thompson wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>> [...]
>>> VLAs would interfere with where C++ is. A simple example:
>>>
>>> const size_t bufferSize = 42;
>>>
>>> void f()
>>> {
>>> char buffer[bufferSize];
>>> }
>>>
>>> declares an array in C++ and a VLA in C!
>>
>> Yes, but only because C++ has different rules for constant expressions.
>> If VLAs were added to C++, then your example would continue to be an
>> ordinary array, but C++ would gain the ability to do things like:
>>
>> void f(size_t len) {
>> char buffer[len];
>> }
>
> My example would continue to be an ordinary array until someone lost
> the const in the the size definition and then the programme's would
> change in unforeseen ways. VLAs are a disaster waiting to happen in
> C, in C++ there would be more opportunities for a disaster!
In a hypothetical C++ with VLAs (or C with different constant expression
rules), this:
const size_t bufferSize = 42;
char buffer[bufferSize];
is not a VLA, but this:
size_t bufferSize = 42;
char buffer[bufferSize];
is a VLA. What disaster do you see happening when the "const"
is removed? `sizeof buffer` is still 42, indexing still works, the
array name still decays to a `char*` in most contexts, and so forth.
[...]
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-19 08:29 -0700 |
| Message-ID | <kfnpp70uofv.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60278 |
Ian Collins <ian-news@hotmail.com> writes:
> Keith Thompson wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>> [...]
>>> VLAs would interfere with where C++ is. A simple example:
>>>
>>> const size_t bufferSize = 42;
>>>
>>> void f()
>>> {
>>> char buffer[bufferSize];
>>> }
>>>
>>> declares an array in C++ and a VLA in C!
>>
>> Yes, but only because C++ has different rules for constant
>> expressions. If VLAs were added to C++, then your example would
>> continue to be an ordinary array, but C++ would gain the ability
>> to do things like:
>>
>> void f(size_t len) {
>> char buffer[len];
>> }
>
> My example would continue to be an ordinary array until someone
> lost the const in the the size definition and then the programme's
> would change in unforeseen ways. VLAs are a disaster waiting to
> happen in C, in C++ there would be more opportunities for a
> disaster!
The VLAs being discussed are those of C11, which are an optional
language feature. If VLAs were added to C++ on the same basis
as they are in C11, it would be about two nanoseconds before
there were compiler options to choose the "don't suppport" case,
and about three nanoseconds before that became the default. The
scenario you're describing is overblown, and not realistic.
>> I'm not necessarily advocating this (most uses of VLAs might be
>> better handled in C++ by using one of the standard library
>> container classes), but the minor difference you mention is not
>> an obstacle.
>
> This (better existing solutions) is the main reason they'll never
> get added. I think most on the C++ community consider the absence
> of VLAs to be a big plus....
And they can still get that with VLAs being an optional language
feature.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-18 13:08 +0200 |
| Message-ID | <mgtdti$95f$1@dont-email.me> |
| In reply to | #60263 |
On 17/04/15 22:26, Ian Collins wrote:
> Tim Rentsch wrote:
>> Martin Shobe <martin.shobe@yahoo.com> writes:
>>>
>>> They did add some. E.g. __func__, variardic macros, long long,
>>> extended integral types. From what I heard, the C and C++
>>> committees tried to keep their the changes they made to support
>>> threading reasonably compatible. From what I've seen, the C++
>>> committee's attitude is keep it compatible unless it interferes
>>> with the direction they want to take C++ in.
>>
>> This position sounds reasonable, but in terms of practical
>> results it seems not too different from we'll put it in if
>> we feel like it. Consider a small set of constructs present
>> in C but not (AFAIK but please correct if wrong) in C++:
>>
>> restrict
>> compound literals
>> designated initializers
>> variable length arrays
>> complex floating point values
>>
>> I think these could be added to C++ as follows:
>>
>> restrict - accept the syntax, and add the needed rules for
>> type compatibility (which are rarely transgressed), but
>> without any semantic consequences (which is conforming
>> for what restrict does).
>
> A qualified yes to this one especially given most compilers have a
> common front end. In C++ code (where pointers are typically hidden in
> objects) restrict would have less use than in C. So I guess the small
> additional complexity to the language isn't seen as enough of an advantage.
Both gcc and clang have a __restrict__ keyword in C++ as an extension.
This suggests that there should be no major issues (other than the usual
conflicts with existing identifiers) with introducing restrict to C++.
>
>> compound literals and designated initializers - accept these
>> constructs as C accepts them, perhaps limited to data types
>> that are legal in C programs.
>
> Designated initialisers would be a simple and useful addition and I've
> never bought into the arguments against adding them to C++. In the
> embedded and driver space designated initialisers are frequently used to
> create static objects which would work well with C++'s constexpr.
> Neither of the workarounds on offer when working with C structs
> (wrapping them or initialising them in a C file) are satisfactory.
>
>> VLAs and complex - add these to C++ in the same way that C11
>> does, ie, optional features whose presence is checkable via
>> a pre-processor macro; implementations could put them in
>> or not, as they choose.
>
> VLAs are a disaster and would be incompatible with C++!
No, VLA's are simply not a feature that is often useful. There are
times when a VLA is a better choice than a statically sized array, or a
dynamic array on the heap (since VLA's typically go on the stack).
gcc (and probably clang) accept them in C++ as an extension.
Of course, there can be benefits in using a C++ class that wraps them up
as a standard container - I think (but could be wrong) there was a
std::dynarray template suggested, but it didn't make it into C++14.
>
> C++ already has std::complex.
Yes, neatly made almost but not quite compatible with C's complex types.
Certainly using a class is the most natural choice for C++, rather
than extending the language, and complex numbers are rare enough that
compatibility is not a big issue.
>
>> It's hard to see how any of these interfere with where C++
>> is or where it seems likely to go. Granted, some of them
>> may appear quaint and old-fashioned compared to some future
>> super-duper new C++ construct, but I don't think they
>> would actually interfere with such constructs. What's the
>> problem? From where I sit it looks like snooty stubbornness,
>> nothing more.
>
> VLAs would interfere with where C++ is. A simple example:
>
> const size_t bufferSize = 42;
>
> void f()
> {
> char buffer[bufferSize];
> }
>
> declares an array in C++ and a VLA in C!
>
That's true - but what difference does it make? I can't see how there
would be any difference (either from the programmer's viewpoint, or the
generated code) between an array with static size, and a VLA whose size
happens to be known at compile time.
(Far more useful than C++ copying C's VLAs would be for C to copy C++'s
ability to make statically allocated arrays using const values for their
size, reducing the need of #define's or abused enum constants.)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-04-18 23:33 +1200 |
| Message-ID | <cpetp4Fl1o8U4@mid.individual.net> |
| In reply to | #60303 |
David Brown wrote:
> On 17/04/15 22:26, Ian Collins wrote:
>> Tim Rentsch wrote:
>>> Martin Shobe <martin.shobe@yahoo.com> writes:
>>>>
>>>> They did add some. E.g. __func__, variardic macros, long long,
>>>> extended integral types. From what I heard, the C and C++
>>>> committees tried to keep their the changes they made to support
>>>> threading reasonably compatible. From what I've seen, the C++
>>>> committee's attitude is keep it compatible unless it interferes
>>>> with the direction they want to take C++ in.
>>>
>>> This position sounds reasonable, but in terms of practical
>>> results it seems not too different from we'll put it in if
>>> we feel like it. Consider a small set of constructs present
>>> in C but not (AFAIK but please correct if wrong) in C++:
>>>
>>> restrict
>>> compound literals
>>> designated initializers
>>> variable length arrays
>>> complex floating point values
>>>
>>> I think these could be added to C++ as follows:
>>>
>>> restrict - accept the syntax, and add the needed rules for
>>> type compatibility (which are rarely transgressed), but
>>> without any semantic consequences (which is conforming
>>> for what restrict does).
>>
>> A qualified yes to this one especially given most compilers have a
>> common front end. In C++ code (where pointers are typically hidden in
>> objects) restrict would have less use than in C. So I guess the small
>> additional complexity to the language isn't seen as enough of an advantage.
>
> Both gcc and clang have a __restrict__ keyword in C++ as an extension.
> This suggests that there should be no major issues (other than the usual
> conflicts with existing identifiers) with introducing restrict to C++.
I didn't say there were issues, just additional complexity for little gain.
>>> VLAs and complex - add these to C++ in the same way that C11
>>> does, ie, optional features whose presence is checkable via
>>> a pre-processor macro; implementations could put them in
>>> or not, as they choose.
>>
>> VLAs are a disaster and would be incompatible with C++!
>
> No, VLA's are simply not a feature that is often useful. There are
> times when a VLA is a better choice than a statically sized array, or a
> dynamic array on the heap (since VLA's typically go on the stack).
>
> gcc (and probably clang) accept them in C++ as an extension.
>
> Of course, there can be benefits in using a C++ class that wraps them up
> as a standard container - I think (but could be wrong) there was a
> std::dynarray template suggested, but it didn't make it into C++14.
Whether VLAs are a disaster or not is a matter of opinion. I consider
them a ticking time bomb...
>> C++ already has std::complex.
>
> Yes, neatly made almost but not quite compatible with C's complex types.
But std::complex did precede C99.
>> VLAs would interfere with where C++ is. A simple example:
>>
>> const size_t bufferSize = 42;
>>
>> void f()
>> {
>> char buffer[bufferSize];
>> }
>>
>> declares an array in C++ and a VLA in C!
>>
>
> That's true - but what difference does it make?
With a static size, static analysis tools can determine stack size.
> I can't see how there
> would be any difference (either from the programmer's viewpoint, or the
> generated code) between an array with static size, and a VLA whose size
> happens to be known at compile time.
>
> (Far more useful than C++ copying C's VLAs would be for C to copy C++'s
> ability to make statically allocated arrays using const values for their
> size, reducing the need of #define's or abused enum constants.)
Indeed.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-18 14:19 +0200 |
| Message-ID | <mgti28$n35$1@dont-email.me> |
| In reply to | #60306 |
On 18/04/15 13:33, Ian Collins wrote:
> David Brown wrote:
>> On 17/04/15 22:26, Ian Collins wrote:
>>> Tim Rentsch wrote:
>>>> Martin Shobe <martin.shobe@yahoo.com> writes:
>>>>>
<snip>
>>> A qualified yes to this one especially given most compilers have a
>>> common front end. In C++ code (where pointers are typically hidden in
>>> objects) restrict would have less use than in C. So I guess the small
>>> additional complexity to the language isn't seen as enough of an
>>> advantage.
>>
>> Both gcc and clang have a __restrict__ keyword in C++ as an extension.
>> This suggests that there should be no major issues (other than the usual
>> conflicts with existing identifiers) with introducing restrict to C++.
>
> I didn't say there were issues, just additional complexity for little gain.
Agreed.
>
>>>> VLAs and complex - add these to C++ in the same way that C11
>>>> does, ie, optional features whose presence is checkable via
>>>> a pre-processor macro; implementations could put them in
>>>> or not, as they choose.
>>>
>>> VLAs are a disaster and would be incompatible with C++!
>>
>> No, VLA's are simply not a feature that is often useful. There are
>> times when a VLA is a better choice than a statically sized array, or a
>> dynamic array on the heap (since VLA's typically go on the stack).
>>
>> gcc (and probably clang) accept them in C++ as an extension.
>>
>> Of course, there can be benefits in using a C++ class that wraps them up
>> as a standard container - I think (but could be wrong) there was a
>> std::dynarray template suggested, but it didn't make it into C++14.
>
> Whether VLAs are a disaster or not is a matter of opinion. I consider
> them a ticking time bomb...
I was getting that impression!
>
>>> C++ already has std::complex.
>>
>> Yes, neatly made almost but not quite compatible with C's complex types.
>
> But std::complex did precede C99.
Fair enough then. C99 clearly could not copy the C++ complex numbers.
>
>>> VLAs would interfere with where C++ is. A simple example:
>>>
>>> const size_t bufferSize = 42;
>>>
>>> void f()
>>> {
>>> char buffer[bufferSize];
>>> }
>>>
>>> declares an array in C++ and a VLA in C!
>>>
>>
>> That's true - but what difference does it make?
>
> With a static size, static analysis tools can determine stack size.
That's not an issue - a compiler that can see that the VLA is created
with a compile-time known size can apply exactly the same static
checking (and exactly the same code generation and optimisation - a
lesser issue, but still nice).
I don't know whether compilers currently do this or not - but they
certainly /could/ do it, so it's a quality of implementation question,
not a language issue.
>
>> I can't see how there
>> would be any difference (either from the programmer's viewpoint, or the
>> generated code) between an array with static size, and a VLA whose size
>> happens to be known at compile time.
>>
>> (Far more useful than C++ copying C's VLAs would be for C to copy C++'s
>> ability to make statically allocated arrays using const values for their
>> size, reducing the need of #define's or abused enum constants.)
>
> Indeed.
>
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-04-19 14:43 +0000 |
| Message-ID | <5533bee7.20848406@news.xs4all.nl> |
| In reply to | #60303 |
David Brown <david.brown@hesbynett.no> wrote: > (Far more useful than C++ copying C's VLAs would be for C to copy C++'s > ability to make statically allocated arrays using const values for their > size, reducing the need of #define's or abused enum constants.) I would second this. If there's one thing I think could be improved in C, apart from some trivialities, it's its reluctance to make use of the undefinedness of changing a const value. Richard
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-04-19 13:46 -0700 |
| Message-ID | <871tjfq21s.fsf@kst-u.example.com> |
| In reply to | #60303 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> (Far more useful than C++ copying C's VLAs would be for C to copy
> C++'s ability to make statically allocated arrays using const values
> for their size, reducing the need of #define's or abused enum
> constants.)
To be precise, I think what you're suggesting (and I'd like to
see it too) is for the name of a const-qualified object whose
initialization is a constant expression to be a constant expression.
It's not just about arrays; it's useful in any context that requires
a constant expression.
For example, given:
const int n = 42;
the expression `n` would be a constant expression, usable as the
size of a static array, as a case label, etc. But &n would still
give you the address of a `const int` object with the value 42.
And of course given:
const int r = rand();
the expression `r` still would *not* be a constant expression.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-19 23:33 +0200 |
| Message-ID | <mh16t9$6fb$1@dont-email.me> |
| In reply to | #60456 |
On 19/04/15 22:46, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> (Far more useful than C++ copying C's VLAs would be for C to copy >> C++'s ability to make statically allocated arrays using const values >> for their size, reducing the need of #define's or abused enum >> constants.) > > To be precise, I think what you're suggesting (and I'd like to > see it too) is for the name of a const-qualified object whose > initialization is a constant expression to be a constant expression. > It's not just about arrays; it's useful in any context that requires > a constant expression. > > For example, given: > > const int n = 42; > > the expression `n` would be a constant expression, usable as the > size of a static array, as a case label, etc. But &n would still > give you the address of a `const int` object with the value 42. > > And of course given: > > const int r = rand(); > > the expression `r` still would *not* be a constant expression. > Yes, I was suggesting something like that - but didn't want to hijack the subthread by going into detail. I think basically I would like to be able to use a "const int" defined object anywhere I can also use an "enum" constant or a #define'd integer constant.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-22 10:25 -0700 |
| Message-ID | <kfnsibst6qv.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60466 |
David Brown <david.brown@hesbynett.no> writes: > [snip] > > I think basically I would like to be able to use a "const int" > defined object anywhere I can also use an "enum" constant or a > #define'd integer constant. I don't think you mean literally what you said.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-23 00:37 +0200 |
| Message-ID | <mh97oh$gca$1@dont-email.me> |
| In reply to | #60761 |
On 22/04/15 19:25, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> [snip]
>>
>> I think basically I would like to be able to use a "const int"
>> defined object anywhere I can also use an "enum" constant or a
>> #define'd integer constant.
>
> I don't think you mean literally what you said.
>
I should have qualified this to mean a const int with the definition
known to the compiler at the time - it could not work with externally
defined const int's.
(In C++, a "const" definition without an extern declaration is viewed as
"static", which I think is a nice feature.)
I want to be able to used const int's like this:
const int bufferSize = 1024;
char buffer[bufferSize];
const int A = 1;
const int B = 2;
void foo(int x) {
switch (x) {
case A : ...
break;
case B : ...
break;
}
}
In C, an identifier declared as a "const" is not a constant expression,
and can't be used as one - even though any attempt to modify it is
undefined behaviour. In C++, such identifiers /are/ constant
expressions and can be used in this way.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-04-23 00:25 -0700 |
| Message-ID | <b0692b7a-f0f2-47a0-8280-d6373f8d01c1@googlegroups.com> |
| In reply to | #60820 |
On Thursday, 23 April 2015 01:37:09 UTC+3, David Brown wrote:
> On 22/04/15 19:25, Tim Rentsch wrote:
> > David Brown <david.brown@hesbynett.no> writes:
> >
> >> [snip]
> >>
> >> I think basically I would like to be able to use a "const int"
> >> defined object anywhere I can also use an "enum" constant or a
> >> #define'd integer constant.
> >
> > I don't think you mean literally what you said.
> >
>
> I should have qualified this to mean a const int with the definition
> known to the compiler at the time - it could not work with externally
> defined const int's.
>
> (In C++, a "const" definition without an extern declaration is viewed as
> "static", which I think is a nice feature.)
>
> I want to be able to used const int's like this:
>
> const int bufferSize = 1024;
> char buffer[bufferSize];
>
> const int A = 1;
> const int B = 2;
The 'const' declares intent of developer to not modify variable
after declaration regardless if the value is known or not compile time.
const int B = rand() % 42;
> void foo(int x) {
> switch (x) {
> case A : ...
> break;
> case B : ...
> break;
> }
> }
Lets try to take step further to see why it might be not good idea?
Adding 'static' instead of 'const' to the variables 'bufferSize',
'A' and 'B', initializing these with constant expressions and not
changing the values or passing the addresses of those anywhere will
cause optimizing compilers to detect that those have compile-time
known values all time. Such compiler will replace all usages with
constants in produced binary despite the variables are declared
mutable.
So technically the language rules could be further relaxed to allow
compiler to complain about 'case A:' only when it can't prove that 'A'
is constant compile-time. However that would *require* such deep
optimizer-level analysis from C compilers.
> In C, an identifier declared as a "const" is not a constant expression,
> and can't be used as one - even though any attempt to modify it is
> undefined behaviour. In C++, such identifiers /are/ constant
> expressions and can be used in this way.
I trust that C++ standardization committee have also realized that
context-dependent dual meaning of 'const' ('immutable value' versus
'constant expression') was mistake. Otherwise why 'constexpr'
was added to C++11?
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-04-23 19:36 +1200 |
| Message-ID | <cprlniF6f3iU1@mid.individual.net> |
| In reply to | #60843 |
Öö Tiib wrote:
>
> I trust that C++ standardization committee have also realized that
> context-dependent dual meaning of 'const' ('immutable value' versus
> 'constant expression') was mistake. Otherwise why 'constexpr'
> was added to C++11?
"constexpr" does a lot more than "const".
It guarantees that an initialisation is done at compile time and it
allows constant expressions involving user-defined types. The most
significant addition (required for expressions involving user-defined
types) is allowing functions to return compile time constants.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-04-23 09:10 -0700 |
| Message-ID | <dab32856-f505-4ddc-8ad1-3e590be40381@googlegroups.com> |
| In reply to | #60845 |
On Thursday, 23 April 2015 10:36:27 UTC+3, Ian Collins wrote:
> 嘱 Tiib wrote:
> >
> > I trust that C++ standardization committee have also realized that
> > context-dependent dual meaning of 'const' ('immutable value' versus
> > 'constant expression') was mistake. Otherwise why 'constexpr'
> > was added to C++11?
>
> "constexpr" does a lot more than "const".
>
> It guarantees that an initialisation is done at compile time and it
> allows constant expressions involving user-defined types. The most
> significant addition (required for expressions involving user-defined
> types) is allowing functions to return compile time constants.
You are correct indeed. Still if microsoft ever implements 'constexpr'
(stops that "partial" nonsense) then it becomes highly likely that
C++ will take a step back closer to C and start to deprecate
'const's usage in sense of 'constexpr' of C++98 that David
demonstrated. That would improve clarity a lot.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-24 09:19 +0200 |
| Message-ID | <mhcqna$no$1@dont-email.me> |
| In reply to | #60913 |
On 23/04/15 18:10, Öö Tiib wrote:
> On Thursday, 23 April 2015 10:36:27 UTC+3, Ian Collins wrote:
>> 嘱 Tiib wrote:
>>>
>>> I trust that C++ standardization committee have also realized that
>>> context-dependent dual meaning of 'const' ('immutable value' versus
>>> 'constant expression') was mistake. Otherwise why 'constexpr'
>>> was added to C++11?
>>
>> "constexpr" does a lot more than "const".
>>
>> It guarantees that an initialisation is done at compile time and it
>> allows constant expressions involving user-defined types. The most
>> significant addition (required for expressions involving user-defined
>> types) is allowing functions to return compile time constants.
>
> You are correct indeed. Still if microsoft ever implements 'constexpr'
> (stops that "partial" nonsense) then it becomes highly likely that
> C++ will take a step back closer to C and start to deprecate
> 'const's usage in sense of 'constexpr' of C++98 that David
> demonstrated. That would improve clarity a lot.
>
See my other reply.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-23 13:41 +0200 |
| Message-ID | <mhaln0$nek$1@dont-email.me> |
| In reply to | #60843 |
On 23/04/15 09:25, Öö Tiib wrote:
> On Thursday, 23 April 2015 01:37:09 UTC+3, David Brown wrote:
>> On 22/04/15 19:25, Tim Rentsch wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> [snip]
>>>>
>>>> I think basically I would like to be able to use a "const int"
>>>> defined object anywhere I can also use an "enum" constant or a
>>>> #define'd integer constant.
>>>
>>> I don't think you mean literally what you said.
>>>
>>
>> I should have qualified this to mean a const int with the definition
>> known to the compiler at the time - it could not work with externally
>> defined const int's.
>>
>> (In C++, a "const" definition without an extern declaration is viewed as
>> "static", which I think is a nice feature.)
>>
>> I want to be able to used const int's like this:
>>
>> const int bufferSize = 1024;
>> char buffer[bufferSize];
>>
>> const int A = 1;
>> const int B = 2;
>
> The 'const' declares intent of developer to not modify variable
> after declaration regardless if the value is known or not compile time.
>
> const int B = rand() % 42;
That is not valid for global (file scope or function static) data. I
should have said I was referring only to global constants (I had the
feeling I had missed something important).
For static lifetime constant data, you do need to have a compile-time
known initialiser.
>
>> void foo(int x) {
>> switch (x) {
>> case A : ...
>> break;
>> case B : ...
>> break;
>> }
>> }
>
> Lets try to take step further to see why it might be not good idea?
>
> Adding 'static' instead of 'const' to the variables 'bufferSize',
> 'A' and 'B', initializing these with constant expressions and not
> changing the values or passing the addresses of those anywhere will
> cause optimizing compilers to detect that those have compile-time
> known values all time. Such compiler will replace all usages with
> constants in produced binary despite the variables are declared
> mutable.
The variables are not mutable if they are "const". But yes, if they are
merely declared "static" but not "const", and they cannot escape and be
legally changed elsewhere, then the compiler can optimise by using the
constant value directly.
>
> So technically the language rules could be further relaxed to allow
> compiler to complain about 'case A:' only when it can't prove that 'A'
> is constant compile-time. However that would *require* such deep
> optimizer-level analysis from C compilers.
Agreed - it could be theoretically possible, but it would complicate the
language and the implementation because a "static int" could sometimes
be used as a label, sometimes not. It would be much easier to say that
it can be used as a label if and only if it is a "const" with a constant
initialiser (or perhaps only if it is a static constant, and therefore
/must/ have a constant initialiser).
>
>> In C, an identifier declared as a "const" is not a constant expression,
>> and can't be used as one - even though any attempt to modify it is
>> undefined behaviour. In C++, such identifiers /are/ constant
>> expressions and can be used in this way.
>
> I trust that C++ standardization committee have also realized that
> context-dependent dual meaning of 'const' ('immutable value' versus
> 'constant expression') was mistake. Otherwise why 'constexpr'
> was added to C++11?
>
As Ian said, constexpr covers other things and is "even more constant".
I am sure that the committee understand that the meaning of "const" can
be significantly different in different contexts, but I doubt if they
view it as a "mistake". (Does the C standards committee call the
multiple uses of "static" a mistake?) But even if you view it as a
mistake, it does not mean there is any good reason not to treat global
const objects (or local const objects with compile-time-constant
initialisers) as true constants, and letting you use them for buffer
sizes, etc.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-04-23 10:36 -0700 |
| Message-ID | <28f726a5-05f8-4975-b98c-8c3583ee0102@googlegroups.com> |
| In reply to | #60873 |
On Thursday, 23 April 2015 14:41:24 UTC+3, David Brown wrote:
> On 23/04/15 09:25, 嘱 Tiib wrote:
...
> > So technically the language rules could be further relaxed to allow
> > compiler to complain about 'case A:' only when it can't prove that 'A'
> > is constant compile-time. However that would *require* such deep
> > optimizer-level analysis from C compilers.
>
> Agreed - it could be theoretically possible, but it would complicate the
> language and the implementation because a "static int" could sometimes
> be used as a label, sometimes not.
So there we agree.
> It would be much easier to say that it can be used as a label if and
> only if it is a "const" with a constant initialiser (or perhaps only
> if it is a static constant, and therefore /must/ have a constant
> initialiser).
It is also complication, just not so big one.
For example should that work?:
static char const Keys[] = "ABC";
void foo(int x) {
switch (x) {
case Keys[0]: ...
break;
case Keys[1]: ...
break;
}
}
From your description it feels that maybe it should.
...
> > I trust that C++ standardization committee have also realized that
> > context-dependent dual meaning of 'const' ('immutable value' versus
> > 'constant expression') was mistake. Otherwise why 'constexpr'
> > was added to C++11?
> >
>
> As Ian said, constexpr covers other things and is "even more constant".
Ian clarified that 'constexpr' is "lot more" in sense that it also
deprecates some most obscure usages of C++ template system and
the like. Or so I understood.
You technically suggested to use 'static const' in sense of
constant expression. What can be "more constant" than constant
expression?
> I am sure that the committee understand that the meaning of "const" can
> be significantly different in different contexts, but I doubt if they
> view it as a "mistake". (Does the C standards committee call the
> multiple uses of "static" a mistake?)
Yes, I was too "telepathic" there, sorry. :D
> But even if you view it as a mistake, it does not mean there is any
> good reason not to treat global const objects (or local const objects
> with compile-time-constant initialisers) as true constants, and
> letting you use them for buffer sizes, etc.
For me it means. I did prefer 'static const' to preprocessor constants
in C++98 code, but it did still feel like hack about only "integral
constants" and other corner case limits. I upgrade to 'constexpr'
where I only can. If C added old half-baked hack of C++98 now when
C++ is moving away of it then I would feel disappointed.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-24 09:25 +0200 |
| Message-ID | <mhcr3t$1jh$1@dont-email.me> |
| In reply to | #60920 |
On 23/04/15 19:36, Öö Tiib wrote:
> On Thursday, 23 April 2015 14:41:24 UTC+3, David Brown wrote:
>> On 23/04/15 09:25, 嘱 Tiib wrote:
>
> ...
>
>>> So technically the language rules could be further relaxed to allow
>>> compiler to complain about 'case A:' only when it can't prove that 'A'
>>> is constant compile-time. However that would *require* such deep
>>> optimizer-level analysis from C compilers.
>>
>> Agreed - it could be theoretically possible, but it would complicate the
>> language and the implementation because a "static int" could sometimes
>> be used as a label, sometimes not.
>
> So there we agree.
Yes. And I think pretty much everyone will agree that we don't need a
feature in C that works /sometimes/.
Making things more complicated is the fact that "is a
compile-time-constant" is not necessarily determined just from the
source code of the file and its headers. If you are doing some sort of
whole-program compilation and optimisation (such as LTO with gcc), one
file may declare an "extern int x", another file may define it as "int x
= 10", and if nothing else writes to it, then it can be treated as a
compile-time constant by the compiler.
But one thing we can be sure of is that if you have a file-scope or
function-static "const" definition (i.e., with an initialiser), then
that constant is a compile-time constant. It should therefore be
possible to use it whenever a compile-time constant is needed in the code.
>
>> It would be much easier to say that it can be used as a label if and
>> only if it is a "const" with a constant initialiser (or perhaps only
>> if it is a static constant, and therefore /must/ have a constant
>> initialiser).
>
> It is also complication, just not so big one.
It would be an extra clause in the standard, but an obvious one (though
some people expect compilers to do magic!).
> For example should that work?:
>
> static char const Keys[] = "ABC";
>
> void foo(int x) {
> switch (x) {
> case Keys[0]: ...
> break;
> case Keys[1]: ...
> break;
> }
> }
>
> From your description it feels that maybe it should.
I see no reason why this should not be able to work - the compiler has
all the information needed to handle this. But it is possible (nay,
likely) that in implementing such a feature, the C committee would
follow the C++ path and restrict this sort of thing to integer-type
constants.
(C++ allows it with constexpr rather than const, as constexpr is usable
on a wider range of types and expressions.)
>
> ...
>
>>> I trust that C++ standardization committee have also realized that
>>> context-dependent dual meaning of 'const' ('immutable value' versus
>>> 'constant expression') was mistake. Otherwise why 'constexpr'
>>> was added to C++11?
>>>
>>
>> As Ian said, constexpr covers other things and is "even more constant".
>
> Ian clarified that 'constexpr' is "lot more" in sense that it also
> deprecates some most obscure usages of C++ template system and
> the like. Or so I understood.
I didn't notice him saying exactly that, but he certainly could have
done. One of the "obscure" uses of templates in C++ is that you can
make the templates dependent on an integer (rather than types, which is
more "normal" usage), and use recursion in order to do compile-time
calculations. A classic example is to make a compile-time Factorial
template. constexpr eliminates this sort of thing, and makes
compile-time calculations clearer and simpler for both programmer and
compiler (especially in C++14, which allows a lot more features in
constexpr functions than C++11).
You can think of "constexpr" as meaning "constant, calculated at
compile-time", and "const" as meaning "read-only". But if an object is
defined and initialised as "read-only", then the compiler knows that it
is a compile-time constant.
>
> You technically suggested to use 'static const' in sense of
> constant expression. What can be "more constant" than constant
> expression?
"static const" inside a function follows the same rules (and therefore
could have the same abilities) as a "static const" at file scope. A
non-static "const" inside a function is a local variable that you
promise not to change after initialisation - the compiler /may/ optimise
it as a compile-time-constant, but as you pointed out it could be
run-time initialised.
(Does that answer your question? I'm not quite sure what you meant.)
Note that in C++, a file-scope (or namespace-scope) definition of "const
x = 1" (without "static" or "extern" or other previous declarations) is
treated as though it were "static const x = 1", whereas in C it (like
other definitions and declarations) is effectively "extern const x = 1".
This is done because in C++, you make a lot more use of such small,
compile-time constants (replacing #define's in C), and there is no need
to clutter up program-global namespaces.
>
>> I am sure that the committee understand that the meaning of "const" can
>> be significantly different in different contexts, but I doubt if they
>> view it as a "mistake". (Does the C standards committee call the
>> multiple uses of "static" a mistake?)
>
> Yes, I was too "telepathic" there, sorry. :D
>
>> But even if you view it as a mistake, it does not mean there is any
>> good reason not to treat global const objects (or local const objects
>> with compile-time-constant initialisers) as true constants, and
>> letting you use them for buffer sizes, etc.
>
> For me it means. I did prefer 'static const' to preprocessor constants
> in C++98 code, but it did still feel like hack about only "integral
> constants" and other corner case limits. I upgrade to 'constexpr'
> where I only can. If C added old half-baked hack of C++98 now when
> C++ is moving away of it then I would feel disappointed.
>
If we could roll back time to early C++ and "fix" things, then I think
"const" would be given the powers of the new "constexpr", and the name
"const" would be replaced with "readonly". And our simple constants
(for buffer sizes, etc.) would still be declared as "const int" - but it
would /mean/ "constexpr int".
I can agree that "constexpr" is more correct than "const" (or "static
const") for replacing pre-processor constant defines - amongst other
things, it has no artificial limitations such as the restriction to
integer types. And I would be happy to see "constexpr" supported in C.
However, I don't see that there is anything to be lost in /also/
allowing "const int" (initialised with constant data) to be treated as
though they were "constexpr int" definitions. It would feel natural, be
compatible with C++, and extend the existing usage of "const int" or
"static const int" in C - where it is already used by many instead of
#define's for constant values other than buffer sizes and switch labels.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-04-24 04:45 -0700 |
| Message-ID | <d33dcc95-19a7-42e1-96fd-762089595aa0@googlegroups.com> |
| In reply to | #60975 |
On Friday, 24 April 2015 10:25:57 UTC+3, David Brown wrote:
> On 23/04/15 19:36, Öö Tiib wrote:
> > On Thursday, 23 April 2015 14:41:24 UTC+3, David Brown wrote:
> >> On 23/04/15 09:25, 嘱 Tiib wrote:
> >
> > ...
> >
> >>> So technically the language rules could be further relaxed to allow
> >>> compiler to complain about 'case A:' only when it can't prove that 'A'
> >>> is constant compile-time. However that would *require* such deep
> >>> optimizer-level analysis from C compilers.
> >>
> >> Agreed - it could be theoretically possible, but it would complicate the
> >> language and the implementation because a "static int" could sometimes
> >> be used as a label, sometimes not.
> >
> > So there we agree.
>
> Yes. And I think pretty much everyone will agree that we don't need a
> feature in C that works /sometimes/.
That was my point. The static const in C++98 works clearly sometimes
as constant expression.
... snip with what I agree.
> >> It would be much easier to say that it can be used as a label if and
> >> only if it is a "const" with a constant initialiser (or perhaps only
> >> if it is a static constant, and therefore /must/ have a constant
> >> initialiser).
> >
> > It is also complication, just not so big one.
>
> It would be an extra clause in the standard, but an obvious one (though
> some people expect compilers to do magic!).
>
> > For example should that work?:
> >
> > static char const Keys[] = "ABC";
> >
> > void foo(int x) {
> > switch (x) {
> > case Keys[0]: ...
> > break;
> > case Keys[1]: ...
> > break;
> > }
> > }
> >
> > From your description it feels that maybe it should.
>
> I see no reason why this should not be able to work - the compiler has
> all the information needed to handle this.
Exactly, but it is ill-formed in C++. It works in C++ if to
replace 'const' with 'constexpr'. That makes me like 'constexpr'
lot more.
> But it is possible (nay,
> likely) that in implementing such a feature, the C committee would
> follow the C++ path and restrict this sort of thing to integer-type
> constants.
On either case it would not be just single clause. In both cases it
is clearly a set of rules and constraints where and when exactly
'const' means more than just immutable, so "sometimes".
> (C++ allows it with constexpr rather than const, as constexpr is usable
> on a wider range of types and expressions.)
Yes and so why to continue using 'const' as sometimes synonyme
of 'constexpr'? Generality and uniformity has became more
important in C++.
> >> But even if you view it as a mistake, it does not mean there is any
> >> good reason not to treat global const objects (or local const objects
> >> with compile-time-constant initialisers) as true constants, and
> >> letting you use them for buffer sizes, etc.
> >
> > For me it means. I did prefer 'static const' to preprocessor constants
> > in C++98 code, but it did still feel like hack about only "integral
> > constants" and other corner case limits. I upgrade to 'constexpr'
> > where I only can. If C added old half-baked hack of C++98 now when
> > C++ is moving away of it then I would feel disappointed.
> >
>
> If we could roll back time to early C++ and "fix" things, then I think
> "const" would be given the powers of the new "constexpr", and the name
> "const" would be replaced with "readonly". And our simple constants
> (for buffer sizes, etc.) would still be declared as "const int" - but it
> would /mean/ "constexpr int".
C++ was not initially made as separate language but as extension to C.
Good silver bullet publicity: easy switching from C and lot of added
buzzwords to gain.
If to imagine starting from scratch a totally separate language then
I would (purely personal preferences) suggest to:
* make everything implicitly immutable after first initialization.
It would considerably shorten my C++ code since I seem to prefer immutability where possible.
* make developer to indicate mutability with keyword (like 'mutable').
Mutability seems to be the special case in my own code that I feel
deserves more clear indication.
* indicate what has been planned to be compile-time known constant
with keyword (can be 'const' like you suggested). It may add
semantic freedom (template argument, case label or array index) and
be needed for optimizations but more important effect for me is that
it must be is diagnosed and ran during compiling. Lot of defects will
fail fast.
> I can agree that "constexpr" is more correct than "const" (or "static
> const") for replacing pre-processor constant defines - amongst other
> things, it has no artificial limitations such as the restriction to
> integer types. And I would be happy to see "constexpr" supported in C.
>
> However, I don't see that there is anything to be lost in /also/
> allowing "const int" (initialised with constant data) to be treated as
> though they were "constexpr int" definitions. It would feel natural, be
> compatible with C++, and extend the existing usage of "const int" or
> "static const int" in C - where it is already used by many instead of
> #define's for constant values other than buffer sizes and switch labels.
People have different experiences and so have different opinions. It
has taken me some time to explain it to people less familiar with C++
why 'const' works here and not there. Look at my code example above.
[toc] | [prev] | [next] | [standalone]
Page 5 of 14 — ← Prev page 1 … 3 4 [5] 6 7 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web