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 6 of 14 — ← Prev page 1 … 4 5 [6] 7 8 … 14 Next page →
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-04-24 13:36 +0100 |
| Message-ID | <mhddae$vbk$1@dont-email.me> |
| In reply to | #60989 |
On 24/04/2015 12:45, Öö Tiib wrote: > 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. Would this be for multi-valued types such as arrays and structs, or also primitives such as ints? In languages such as Python mutability means being able to modify part of an object, but types such as int can't be modified, only replaced completely by assignment. With something like an array, then sometimes the set-up can be elaborate, requiring normal mutability while it's going on, and then used as a read-only table elsewhere. Or it's mutable in some places and not in others. This is difficult to express as a one-time attribute in the source code. (With Python, I think mutability can't change, so strings are never mutable, but lists always are. But then in Python, nearly everywhere is dynamic; you can't change a character in a string, but /can/ take the name of that string variable and assign a function to it!) > * 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 agree. This is very, very simple language feature that people just don't seem to want in C, instead preferring all sorts of complicated or limited alternatives. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-04-27 06:16 -0700 |
| Message-ID | <2ef11fbc-81f1-47c1-be41-59f68e71abee@googlegroups.com> |
| In reply to | #60991 |
On Friday, 24 April 2015 15:36:36 UTC+3, Bart wrote: > On 24/04/2015 12:45, Öö Tiib wrote: > > > > 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. > > Would this be for multi-valued types such as arrays and structs, or also > primitives such as ints? > > In languages such as Python mutability means being able to modify part > of an object, but types such as int can't be modified, only replaced > completely by assignment. I meant that when I give a name to some object or reference to object regardless if the "object" is composite or primitive then on most cases it remains like that until end of scope for that name. The object stays immutable (and the reference is not made to refer and name is not made to name some other object). I now mark it with enough 'const's both in C and C++. Few names mean mutable (or variable) objects in my code. Those are usually most important names using what I build, navigate, search or accumulate something from the immutable state all around. I would like to mark the few. Something like 'var' would be enough if 'mutable' is too lot to type. In other words the way how mutability is indicated with nothing and immutability can be indicated with 'const' in C and C++ feels upside down to me (lot of const spam instead of few mutability indications). > With something like an array, then sometimes the set-up can be > elaborate, requiring normal mutability while it's going on, and then > used as a read-only table elsewhere. Or it's mutable in some places and > not in others. This is difficult to express as a one-time attribute in > the source code. Yes, setup is likely a function anyway. The object is mutable during run of set-up function. It is naturally the most important object in it anyway. Majority of objects do never change again after that initial setup. After setup we can give those a name and never worry that anything of it changes. It would be most natural to do that with most terse syntax. > (With Python, I think mutability can't change, so strings are never > mutable, but lists always are. But then in Python, nearly everywhere is > dynamic; you can't change a character in a string, but /can/ take the > name of that string variable and assign a function to it!) The difference is only on case when there are other aliases to that name and/or references to that object (or parts of it). It is the source of complexity (for programmer, for compiler and for tester) when there are several references thru what an object may be mutated and/or several aliases of name thru what the name can be reassigned. There is only sometimes need for that complicating freedom and it would be great if that was indicated.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-24 14:44 +0200 |
| Message-ID | <mhddq1$197$1@dont-email.me> |
| In reply to | #60989 |
On 24/04/15 13:45, Öö Tiib wrote:
> 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.
The static const with integer types in C++98 works /all the time/ as a
constant expression. And thus it is very useful.
It might be nice if non-integer static const's also worked as constant
expressions, but they don't (until you use constexpr). But that does
not detract from the usefulness of static const integer definitions.
What we don't need is something where the rules about what works are
unclear, or easily confused (I think most people will agree with that).
>
> ... 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.
Yes. It would have been nice if it was legal in C++ as it stands, and
there is no good reason (that I know of) why it was made illegal. But
it's hard to change the past.
>
>> 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".
Those rules are already in place, so nothing needs to be changed. If
you have "static const x = 10;" and try to change x in some way (using
casts to make the syntax legal), then the behaviour is undefined (6.7.3
in C11 standards). It's value must be a compile-time constant at
definition (6.7.9), and it cannot be legally changed at run-time
(6.7.3). Therefore it's value is known entirely at compile-time. The
"static const int" object is /already/ a compile-time constant - but the
language rules stop us (programmers and compilers) from using that fact.
>
>> (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++.
"const" will continue to be needed as it stands - there are plenty of
situations where you want "const" but "constexpr" will not work. So
"static const int x = 10" will continue to be legal. And as noted
above, it will continue to be a guaranteed compile-time constant (in C
and C++). Why would C++ stop allowing it to be used as a compile-time
constant, just because an additional method (constexpr) is introduced?
Why should C continue to disallow this obvious and simple usage?
>
>>>> 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.
If we were to list all the things we would like in a new C-like or
C++-like language, I think it would be a long list and a long thread!
>
>> 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.
>
>
Yes, opinions will vary - I can only express my own (and they may vary
too...).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-24 07:10 -0700 |
| Message-ID | <kfnoamdr51f.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60873 |
David Brown <david.brown@hesbynett.no> writes: > For static lifetime constant data, you do need to have a > compile-time known initialiser. For any static lifetime identifier, the initializer does need to be made up of constant expression(s), whether or not the identifier is 'const', but the constant expressions do not necessarily have values that can be determined at compile time.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-24 07:03 -0700 |
| Message-ID | <kfnsibpr5ch.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60820 |
David Brown <david.brown@hesbynett.no> writes: > 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. > > [snip] I want to be able to used const int's like this: > > const int bufferSize = 1024; > char buffer[bufferSize]; > > [and as case labels] I understood what you meant, all I was trying to say is that what you meant isn't the same as what you said.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-04-24 16:22 +0200 |
| Message-ID | <mhdjgs$m6h$1@dont-email.me> |
| In reply to | #60998 |
On 24/04/15 16:03, Tim Rentsch wrote: > David Brown <david.brown@hesbynett.no> writes: > >> 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. >> >> [snip] I want to be able to used const int's like this: >> >> const int bufferSize = 1024; >> char buffer[bufferSize]; >> >> [and as case labels] > > I understood what you meant, all I was trying to say > is that what you meant isn't the same as what you said. > It certainly seems that I was inaccurate in what I wrote - in particular, I was not thinking of function-local non-static consts, which do not need a compile-time constant initialiser.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-19 08:18 -0700 |
| Message-ID | <kfntwwcuoxe.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60263 |
Ian Collins <ian-news@hotmail.com> writes:
> 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.
The value is in lowering the energy barrier to transition C
code 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.
So you agree that adding designated initializers would not
interfere with where C++ is or where it is going? Do you
also agree that that holds for compound literals?
>> 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
This assessment is overly harsh. VLAs are quite useful in
certain circumstances and are not program-damaging if used
appropriately. Certainly they are not as caustic as what
can be done with goto, and C++ still has goto.
> and would be incompatible with C++!
I will take this up below.
> C++ already has std::complex.
I see no reason _Complex couldn't coexist with std::complex. The
question is not if it's better, or if C++ programmers would use
it, but does it interfere with other C++ usage or where C++ is
going? I don't see that it does. Again, the point of adding it
is not to change C++ code but to ease transition from C to C++.
>> 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!
To me this seems like a non-argument. In practical terms I
believe there is essentially no difference between the semantics
of the two cases. I think it would be perfectly okay for arrays
(in C++) to be fixed-length arrays if C++ would accept them as
such, and be VLAs only if they were not otherwise acceptable to
C++. And, since under C11 VLAs are optional, there could be a
compiler option (ie, for C++ compilers) to allow VLA support,
with a default setting of OFF. So C++ developers could ignore
VLAs, while C developers could more easily transition programs
to C++ without having to go muck about with the source. I don't
see any significant downside.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-04-17 16:58 -0500 |
| Message-ID | <mgrvkt$av7$1@dont-email.me> |
| In reply to | #60253 |
On 4/17/2015 12:58 PM, Tim Rentsch wrote: > Martin Shobe <martin.shobe@yahoo.com> writes: >> On 4/15/2015 5:23 PM, Tim Rentsch wrote: >>> [snip] >>> Getting back to the topic from upthread, ISTM that members of the >>> C++ community often suggest that C should adopt certain features >>> of C++, yet there has been rather little reciprocation from C++ in >>> terms of adopting C constructs from C99. The claim is that almost >>> all C code is legal C++ code. However, judging by the actions of >>> the C++ community (about which I should say that my experience in >>> this realm is fairly limited, but based on that), it seems that >>> they are less interested in expanding the common subset than they >>> are in following an "embrace, extend, extinguish" type strategy. >>> And if they want to prove that hypothesis wrong, that's easy to >>> do: simply add those features introduced in C99 to C++. >> >> 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). See N4150. Part of the reason that they haven't added it is that they haven't decided what the needed rules for type compatibility are in C++. In particular how it behaves with overloads, functors, and templates. > compound literals and designated initializers - accept these > constructs as C accepts them, perhaps limited to data types > that are legal in C programs. I'll give you designated initializers. They should be allowed on PODs in C++. I've heard that they've been proposed, but I haven't found the actual proposal. That doesn't bode well for it in the next revision. I think the ship has sailed on compound literals though. It would interfere with the initilizer lists that are already in C++. > 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. A restricted form of VLAs made the draft of C++14, but didn't make the final cut. I'm not sure why. C++ already has std::complex. Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-19 09:21 -0700 |
| Message-ID | <kfnh9scum0o.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60271 |
Martin Shobe <martin.shobe@yahoo.com> writes:
> On 4/17/2015 12:58 PM, Tim Rentsch wrote:
>> Martin Shobe <martin.shobe@yahoo.com> writes:
>>> On 4/15/2015 5:23 PM, Tim Rentsch wrote:
>>>> [snip] Getting back to the topic from upthread, ISTM that
>>>> members of the C++ community often suggest that C should adopt
>>>> certain features of C++, yet there has been rather little
>>>> reciprocation from C++ in terms of adopting C constructs from
>>>> C99. The claim is that almost all C code is legal C++ code.
>>>> However, judging by the actions of the C++ community (about
>>>> which I should say that my experience in this realm is fairly
>>>> limited, but based on that), it seems that they are less
>>>> interested in expanding the common subset than they are in
>>>> following an "embrace, extend, extinguish" type strategy. And
>>>> if they want to prove that hypothesis wrong, that's easy to do:
>>>> simply add those features introduced in C99 to C++.
>>>
>>> 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).
>
> See N4150. Part of the reason that they haven't added it is that
> they haven't decided what the needed rules for type compatibility
> are in C++. In particular how it behaves with overloads, functors,
> and templates.
I looked through this briefly. AFAICT none of the problems
they bring up has any effect on what I'm suggesting, which
is basically to accept the syntax but do nothing with it.
If it were important for what C++ wants to do later, there
could also be no effect on type compatibility. And the list
of compilers that already have some form of restrict as an
extension is pretty comprehensive ("accepted by every major
compiler" is what N4150 says).
>> compound literals and designated initializers - accept these
>> constructs as C accepts them, perhaps limited to data types
>> that are legal in C programs.
>
> I'll give you designated initializers. They should be allowed on
> PODs in C++. I've heard that they've been proposed, but I haven't
> found the actual proposal. That doesn't bode well for it in the
> next revision.
>
> I think the ship has sailed on compound literals though. It would
> interfere with the initilizer lists that are already in C++.
Can you elaborate on that? To me it looks like the two constructs
just don't interact, by virtue of clearcut syntactic distinction.
>> 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.
>
> A restricted form of VLAs made the draft of C++14, but didn't make
> the final cut. I'm not sure why.
That's curious.
> C++ already has std::complex.
Right, but the question is would also having _Complex (as an
optional feature) interfere with that? That should be the
test, and I don't see how it does.
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-04-20 12:51 -0500 |
| Message-ID | <mh3e9c$h1f$1@dont-email.me> |
| In reply to | #60427 |
On 4/19/2015 11:21 AM, Tim Rentsch wrote:
> Martin Shobe <martin.shobe@yahoo.com> writes:
>
>> On 4/17/2015 12:58 PM, Tim Rentsch wrote:
>>> Martin Shobe <martin.shobe@yahoo.com> writes:
>>>> On 4/15/2015 5:23 PM, Tim Rentsch wrote:
>>>>> [snip] Getting back to the topic from upthread, ISTM that
>>>>> members of the C++ community often suggest that C should adopt
>>>>> certain features of C++, yet there has been rather little
>>>>> reciprocation from C++ in terms of adopting C constructs from
>>>>> C99. The claim is that almost all C code is legal C++ code.
>>>>> However, judging by the actions of the C++ community (about
>>>>> which I should say that my experience in this realm is fairly
>>>>> limited, but based on that), it seems that they are less
>>>>> interested in expanding the common subset than they are in
>>>>> following an "embrace, extend, extinguish" type strategy. And
>>>>> if they want to prove that hypothesis wrong, that's easy to do:
>>>>> simply add those features introduced in C99 to C++.
>>>>
>>>> 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).
>>
>> See N4150. Part of the reason that they haven't added it is that
>> they haven't decided what the needed rules for type compatibility
>> are in C++. In particular how it behaves with overloads, functors,
>> and templates.
>
> I looked through this briefly. AFAICT none of the problems
> they bring up has any effect on what I'm suggesting, which
> is basically to accept the syntax but do nothing with it.
> If it were important for what C++ wants to do later, there
> could also be no effect on type compatibility. And the list
> of compilers that already have some form of restrict as an
> extension is pretty comprehensive ("accepted by every major
> compiler" is what N4150 says).
Let's say that the C++ committee does what you propose. They add
restrict and (as far as overloads, functors, and templates are
concerned) it does nothing. People then write code based on the fact
that it does nothing. Meanwhile, the C++ committee decides that it
should do something, possibly to allow for template writers to specify
different algorithms based on whether or not restrict is used. Now
adding that ability to the language is a breaking change.
>>> compound literals and designated initializers - accept these
>>> constructs as C accepts them, perhaps limited to data types
>>> that are legal in C programs.
>> I'll give you designated initializers. They should be allowed on
>> PODs in C++. I've heard that they've been proposed, but I haven't
>> found the actual proposal. That doesn't bode well for it in the
>> next revision.
>> I think the ship has sailed on compound literals though. It would
>> interfere with the initilizer lists that are already in C++.
> Can you elaborate on that? To me it looks like the two constructs
> just don't interact, by virtue of clearcut syntactic distinction.
I had thought there was an interaction between c-style casts and
initializer lists. Some further research indicates I was mistaken.
>> C++ already has std::complex.
> Right, but the question is would also having _Complex (as an
> optional feature) interfere with that? That should be the
> test, and I don't see how it does.
I don't see any technical hurdles that couldn't be overcome, but would
you have float _Complex be the same type as std::complex<float> or would
they be different? There would need to be agreement here and I can see
arguments for either.
Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-22 10:47 -0700 |
| Message-ID | <kfnoamgt5qp.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60544 |
Martin Shobe <martin.shobe@yahoo.com> writes:
> On 4/19/2015 11:21 AM, Tim Rentsch wrote:
>> Martin Shobe <martin.shobe@yahoo.com> writes:
>>
>>> On 4/17/2015 12:58 PM, Tim Rentsch wrote:
>>>> Martin Shobe <martin.shobe@yahoo.com> writes:
>>>>> On 4/15/2015 5:23 PM, Tim Rentsch wrote:
>>>>>> [snip] Getting back to the topic from upthread, ISTM that
>>>>>> members of the C++ community often suggest that C should adopt
>>>>>> certain features of C++, yet there has been rather little
>>>>>> reciprocation from C++ in terms of adopting C constructs from
>>>>>> C99. The claim is that almost all C code is legal C++ code.
>>>>>> However, judging by the actions of the C++ community (about
>>>>>> which I should say that my experience in this realm is fairly
>>>>>> limited, but based on that), it seems that they are less
>>>>>> interested in expanding the common subset than they are in
>>>>>> following an "embrace, extend, extinguish" type strategy. And
>>>>>> if they want to prove that hypothesis wrong, that's easy to do:
>>>>>> simply add those features introduced in C99 to C++.
>>>>>
>>>>> 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).
>>>
>>> See N4150. Part of the reason that they haven't added it is that
>>> they haven't decided what the needed rules for type compatibility
>>> are in C++. In particular how it behaves with overloads,
>>> functors, and templates.
>>
>> I looked through this briefly. AFAICT none of the problems
>> they bring up has any effect on what I'm suggesting, which
>> is basically to accept the syntax but do nothing with it.
>> If it were important for what C++ wants to do later, there
>> could also be no effect on type compatibility. And the list
>> of compilers that already have some form of restrict as an
>> extension is pretty comprehensive ("accepted by every major
>> compiler" is what N4150 says).
>
> Let's say that the C++ committee does what you propose. They
> add restrict and (as far as overloads, functors, and templates
> are concerned) it does nothing. People then write code based
> on the fact that it does nothing. Meanwhile, the C++ committee
> decides that it should do something, possibly to allow for
> template writers to specify different algorithms based on
> whether or not restrict is used. Now adding that ability to
> the language is a breaking change.
Two comments. First, I don't think the scenario you describe
(ie, that code would be written based on 'restrict' doing
nothing) is very plausible. Possible, yes, but not plausible.
Second, if 'restrict' had no effect on type rules, then it
wouldn't be possible to overload (or template select) based
on 'restrict'. AFAICS this removes any incentive to add
'restrict' to any new C++ code.
>>>> compound literals and designated initializers - accept these
>>>> constructs as C accepts them, perhaps limited to data types
>>>> that are legal in C programs.
>>>
>>> I'll give you designated initializers. They should be allowed on
>>> PODs in C++. I've heard that they've been proposed, but I haven't
>>> found the actual proposal. That doesn't bode well for it in the
>>> next revision.
>>>
>>> I think the ship has sailed on compound literals though. It would
>>> interfere with the initilizer lists that are already in C++.
>>
>> Can you elaborate on that? To me it looks like the two constructs
>> just don't interact, by virtue of clearcut syntactic distinction.
>
> I had thought there was an interaction between c-style casts
> and initializer lists. Some further research indicates I was
> mistaken.
Okay, thank you for looking into that.
>>> C++ already has std::complex.
>>
>> Right, but the question is would also having _Complex (as an
>> optional feature) interfere with that? That should be the
>> test, and I don't see how it does.
>
> I don't see any technical hurdles that couldn't be overcome,
> but would you have float _Complex be the same type as
> std::complex<float> or would they be different? There would
> need to be agreement here and I can see arguments for either.
Speaking just for myself, I don't care - either choice is better
than not having _Complex at all. Having said that, my first
reaction is that probably they should be different, and use
implicit conversion to get back and forth; which choice makes
the most sense though probably depends on library issues, which I
am not qualified to address. But either way is fine by me. In
fact, I can make a stronger statement - there could be a rule
that any TU that uses _Complex would be precluded from using
std::complex, and vice versa. As long as I can take a C program,
and compile it using a C++ compiler, I don't care if std::complex
and _Complex can interoperate (within a single TU - presumably
different TU's could use the two independently).
[toc] | [prev] | [next] | [standalone]
| From | Martin Shobe <martin.shobe@yahoo.com> |
|---|---|
| Date | 2015-04-22 17:20 -0500 |
| Message-ID | <mh96pr$d9d$1@dont-email.me> |
| In reply to | #60764 |
On 4/22/2015 12:47 PM, Tim Rentsch wrote:
> Martin Shobe <martin.shobe@yahoo.com> writes:
>
>> On 4/19/2015 11:21 AM, Tim Rentsch wrote:
>>> Martin Shobe <martin.shobe@yahoo.com> writes:
>>>
>>>> On 4/17/2015 12:58 PM, Tim Rentsch wrote:
>>>>> Martin Shobe <martin.shobe@yahoo.com> writes:
>>>>>> On 4/15/2015 5:23 PM, Tim Rentsch wrote:
>>>>>>> [snip] Getting back to the topic from upthread, ISTM that
>>>>>>> members of the C++ community often suggest that C should adopt
>>>>>>> certain features of C++, yet there has been rather little
>>>>>>> reciprocation from C++ in terms of adopting C constructs from
>>>>>>> C99. The claim is that almost all C code is legal C++ code.
>>>>>>> However, judging by the actions of the C++ community (about
>>>>>>> which I should say that my experience in this realm is fairly
>>>>>>> limited, but based on that), it seems that they are less
>>>>>>> interested in expanding the common subset than they are in
>>>>>>> following an "embrace, extend, extinguish" type strategy. And
>>>>>>> if they want to prove that hypothesis wrong, that's easy to do:
>>>>>>> simply add those features introduced in C99 to C++.
>>>>>>
>>>>>> 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).
>>>>
>>>> See N4150. Part of the reason that they haven't added it is that
>>>> they haven't decided what the needed rules for type compatibility
>>>> are in C++. In particular how it behaves with overloads,
>>>> functors, and templates.
>>> I looked through this briefly. AFAICT none of the problems
>>> they bring up has any effect on what I'm suggesting, which
>>> is basically to accept the syntax but do nothing with it.
>>> If it were important for what C++ wants to do later, there
>>> could also be no effect on type compatibility. And the list
>>> of compilers that already have some form of restrict as an
>>> extension is pretty comprehensive ("accepted by every major
>>> compiler" is what N4150 says).
>> Let's say that the C++ committee does what you propose. They
>> add restrict and (as far as overloads, functors, and templates
>> are concerned) it does nothing. People then write code based
>> on the fact that it does nothing. Meanwhile, the C++ committee
>> decides that it should do something, possibly to allow for
>> template writers to specify different algorithms based on
>> whether or not restrict is used. Now adding that ability to
>> the language is a breaking change.
> Two comments. First, I don't think the scenario you describe
> (ie, that code would be written based on 'restrict' doing
> nothing) is very plausible. Possible, yes, but not plausible.
> Second, if 'restrict' had no effect on type rules, then it
> wouldn't be possible to overload (or template select) based
> on 'restrict'. AFAICS this removes any incentive to add
> 'restrict' to any new C++ code.
What about people who start the process of converting C code to C++ and
leave it in an intermediate state? I find that scenario plausible.
[snip]
>>>> C++ already has std::complex.
>>>
>>> Right, but the question is would also having _Complex (as an
>>> optional feature) interfere with that? That should be the
>>> test, and I don't see how it does.
>> I don't see any technical hurdles that couldn't be overcome,
>> but would you have float _Complex be the same type as
>> std::complex<float> or would they be different? There would
>> need to be agreement here and I can see arguments for either.
> Speaking just for myself, I don't care - either choice is better
> than not having _Complex at all. Having said that, my first
> reaction is that probably they should be different, and use
> implicit conversion to get back and forth; which choice makes
> the most sense though probably depends on library issues, which I
> am not qualified to address. But either way is fine by me.
Personally, I wouldn't care either, but whatever they decide to do, the
committee would still have to agree on it.
> In
> fact, I can make a stronger statement - there could be a rule
> that any TU that uses _Complex would be precluded from using
> std::complex, and vice versa. As long as I can take a C program,
> and compile it using a C++ compiler, I don't care if std::complex
> and _Complex can interoperate (within a single TU - presumably
> different TU's could use the two independently).
I would find that annoying.
Martin Shobe
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-24 07:51 -0700 |
| Message-ID | <kfnh9s5r34r.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60813 |
Martin Shobe <martin.shobe@yahoo.com> writes:
> On 4/22/2015 12:47 PM, Tim Rentsch wrote:
>> Martin Shobe <martin.shobe@yahoo.com> writes:
>>
>>> On 4/19/2015 11:21 AM, Tim Rentsch wrote:
>>>> Martin Shobe <martin.shobe@yahoo.com> writes:
>>>>
>>>>> On 4/17/2015 12:58 PM, Tim Rentsch wrote:
>>>>>> Martin Shobe <martin.shobe@yahoo.com> writes:
>>>>>>> On 4/15/2015 5:23 PM, Tim Rentsch wrote:
>>>>>>>> [snip] Getting back to the topic from upthread, ISTM that
>>>>>>>> members of the C++ community often suggest that C should adopt
>>>>>>>> certain features of C++, yet there has been rather little
>>>>>>>> reciprocation from C++ in terms of adopting C constructs from
>>>>>>>> C99. The claim is that almost all C code is legal C++ code.
>>>>>>>> However, judging by the actions of the C++ community (about
>>>>>>>> which I should say that my experience in this realm is fairly
>>>>>>>> limited, but based on that), it seems that they are less
>>>>>>>> interested in expanding the common subset than they are in
>>>>>>>> following an "embrace, extend, extinguish" type strategy. And
>>>>>>>> if they want to prove that hypothesis wrong, that's easy to do:
>>>>>>>> simply add those features introduced in C99 to C++.
>>>>>>>
>>>>>>> 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).
>>>>>
>>>>> See N4150. Part of the reason that they haven't added it is that
>>>>> they haven't decided what the needed rules for type compatibility
>>>>> are in C++. In particular how it behaves with overloads,
>>>>> functors, and templates.
>>>>
>>>> I looked through this briefly. AFAICT none of the problems
>>>> they bring up has any effect on what I'm suggesting, which
>>>> is basically to accept the syntax but do nothing with it.
>>>> If it were important for what C++ wants to do later, there
>>>> could also be no effect on type compatibility. And the list
>>>> of compilers that already have some form of restrict as an
>>>> extension is pretty comprehensive ("accepted by every major
>>>> compiler" is what N4150 says).
>>>
>>> Let's say that the C++ committee does what you propose. They
>>> add restrict and (as far as overloads, functors, and templates
>>> are concerned) it does nothing. People then write code based
>>> on the fact that it does nothing. Meanwhile, the C++ committee
>>> decides that it should do something, possibly to allow for
>>> template writers to specify different algorithms based on
>>> whether or not restrict is used. Now adding that ability to
>>> the language is a breaking change.
>>
>> Two comments. First, I don't think the scenario you describe
>> (ie, that code would be written based on 'restrict' doing
>> nothing) is very plausible. Possible, yes, but not plausible.
>> Second, if 'restrict' had no effect on type rules, then it
>> wouldn't be possible to overload (or template select) based
>> on 'restrict'. AFAICS this removes any incentive to add
>> 'restrict' to any new C++ code.
>
> What about people who start the process
> of converting C code to C++ and leave it
> in an intermediate state? I find that
> scenario plausible.
I agree, it is plausible, but here I don't think the problem is
serious, because of what 'restrict' (in C) does. In particular,
there is no expectation that adding 'restrict' (in C code) _has_
to do anything. So if it were necessary to adjust the code in
question when C++ introduces its own semantics for 'restrict', at
that point we could just take out all the 'restrict' qualifiers,
and that is that. This is assuming of course that it would even
be necessary to take them out, which I believe is unlikely - if
C++ does introduce its own version of restrict at some point,
based on what is said in N4150 the semantics of 'restrict' in C++
will very likely be compatible with 'restrict' in C for almost
all of the uses of 'restrict' in C programs.
>>>>> C++ already has std::complex.
>>>>
>>>> Right, but the question is would also having _Complex (as an
>>>> optional feature) interfere with that? That should be the
>>>> test, and I don't see how it does.
>>>
>>> I don't see any technical hurdles that couldn't be overcome,
>>> but would you have float _Complex be the same type as
>>> std::complex<float> or would they be different? There would
>>> need to be agreement here and I can see arguments for either.
>>
>> Speaking just for myself, I don't care - either choice is better
>> than not having _Complex at all. Having said that, my first
>> reaction is that probably they should be different, and use
>> implicit conversion to get back and forth; which choice makes
>> the most sense though probably depends on library issues, which I
>> am not qualified to address. But either way is fine by me.
>
> Personally, I wouldn't care either, but
> whatever they decide to do, the
> committee would still have to agree on
> it.
My point, indirectly, is that it should be easy to reach
agreement because there is not much force in either direction
(ie, as far as C compatibility goes).
Looking into this a little further, I see that gcc supports both
types internally (ie, as distinct types). That provides an
existence proof that keeping the types distinct can be done, and
gives some weight to the proposition that this is what should be
done. So I'm inclined to think that reaching consensus on the
issue probably won't present any significant difficulties. Do
you disagree?
>> In
>> fact, I can make a stronger statement - there could be a rule
>> that any TU that uses _Complex would be precluded from using
>> std::complex, and vice versa. As long as I can take a C program,
>> and compile it using a C++ compiler, I don't care if std::complex
>> and _Complex can interoperate (within a single TU - presumably
>> different TU's could use the two independently).
>
> I would find that annoying.
In the long term I expect I would also. I'm willing to accept it
in the short term if that helps the process converge more
quickly. (And I should add, now that I've looked a bit at what
gcc does currently, I don't think there is any reason to want to
go down this path, so the question is pretty much moot.)
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-04-17 23:10 +0000 |
| Message-ID | <slrnmj34mq.2ot.grahn+nntp@frailea.sa.invalid> |
| In reply to | #60106 |
On Wed, 2015-04-15, Tim Rentsch wrote: ... > Getting back to the topic from upthread, ISTM that members of the > C++ community often suggest that C should adopt certain features > of C++, yet there has been rather little reciprocation from C++ in > terms of adopting C constructs from C99. To be blunt, most of us would rather pretend C didn't exist. We're not interested in changing it. I'm a member of that community, but I can't think of a single thing from C++ that I'd like to add to C. What would be the point? At work I'm even /less/ likely to be allowed to use a future C dialect, than C++. I mean, I had to fight to be allowed to use C99 -- and that was standardized fifteen years ago. C /did/ get some things from C++, but that was a long time ago ... when C could still be improved without turning it into a crippled C++ dialect. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-04-19 14:46 +0000 |
| Message-ID | <5533bf41.20937656@news.xs4all.nl> |
| In reply to | #60275 |
Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: > On Wed, 2015-04-15, Tim Rentsch wrote: > ... > > Getting back to the topic from upthread, ISTM that members of the > > C++ community often suggest that C should adopt certain features > > of C++, yet there has been rather little reciprocation from C++ in > > terms of adopting C constructs from C99. > > To be blunt, most of us would rather pretend C didn't exist. We're not > interested in changing it. Well, then, to be equally blunt: fuck off. Don't bugger up C as badly as Byarney buggered up C--. You're a Java-wannabe already; just be done with it and become Java-- and stop pretending to be a "better C". Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-19 08:56 -0700 |
| Message-ID | <kfnlhhoun72.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60275 |
Jorgen Grahn <grahn+nntp@snipabacken.se> writes: > On Wed, 2015-04-15, Tim Rentsch wrote: > ... >> Getting back to the topic from upthread, ISTM that members of the >> C++ community often suggest that C should adopt certain features >> of C++, yet there has been rather little reciprocation from C++ >> in terms of adopting C constructs from C99. > > To be blunt, most of us would rather pretend C didn't exist. > We're not interested in changing it. > > I'm a member of that community, but I can't think of a single > thing from C++ that I'd like to add to C. What would be the > point? At work I'm even /less/ likely to be allowed to use a > future C dialect, than C++. I mean, I had to fight to be allowed > to use C99 -- and that was standardized fifteen years ago. > > C /did/ get some things from C++, but that was a long time ago ... > when C could still be improved without turning it into a crippled > C++ dialect. Well, this kind of supports my thesis, doesn't it? The official policy (or maybe I should say "official" policy, since it's unclear if it came from any authorized person) is features from C will be included in C++ if they don't interfere with where C++ is going. Unofficially though, there is little or no interest in maintaining a reasonable degree of compatibility. My complaint is that (some of) the same people give both stories - the most C code is also C++ code, but at the same time they aren't going to add some notable C features that C++ is lacking. Either one by itself is fine; but asserting both seems a little bit dishonest.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-31 16:33 +1300 |
| Message-ID | <cnuit6Fm7ngU1@mid.individual.net> |
| In reply to | #59301 |
Tim Rentsch wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> Tim Rentsch wrote: >>> Ian Collins <ian-news@hotmail.com> writes: >>> >>>> Tim Rentsch wrote: >>>> >>>>> By the way, I'll give you another item for your list, which is >>>>> compound literals. I find compound literals extremely useful, >>>>> and would not want to give them up. (Disclaimer: I believe that >>>>> C++ does not support compound literals, but I haven't really >>>>> followed what's going on with C++ features, especially lately.) >>>> >>>> C++ does not support compound literals, but in most use cases >>>> initialiser lists fulfill the same role. [snip elaboration] >>> >>> This assertion is not even remotely right. Of course you can >>> use an initializer list when you have a declared identifier >>> to initialize. The whole point of compound literals is not >>> to have to need such a declared identifier, and that's when >>> compound literals are used. >> >> I'm either being dense, or we are completely misunderstanding each >> other. Are you referring to a case like [snip example of how to >> re-write a C fragment in C++]: > > I guess you weren't completely paying attention earlier. What > was being discussed is what parts of C are (or are not) legal > C++, not how to re-write C code in C++. The claim is that almost > all C (programs or lines of code, it was ambiguous which) is also > legal C++. Compound literals is a counter-example to that. Use > cases in C++ are irrelevant to the question; it is use cases in > C that matter. Hang on, I was paying attention. You wrote "I find compound literals extremely useful, and would not want to give them up" and I made an apparently misguided attempt to show you how initialiser lists fulfill much the same role. Do you disagree that the last example I posted and you snipped does this? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-15 22:56 -0700 |
| Message-ID | <kfnd2341uqp.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #59322 |
Ian Collins <ian-news@hotmail.com> writes: > Tim Rentsch wrote: >> Ian Collins <ian-news@hotmail.com> writes: >> >>> Tim Rentsch wrote: >>>> Ian Collins <ian-news@hotmail.com> writes: >>>> >>>>> Tim Rentsch wrote: >>>>> >>>>>> By the way, I'll give you another item for your list, which is >>>>>> compound literals. I find compound literals extremely useful, >>>>>> and would not want to give them up. (Disclaimer: I believe >>>>>> that C++ does not support compound literals, but I haven't >>>>>> really followed what's going on with C++ features, especially >>>>>> lately.) >>>>> >>>>> C++ does not support compound literals, but in most use cases >>>>> initialiser lists fulfill the same role. [snip elaboration] >>>> >>>> This assertion is not even remotely right. Of course you can >>>> use an initializer list when you have a declared identifier >>>> to initialize. The whole point of compound literals is not >>>> to have to need such a declared identifier, and that's when >>>> compound literals are used. >>> >>> I'm either being dense, or we are completely misunderstanding >>> each other. Are you referring to a case like [snip example of >>> how to re-write a C fragment in C++]: >> >> I guess you weren't completely paying attention earlier. What >> was being discussed is what parts of C are (or are not) legal >> C++, not how to re-write C code in C++. The claim is that almost >> all C (programs or lines of code, it was ambiguous which) is also >> legal C++. Compound literals is a counter-example to that. Use >> cases in C++ are irrelevant to the question; it is use cases in >> C that matter. > > Hang on, I was paying attention. You wrote "I find compound > literals extremely useful, and would not want to give them up" and > I made an apparently misguided attempt to show you how initialiser > lists fulfill much the same role. Do you disagree that the last > example I posted and you snipped does this? There are two distinct points of confusion here, let me try to separate them. The subject that was previously under discussion is whether almost all C code is also legal C++ code. Compound literals aren't. It's possible to code around that limitation, and not use compound literals. The example you gave seems like it is on a slightly different subject, which is how to write C code in the common subset of C and C++. If I write in that common subset, then I have to give up compound literals. It is this point that I was primarily addressing in my last response and first response in the quoted stuff above. The second item is about how such workarounds might be done and to what extent they meet the needs of using compound literls. You gave an example (which I slightly mislabeled in my []'ed summary - that should be "snip example of how to re-write a C fragment in C/C++ common subset", which is more like what I actually meant) showing how to do that. I agree that your example shows a reasonable way of writing the example line so as not to use a compound literal. The problem is, the example line is not representative of how compound literals are typically used. Usually compound literals are used as subexpressions of a larger expression, not as the (whole) initializer portion of a declared variable. To use the technique illustrated in your example, in most cases it would be necessary to introduce a declaration so that there could be an initializer list to give the initial value. The point of using a compound literal, and indeed why they were added to the language in the first place, is so we don't have to add a declaration just to supply a compound value. It is this point that I was addressing in my middle response of the quoted stuff above. To restate briefly: I agree your example shows a way to use an initializer list (rather than a compound literal) for the one case, but that case is not at all typical of where/how compound literals are commonly used, which do not map conveniently onto an initializer list formulation. Does this clarify my earlier comments sufficiently?
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-04-16 20:06 +1200 |
| Message-ID | <cp98t0Ffnp3U2@mid.individual.net> |
| In reply to | #60112 |
Tim Rentsch wrote: > > To restate briefly: I agree your example shows a way to use > an initializer list (rather than a compound literal) for the > one case, but that case is not at all typical of where/how > compound literals are commonly used, which do not map > conveniently onto an initializer list formulation. > > Does this clarify my earlier comments sufficiently? Yes it does. What would have helped the discussion would have bee some examples of what you consider common uses of compound literals. I'm guessing your typical uses differ from mine... -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-04-17 08:44 -0700 |
| Message-ID | <kfn8udqyd1p.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #60118 |
Ian Collins <ian-news@hotmail.com> writes: > Tim Rentsch wrote: > >> To restate briefly: I agree your example shows a way to use >> an initializer list (rather than a compound literal) for the >> one case, but that case is not at all typical of where/how >> compound literals are commonly used, which do not map >> conveniently onto an initializer list formulation. >> >> Does this clarify my earlier comments sufficiently? > > Yes it does. What would have helped the discussion would have bee > some examples of what you consider common uses of compound > literals. I'm guessing your typical uses differ from mine... (reply combined with response to second message.)
[toc] | [prev] | [next] | [standalone]
Page 6 of 14 — ← Prev page 1 … 4 5 [6] 7 8 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web