Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #130416 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2018-05-11 10:13 -0700 |
| Last post | 2018-05-11 16:56 -0700 |
| Articles | 20 on this page of 237 — 20 participants |
Back to article view | Back to comp.lang.c
C++ features for C Thiago Adams <thiago.adams@gmail.com> - 2018-05-11 10:13 -0700
Re: C++ features for C supercat@casperkitty.com - 2018-05-11 10:47 -0700
Re: C++ features for C Thiago Adams <thiago.adams@gmail.com> - 2018-05-11 11:06 -0700
Re: C++ features for C Philipp Klaus Krause <pkk@spth.de> - 2018-05-11 21:52 +0200
Re: C++ features for C Thiago Adams <thiago.adams@gmail.com> - 2018-05-11 16:51 -0700
Re: C++ features for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-05-11 21:35 +0100
Re: C++ features for C Steve Carroll <frelwizzen@gmail.com> - 2018-05-11 23:39 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-11 19:20 +0100
Re: C++ features for C supercat@casperkitty.com - 2018-05-11 12:21 -0700
Re: C++ features for C Richard Damon <Richard@Damon-Family.org> - 2018-05-12 11:09 -0400
Re: C++ features for C Tim Rentsch <txr@alumni.caltech.edu> - 2018-05-18 20:48 -0700
Re: C++ features for C supercat@casperkitty.com - 2018-05-19 12:59 -0700
Re: C++ features for C Ike Naar <ike@iceland.freeshell.org> - 2018-05-22 06:50 +0000
Re: C++ features for C supercat@casperkitty.com - 2018-05-22 07:39 -0700
Re: C++ features for C Steve Carroll <frelwizzen@gmail.com> - 2018-05-22 09:54 -0700
Re: C++ features for C Richard Damon <Richard@Damon-Family.org> - 2018-05-19 16:18 -0400
Re: C++ features for C supercat@casperkitty.com - 2018-05-19 13:54 -0700
Re: C++ features for C Richard Damon <Richard@Damon-Family.org> - 2018-05-19 18:05 -0400
Re: C++ features for C Tim Rentsch <txr@alumni.caltech.edu> - 2018-06-14 04:27 -0700
Re: C++ features for C supercat@casperkitty.com - 2018-06-14 07:35 -0700
Re: C++ features for C Richard Damon <Richard@Damon-Family.org> - 2018-06-15 10:25 -0400
Re: C++ features for C Tim Rentsch <txr@alumni.caltech.edu> - 2018-06-17 12:59 -0700
Re: C++ features for C supercat@casperkitty.com - 2018-06-17 23:44 -0700
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-12 12:48 -0700
Re: C++ features for C supercat@casperkitty.com - 2018-05-12 13:07 -0700
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-12 13:59 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-11 18:50 +0100
Re: C++ features for C Thiago Adams <thiago.adams@gmail.com> - 2018-05-11 11:22 -0700
Re: C++ features for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-05-18 02:45 -0700
Re: C++ features for C Thiago Adams <thiago.adams@gmail.com> - 2018-05-11 11:28 -0700
Re: C++ features for C Philipp Klaus Krause <pkk@spth.de> - 2018-05-11 21:49 +0200
Re: C++ features for C Thiago Adams <thiago.adams@gmail.com> - 2018-05-11 16:44 -0700
Terse static_assert (was Re: C++ features for C) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-05-12 05:51 +0000
Re: Terse static_assert (was Re: C++ features for C) Tim Rentsch <txr@alumni.caltech.edu> - 2018-05-18 22:20 -0700
Re: Terse static_assert (was Re: C++ features for C) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-05-22 05:24 +0000
Re: Terse static_assert (was Re: C++ features for C) Steve Carroll <frelwizzen@gmail.com> - 2018-05-22 00:47 -0700
Re: Terse static_assert (was Re: C++ features for C) Tim Rentsch <txr@alumni.caltech.edu> - 2018-06-14 03:22 -0700
Re: C++ features for C Ian Collins <ian-news@hotmail.com> - 2018-05-12 07:59 +1200
Re: C++ features for C Thiago Adams <thiago.adams@gmail.com> - 2018-05-11 13:28 -0700
Re: C++ features for C Ian Collins <ian-news@hotmail.com> - 2018-05-12 10:13 +1200
Re: C++ features for C supercat@casperkitty.com - 2018-05-11 15:36 -0700
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-11 15:38 -0700
Re: C++ features for C Thiago Adams <thiago.adams@gmail.com> - 2018-05-11 16:41 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-12 11:53 +0100
Re: C++ features for C Philipp Klaus Krause <pkk@spth.de> - 2018-05-12 13:30 +0200
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-12 13:48 +0100
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-12 12:17 -0700
Re: C++ features for C Philipp Klaus Krause <pkk@spth.de> - 2018-05-13 09:44 +0200
Re: C++ features for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-05-12 14:46 +0100
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-12 17:23 +0100
Re: C++ features for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-05-12 19:46 +0100
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-12 21:05 +0100
Re: C++ features for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-05-13 02:16 +0100
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-13 12:06 +0100
Re: C++ features for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-05-13 14:20 +0100
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-13 16:19 +0100
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-13 21:00 +0200
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-13 20:30 +0100
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-14 09:49 +0200
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-14 11:56 +0100
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-14 13:15 +0200
Re: C++ features for C supercat@casperkitty.com - 2018-05-14 09:28 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-14 17:44 +0100
Re: C++ features for C supercat@casperkitty.com - 2018-05-14 10:13 -0700
Re: C++ features for C scott@slp53.sl.home (Scott Lurndal) - 2018-05-14 17:46 +0000
Re: C++ features for C scott@slp53.sl.home (Scott Lurndal) - 2018-05-14 17:13 +0000
Re: C++ features for C supercat@casperkitty.com - 2018-05-14 11:23 -0700
Re: C++ features for C Steve Carroll <frelwizzen@gmail.com> - 2018-05-14 14:06 -0700
Re: C++ features for C supercat@casperkitty.com - 2018-05-13 12:40 -0700
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-14 09:11 +0200
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-12 18:03 +0200
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-12 17:45 +0100
Re: C++ features for C Ike Naar <ike@iceland.freeshell.org> - 2018-05-12 18:00 +0000
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-12 20:31 +0100
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-13 16:57 +0200
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-13 17:14 +0100
Re: C++ features for C supercat@casperkitty.com - 2018-05-13 11:38 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-13 19:52 +0100
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-13 21:18 +0200
Re: C++ features for C Steve Carroll <frelwizzen@gmail.com> - 2018-05-13 12:35 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-13 21:22 +0100
Re: C++ features for C mark.bluemel@gmail.com - 2018-05-14 00:49 -0700
Re: C++ features for C Steve Carroll <frelwizzen@gmail.com> - 2018-05-14 01:05 -0700
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-14 10:14 +0200
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-14 11:43 +0100
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-14 12:05 +0100
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-14 09:19 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-14 17:29 +0100
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-14 13:24 +0200
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-14 14:07 +0100
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-14 16:19 +0200
Re: C++ features for C mark.bluemel@gmail.com - 2018-05-14 07:49 -0700
Re: C++ features for C Steve Carroll <frelwizzen@gmail.com> - 2018-05-14 08:07 -0700
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-13 13:20 -0700
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-14 10:47 +0200
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-14 10:35 -0700
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-15 09:10 +0200
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-15 08:53 -0700
Re: C++ features for C Ian Collins <ian-news@hotmail.com> - 2018-05-13 08:19 +1200
Re: C++ features for C scott@slp53.sl.home (Scott Lurndal) - 2018-05-13 17:44 +0000
Re: C++ features for C supercat@casperkitty.com - 2018-05-12 13:33 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-13 22:56 +0100
Re: C++ features for C supercat@casperkitty.com - 2018-05-13 15:18 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-13 23:41 +0100
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-14 12:05 +0200
Re: C++ features for C Steve Carroll <frelwizzen@gmail.com> - 2018-05-14 04:30 -0700
Re: C++ features for C supercat@casperkitty.com - 2018-05-14 08:31 -0700
Re: C++ features for C Steve Carroll <frelwizzen@gmail.com> - 2018-05-14 08:39 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-14 17:21 +0100
Re: C++ features for C supercat@casperkitty.com - 2018-05-14 09:33 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-14 17:55 +0100
Re: C++ features for C supercat@casperkitty.com - 2018-05-14 11:26 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-14 20:24 +0100
Re: C++ features for C Thiago Adams <thiago.adams@gmail.com> - 2018-05-14 13:07 -0700
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-13 15:28 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-13 23:43 +0100
Re: C++ features for C mark.bluemel@gmail.com - 2018-05-14 00:50 -0700
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-14 12:37 +0200
Re: C++ features for C Ian Collins <ian-news@hotmail.com> - 2018-05-13 08:32 +1200
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-12 22:48 +0100
Re: C++ features for C Ian Collins <ian-news@hotmail.com> - 2018-05-13 10:08 +1200
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-13 00:00 +0100
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-13 00:35 +0100
Re: C++ features for C Ian Collins <ian-news@hotmail.com> - 2018-05-13 12:24 +1200
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-13 01:37 +0100
Re: C++ features for C Ian Collins <ian-news@hotmail.com> - 2018-05-13 13:30 +1200
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-13 17:57 +0200
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-13 17:31 +0100
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-13 21:34 +0200
Re: C++ features for C supercat@casperkitty.com - 2018-05-13 11:11 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-13 19:41 +0100
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-13 21:42 +0200
Re: C++ features for C supercat@casperkitty.com - 2018-05-13 13:09 -0700
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-14 12:41 +0200
Re: C++ features for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-05-14 14:25 +0100
Re: C++ features for C supercat@casperkitty.com - 2018-05-12 15:36 -0700
Re: C++ features for C Steve Carroll <frelwizzen@gmail.com> - 2018-05-13 12:05 -0700
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-12 15:53 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-13 00:14 +0100
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-12 18:05 -0700
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-13 21:59 +0200
Re: C++ features for C supercat@casperkitty.com - 2018-05-13 13:23 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-13 22:05 +0100
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-14 12:55 +0200
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-14 12:57 +0200
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-14 10:57 -0700
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-15 09:14 +0200
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-13 14:10 -0700
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-13 17:31 +0200
Re: C++ features for C Thiago Adams <thiago.adams@gmail.com> - 2018-05-14 10:19 -0700
Re: C++ features for C Ian Collins <ian-news@hotmail.com> - 2018-05-15 08:06 +1200
Re: C++ features for C Thiago Adams <thiago.adams@gmail.com> - 2018-05-14 13:20 -0700
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-14 13:46 -0700
Re: C++ features for C Thiago Adams <thiago.adams@gmail.com> - 2018-05-14 14:12 -0700
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-14 14:27 -0700
Re: C++ features for C supercat@casperkitty.com - 2018-05-14 15:21 -0700
Re: C++ features for C Steve Carroll <frelwizzen@gmail.com> - 2018-05-14 15:24 -0700
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-15 09:26 +0200
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-15 11:28 +0100
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-15 13:18 +0200
Re: C++ features for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-05-15 12:23 +0100
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-15 13:27 +0100
Re: C++ features for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-05-15 16:19 +0100
Re: C++ features for C Steve Carroll <frelwizzen@gmail.com> - 2018-05-15 08:29 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-15 17:18 +0100
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-15 10:23 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-15 19:23 +0100
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-15 11:59 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-15 20:20 +0100
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-15 12:56 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-15 21:01 +0100
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-15 13:15 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-15 22:36 +0100
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-15 14:59 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-15 23:54 +0100
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-15 16:18 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-16 00:40 +0100
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-15 17:25 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-16 01:32 +0100
Re: C++ features for C scott@slp53.sl.home (Scott Lurndal) - 2018-05-16 14:32 +0000
Re: C++ features for C Steve Carroll <frelwizzen@gmail.com> - 2018-05-16 07:41 -0700
Re: C++ features for C Steve Carroll <frelwizzen@gmail.com> - 2018-05-15 21:13 -0700
Re: C++ features for C supercat@casperkitty.com - 2018-05-16 07:51 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-16 18:09 +0100
Re: C++ features for C supercat@casperkitty.com - 2018-05-16 13:22 -0700
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-16 09:15 +0200
Re: C++ features for C Steve Carroll <frelwizzen@gmail.com> - 2018-05-16 00:39 -0700
Re: C++ features for C supercat@casperkitty.com - 2018-05-16 08:31 -0700
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-17 15:00 +0200
Re: C++ features for C supercat@casperkitty.com - 2018-05-17 08:07 -0700
Re: C++ features for C Steve Carroll <frelwizzen@gmail.com> - 2018-05-18 05:04 -0700
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-17 09:07 -0700
Re: C++ features for C supercat@casperkitty.com - 2018-05-17 10:33 -0700
Re: C++ features for C scott@slp53.sl.home (Scott Lurndal) - 2018-05-17 18:04 +0000
Re: C++ features for C supercat@casperkitty.com - 2018-05-17 13:15 -0700
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-17 14:07 -0700
Re: C++ features for C supercat@casperkitty.com - 2018-05-17 15:40 -0700
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-17 16:28 -0700
Re: C++ features for C supercat@casperkitty.com - 2018-05-18 09:17 -0700
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-18 10:36 -0700
Re: C++ features for C supercat@casperkitty.com - 2018-05-18 11:41 -0700
Re: C++ features for C Steve Carroll <frelwizzen@gmail.com> - 2018-05-19 14:16 -0700
Re: C++ features for C Richard Damon <Richard@Damon-Family.org> - 2018-05-18 19:54 -0400
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-17 20:39 +0200
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-17 12:37 -0700
Re: C++ features for C Ike Naar <ike@iceland.freeshell.org> - 2018-05-17 19:54 +0000
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-17 13:39 -0700
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-17 22:48 +0200
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-17 22:47 +0200
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-17 14:13 -0700
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-18 10:10 +0200
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-18 17:55 +0200
Re: C++ features for C Steve Carroll <frelwizzen@gmail.com> - 2018-05-18 08:59 -0700
Re: C++ features for C supercat@casperkitty.com - 2018-05-18 10:17 -0700
Re: C++ features for C "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-05-15 15:56 -0700
Re: C++ features for C "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-05-15 15:59 -0700
Re: C++ features for C supercat@casperkitty.com - 2018-05-15 15:15 -0700
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-15 15:58 -0700
Re: C++ features for C Steve Carroll <frelwizzen@gmail.com> - 2018-05-15 16:48 -0700
Re: C++ features for C gazelle@shell.xmission.com (Kenny McCormack) - 2018-05-15 20:37 +0000
Re: C++ features for C supercat@casperkitty.com - 2018-05-15 13:46 -0700
Re: C++ features for C Steve Carroll <frelwizzen@gmail.com> - 2018-05-15 14:43 -0700
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-15 09:17 -0700
Re: C++ features for C bartc <bc@freeuk.com> - 2018-05-15 18:20 +0100
Re: C++ features for C scott@slp53.sl.home (Scott Lurndal) - 2018-05-15 17:38 +0000
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-15 11:13 -0700
Re: C++ features for C Steve Carroll <frelwizzen@gmail.com> - 2018-05-15 06:40 -0700
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-15 09:12 -0700
Re: C++ features for C Steve Carroll <frelwizzen@gmail.com> - 2018-05-15 03:33 -0700
Re: C++ features for C Keith Thompson <kst-u@mib.org> - 2018-05-15 09:09 -0700
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-15 23:45 +0200
Re: C++ features for C Ike Naar <ike@iceland.freeshell.org> - 2018-05-17 18:49 +0000
Re: C++ features for C David Brown <david.brown@hesbynett.no> - 2018-05-17 22:49 +0200
Re: C++ features for C Chad <cdalten@gmail.com> - 2018-05-11 15:46 -0700
Re: C++ features for C supercat@casperkitty.com - 2018-05-11 16:13 -0700
Re: C++ features for C Andrey Tarasevich <andreytarasevich@hotmail.com> - 2018-05-11 16:52 -0700
Re: C++ features for C Thiago Adams <thiago.adams@gmail.com> - 2018-05-11 16:56 -0700
Page 7 of 12 — ← Prev page 1 … 5 6 [7] 8 9 … 12 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-05-13 10:08 +1200 |
| Message-ID | <flp6vrFua2iU5@mid.individual.net> |
| In reply to | #130474 |
On 05/13/2018 09:48 AM, bartc wrote:
> On 12/05/2018 21:32, Ian Collins wrote:
>> On 05/12/2018 11:41 AM, Thiago Adams wrote:
>>>
>>> The feature to define PI should not define a variable, but
>>> a named literal or compound literal.
>>> I cannot take the address of &3.14 why I would like to
>>> take the address of pi?
>>
>>
>> constexpr double pi = 3.14159265358979323846264338327950288419716939937511;
>> constexpr double e = 2.71828182845904523536028747135266249775724709369995;
>> constexpr double constants[] = {pi,e};
>>
>> void f( const double* values, size_t count )
>> {
>> for( size_t n = 0; n < count; ++n )
>> {
>> printf( "%f\n", values[n] );
>> }
>> }
>>
>> int main()
>> {
>> f( constants, 2 );
>> f( &pi, 1 );
>> }
>
> > People do "get it", they just don't see the need for it.
>
> I doubt it. I want a named literal that can be used in exactly the same
> as a raw literal. And that includes not being able to apply & to it.
>
> (And in your example, I was able to write a function to change the value
> of pi, but it only failed at runtime because pi must have been stored in
> read-only memory.)
If you do stupid things, shit happens.
The question I was answering was "I cannot take the address of &3.14 why
I would like to take the address of pi?". The code demonstrated a
simple use case for the address of pi. It had nothing to do with the
bit of my reply another of your posts you inserted above.
If I wanted the values to be completely immutable and pi not to have an
address, I would have written:
struct X
{
static constexpr double pi =
3.14159265358979323846264338327950288419716939937511;
static constexpr double e =
2.71828182845904523536028747135266249775724709369995;
static constexpr double constants[] = {pi,e};
};
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-13 00:00 +0100 |
| Message-ID | <AmKJC.125921$Hc3.56469@fx30.am4> |
| In reply to | #130475 |
On 12/05/2018 23:08, Ian Collins wrote:
> On 05/13/2018 09:48 AM, bartc wrote:
> If you do stupid things, shit happens.
The problem is other people being able to do it.
> If I wanted the values to be completely immutable and pi not to have an
> address, I would have written:
>
> struct X
> {
> static constexpr double pi =
> 3.14159265358979323846264338327950288419716939937511;
> static constexpr double e =
> 2.71828182845904523536028747135266249775724709369995;
> static constexpr double constants[] = {pi,e};
> };
Is that all? And I merely have to refer to X::pi?
However, it appears that with visual studio, pi /does/ have an address:
int main()
{
std::cout << X::pi << std::endl;
std::cout << &X::pi << std::endl;
}
Output:
3.14159
00007FF797342220
Furthermore, writing:
*(double*)(&X::pi) = 1.0;
let's me easily by-pass the language protection. (But not the memory
protection in this implementation. However why should I need to rely on
that for something that should not be accessible by address anyway?)
Guys, this is how it's done (not C or C++):
const e = 2.17181728
print &e # ERROR (ref on constant)
e := 3.14159 # ERROR
[e]int a # converts e to int value
print a.len # displays 2 (not a VLA)
switch x
when e then # compares against 2 (switch uses int)
...
(I can't use pi for my example as it is already a built-in constant.)
It ticks ALL the boxes, and is very simple to implement.
I think I was right about people here simply not getting it. Why have
one simple feature when half-a-dozen different and more complex ways of
badly doing the same thing can be used instead?
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-13 00:35 +0100 |
| Message-ID | <GSKJC.168950$Z64.111419@fx36.am4> |
| In reply to | #130478 |
On 13/05/2018 00:00, bartc wrote:
> Furthermore, writing:
>
> *(double*)(&X::pi) = 1.0;
>
> let's me easily by-pass the language protection. (But not the memory
> protection in this implementation. However why should I need to rely on
> that for something that should not be accessible by address anyway?)
If I do the equivalent in C (using static const double), then I can
change pi to 1.0 with 3 of my 7 C compilers.
Avoiding being able to redefine pi becomes a QoI issue rather than a
language one as I think it should be and as it can be using the right
feature.
(Mind you, Python isn't that brilliant at this either:
import math
math.pi = "Hmm, pie!"
print (math.pi)
)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-05-13 12:24 +1200 |
| Message-ID | <flpet7Fua2iU6@mid.individual.net> |
| In reply to | #130478 |
On 05/13/2018 11:00 AM, bartc wrote:
> On 12/05/2018 23:08, Ian Collins wrote:
>> On 05/13/2018 09:48 AM, bartc wrote:
>
> > If you do stupid things, shit happens.
>
> The problem is other people being able to do it.
>
>> If I wanted the values to be completely immutable and pi not to have an
>> address, I would have written:
>>
>> struct X
>> {
>> static constexpr double pi =
>> 3.14159265358979323846264338327950288419716939937511;
>> static constexpr double e =
>> 2.71828182845904523536028747135266249775724709369995;
>> static constexpr double constants[] = {pi,e};
>> };
>
> Is that all? And I merely have to refer to X::pi?
>
> However, it appears that with visual studio, pi /does/ have an address:
That is non-standard behaviour, probably because the compiler has always
had the behaviour and they don't want to change it....
> Guys, this is how it's done (not C or C++):
>
> const e = 2.17181728
>
> print &e # ERROR (ref on constant)
> e := 3.14159 # ERROR
>
> [e]int a # converts e to int value
> print a.len # displays 2 (not a VLA)
>
> switch x
> when e then # compares against 2 (switch uses int)
> ...
>
> (I can't use pi for my example as it is already a built-in constant.)
>
> It ticks ALL the boxes, and is very simple to implement.
Maybe, but how do you pass e to a function with a pointer to whatever it
is parameter? In my original example, passing it to f()?
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-13 01:37 +0100 |
| Message-ID | <rNLJC.228323$Xa4.95986@fx29.am4> |
| In reply to | #130481 |
On 13/05/2018 01:24, Ian Collins wrote: > On 05/13/2018 11:00 AM, bartc wrote: >> const e = 2.17181728 (This is a somewhat non-standard value of e ...) >> It ticks ALL the boxes, and is very simple to implement. > > Maybe, but how do you pass e to a function with a pointer to whatever it > is parameter? In my original example, passing it to f()? You can't do that for the same reason you can't pass actual literals like 129 or 8.21 to such functions. But there is no outcry about that. If that was a real requirement, a copy of the constant would need to be stored in a regular variable for which & is well-defined (and where the function cannot modify the original): static const double picopy = pi; f(&picopy, 1); -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-05-13 13:30 +1200 |
| Message-ID | <flpiq2Fua2iU7@mid.individual.net> |
| In reply to | #130482 |
On 05/13/2018 12:37 PM, bartc wrote: > On 13/05/2018 01:24, Ian Collins wrote: >> On 05/13/2018 11:00 AM, bartc wrote: So, does the C++ example yo conveniently snipped and for integer types in C and C++, an enumeration, meet your definition of a constant? -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-13 17:57 +0200 |
| Message-ID | <pd9n90$jsk$1@dont-email.me> |
| In reply to | #130478 |
On 13/05/18 01:00, bartc wrote:
> On 12/05/2018 23:08, Ian Collins wrote:
>> On 05/13/2018 09:48 AM, bartc wrote:
>
> > If you do stupid things, shit happens.
>
> The problem is other people being able to do it.
>
>> If I wanted the values to be completely immutable and pi not to have
>> an address, I would have written:
>>
>> struct X
>> {
>> static constexpr double pi =
>> 3.14159265358979323846264338327950288419716939937511;
>> static constexpr double e =
>> 2.71828182845904523536028747135266249775724709369995;
>> static constexpr double constants[] = {pi,e};
>> };
>
> Is that all? And I merely have to refer to X::pi?
>
> However, it appears that with visual studio, pi /does/ have an address:
>
> int main()
> {
> std::cout << X::pi << std::endl;
> std::cout << &X::pi << std::endl;
> }
>
> Output:
>
> 3.14159
> 00007FF797342220
>
> Furthermore, writing:
>
> *(double*)(&X::pi) = 1.0;
>
> let's me easily by-pass the language protection. (But not the memory
> protection in this implementation. However why should I need to rely on
> that for something that should not be accessible by address anyway?)
>
> Guys, this is how it's done (not C or C++):
In C or C++:
>
> const e = 2.17181728
constexpr double e = 2.17181728; // C++
static const double e = 2.17181728; // C or C++
Winner - C and C++, as they are typed.
>
> print &e # ERROR (ref on constant)
printf("%p", (void*) &e);
Winner - C and C++ let you take the address if you want to, but don't
require the creation of an object unless needed.
> e := 3.14159 # ERROR
e = 3.14159; // Error - can't assign to a const object
Winner - draw.
>
> [e]int a # converts e to int value
int a[(int) e];
Winner - C and C++, for having a clearer syntax and for /requiring/ the
size of the array to be an integer type instead of converting it on the
fly. (In C, "a" is technically a VLA but implemented exactly like a
fixed size array. In C++, it is a normal fixed-size array.)
> print a.len # displays 2 (not a VLA)
printf("%i", sizeof(a) / sizeof(a[0]));
Winner - your language has a nicer syntax for getting the size of an
array. It is not something I have missed (if I have an array, I know
its size because I made the array) - but it is definitely nicer.
>
> switch x
> when e then # compares against 2 (switch uses int)
C won't let you do that. C++ lets you do it if "e" is declared
"constexpr" and you add a cast to "int".
Winner - C++, as it requires the cast to int rather than messing with
your types behind your back.
> ...
>
> (I can't use pi for my example as it is already a built-in constant.)
>
> It ticks ALL the boxes, and is very simple to implement.
>
> I think I was right about people here simply not getting it. Why have
> one simple feature when half-a-dozen different and more complex ways of
> badly doing the same thing can be used instead?
>
C++ seems to cover all the boxes as far as I can see, and beats your
constants in several aspects. C consts are a bit limited - everyone
knows that already.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-13 17:31 +0100 |
| Message-ID | <CLZJC.116258$6D.14276@fx05.am4> |
| In reply to | #130492 |
On 13/05/2018 16:57, David Brown wrote:
> On 13/05/18 01:00, bartc wrote:
> In C or C++:
>
>>
>> const e = 2.17181728
>
> constexpr double e = 2.17181728; // C++
> static const double e = 2.17181728; // C or C++
>
>
> Winner - C and C++, as they are typed.
So is my 'e', as 64-bit float as the type is inferred. Or it can be
explicitly typed too:
const real e = 2.17181728
So overall mine wins because I don't need 'static'.
>
>>
>> print &e # ERROR (ref on constant)
>
> printf("%p", (void*) &e);
>
> Winner - C and C++ let you take the address if you want to, but don't
> require the creation of an object unless needed.
No, I still win, because I said, this can be used to change the value in
3 out of 7 C compilers. So C REQUIRES a compiler to be sophisticated
enough to prevent that, and even then I can still get past the compiler,
crashing only at runtime.
In my language, this will always be detected simply because &e is
meaningless.
>>
>> [e]int a # converts e to int value
>
>
> int a[(int) e];
>
> Winner - C and C++, for having a clearer syntax and for /requiring/ the
Actually, my compiler also needed to use [int(e)] as it didn't
auto-convert from float in this case. I changed it to not need the cast
before pressing 'Send' so as to keep my example cleaner. But I could
change it back....
So a draw I think. (But I think auto-conversion from float is needed as
that is how it works everywhere else in both languages. I don't think
there are extra rules for constant expressions for array bounds,
compared with anywhere else.)
> C++ seems to cover all the boxes as far as I can see, and beats your
> constants in several aspects.
It's heavyweight. And it would be quite a bit of work to reproduce in C.
Whereas my version ['constant' proposal for C, not the 'const' of my
language] is a little bit simpler as I demonstrated in my last post.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-13 21:34 +0200 |
| Message-ID | <pda3vg$e82$1@dont-email.me> |
| In reply to | #130494 |
On 13/05/18 18:31, bartc wrote:
> On 13/05/2018 16:57, David Brown wrote:
>> On 13/05/18 01:00, bartc wrote:
>
>> In C or C++:
>>
>>>
>>> const e = 2.17181728
>>
>> constexpr double e = 2.17181728; // C++
>> static const double e = 2.17181728; // C or C++
>>
>>
>> Winner - C and C++, as they are typed.
>
>
> So is my 'e', as 64-bit float as the type is inferred. Or it can be
> explicitly typed too:
>
> const real e = 2.17181728
>
> So overall mine wins because I don't need 'static'.
That is fine if the inferred type is the one you want. For most of my
programming, I would want:
constexpr float e = 2.17181728;
(Note that I can omit the "f" suffix - the compiler will convert the
double literal to float.)
And for integer data, the data type inferred from the initialiser may
not match that of the constant I want.
So perhaps your system is good enough for your limited language where
you can live with a single floating point type, and perhaps just one
integer type. But not for C or C++.
>
>>
>>>
>>> print &e # ERROR (ref on constant)
>>
>> printf("%p", (void*) &e);
>>
>> Winner - C and C++ let you take the address if you want to, but don't
>> require the creation of an object unless needed.
>
> No, I still win, because I said, this can be used to change the value in
> 3 out of 7 C compilers. So C REQUIRES a compiler to be sophisticated
> enough to prevent that, and even then I can still get past the compiler,
> crashing only at runtime.
No, C requires programmers to know what they are doing. It is not a
language that tolerates fools. It gives you a lot of features to help
you, and good tools provide more, but the language does not stop you
being an ignoramus or intentionally trying to cause trouble for
yourself. (This means that you /can/ do difficult or "dangerous" things
if you are careful.)
Having said that, I'm always happier to see more warnings and checks in
compilers, and there are many things that are syntactically allowed in C
that I would prefer had to give errors. But taking the address of a
const is not one of these cases.
>
> In my language, this will always be detected simply because &e is
> meaningless.
In C and C++, you can only get code that looks like it is changing a
const if you explicitly use a cast. And a cast is a code construct that
says "I really know what I am doing here, even though it looks a bit
suspicious". If you lie to your compiler, you have only yourself to blame.
>
>>>
>>> [e]int a # converts e to int value
>>
>>
>> int a[(int) e];
>>
>> Winner - C and C++, for having a clearer syntax and for /requiring/ the
>
> Actually, my compiler also needed to use [int(e)] as it didn't
> auto-convert from float in this case. I changed it to not need the cast
> before pressing 'Send' so as to keep my example cleaner. But I could
> change it back....
>
> So a draw I think. (But I think auto-conversion from float is needed as
> that is how it works everywhere else in both languages. I don't think
> there are extra rules for constant expressions for array bounds,
> compared with anywhere else.)
>
>> C++ seems to cover all the boxes as far as I can see, and beats your
>> constants in several aspects.
>
> It's heavyweight. And it would be quite a bit of work to reproduce in C.
> Whereas my version ['constant' proposal for C, not the 'const' of my
> language] is a little bit simpler as I demonstrated in my last post.
>
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-13 11:11 -0700 |
| Message-ID | <8b5f1a24-1163-42db-ac1d-5460a10b804a@googlegroups.com> |
| In reply to | #130492 |
On Sunday, May 13, 2018 at 10:57:28 AM UTC-5, David Brown wrote:
> On 13/05/18 01:00, bartc wrote:
> > [e]int a # converts e to int value
>
>
> int a[(int) e];
>
> Winner - C and C++, for having a clearer syntax and for /requiring/ the
> size of the array to be an integer type instead of converting it on the
> fly. (In C, "a" is technically a VLA but implemented exactly like a
> fixed size array. In C++, it is a normal fixed-size array.)
While an implementation might implement it as a fixed-sized array,
there are some corner cases that are defined for fixed-sized arrays
but would be constraint violations for VLAs. There are also some
cases that would yield defined behavior for fixed-sized arrays but
UB for VLAs.
For example:
switch(foo)
{
int x[pseudoConst];
case 0:
...
case 1:
...
}
would be a constraint violation, but would be allowable (and might not
be unreasonable) if pseudoConst were replaced by an actual constant.
Given something like:
int *p;
goto ONE;
TWO:
doSomethingWith(p);
goto THREE;
ONE:
int foo[pseudoConst];
p = foo;
goto TWO;
THREE:
;
The lifetime of "foo" would be terminated by the "goto TWO" but if
pseudoConst were replaced by a constant expression, it wouldn't (I
personally would think it would have been reasonable to say that a
"goto" to a location before a declaration would end the lifetime of
anything declared thereby, whether or not it was a VLA, but that's
not what the Standard actually says).
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-13 19:41 +0100 |
| Message-ID | <2F%JC.16985$AQ.11785@fx32.am4> |
| In reply to | #130492 |
On 13/05/2018 16:57, David Brown wrote:
> On 13/05/18 01:00, bartc wrote:
>> [e]int a # converts e to int value
>
>
> int a[(int) e];
>
> Winner - C and C++, for having a clearer syntax
I missed this earlier on, but how do you figure out that C has a clearer
syntax here?
If you ignore the cast, which is on the C version, then you're saying that:
int a[e];
is a clearer syntax than:
[e]int a
To me they are equivalent, except C needs a semicolon. Although if you
consider how the type is expressed in English (array e of int), my
version is closer.
But make the requirements slightly more elaborate, and C soon gets left
behind because of its crazy syntax and because array/pointer modifiers
need to be repeated for each name in a declaration list.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-13 21:42 +0200 |
| Message-ID | <pda4ei$hec$1@dont-email.me> |
| In reply to | #130499 |
On 13/05/18 20:41, bartc wrote: > On 13/05/2018 16:57, David Brown wrote: >> On 13/05/18 01:00, bartc wrote: > >>> [e]int a # converts e to int value >> >> >> int a[(int) e]; >> >> Winner - C and C++, for having a clearer syntax > > I missed this earlier on, but how do you figure out that C has a clearer > syntax here? Personal opinion. Feel free to personally disagree. (The "(int)" cast is, of course, unrealistic because people don't write such code - so you can ignore that bit). > > If you ignore the cast, which is on the C version, then you're saying that: > > int a[e]; > > is a clearer syntax than: > > [e]int a > Yes. I'd be happy with "int[e] a;", or "a : int[e];", or "a : array[0 .. e-1] of int;" or many other formats. I wouldn't be particularly unhappy if a language had "[e]int a" either - but I find the C syntax clearer than yours. C syntax can be messy for complex declarations - that is one reason I usually avoid them (typedefs are marvellous things). But I don't see your syntax as an improvement at all - at best, it is merely different. It is not a big issue - certainly not in this case. If I were looking at a new programming language to use, "[e]int a" would not turn me away. > To me they are equivalent, except C needs a semicolon. Although if you > consider how the type is expressed in English (array e of int), my > version is closer. I don't program in English. I program in C, Python, Pascal, assembly, or whatever. > > But make the requirements slightly more elaborate, and C soon gets left > behind because of its crazy syntax and because array/pointer modifiers > need to be repeated for each name in a declaration list. >
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-13 13:09 -0700 |
| Message-ID | <3c5d3190-88e4-409d-9938-e030a4e8185f@googlegroups.com> |
| In reply to | #130508 |
On Sunday, May 13, 2018 at 2:42:18 PM UTC-5, David Brown wrote: > I don't program in English. I program in C, Python, Pascal, assembly, > or whatever. In many cases, it is useful for computer languages to have spoken forms that do not require explicit enumeration of all the characters therein. While one could describe a declaration as aye-en-tee space eff-oh-oh openbrace one-zero closebrace semicolon it's nicer to be able to describe it as something like: int array foo of size ten. Even complex Pascal declarations (in dialects that allow them) can be vocalized straightforwardly. Var I as Array zerota seven of pointer to pointer to array zerota nine of double. I'm not sure how I would try to verbally describe that same construct in C, except by explicitly specifying all the punctuation involved, which would then require the listener to write it all down to have any clue what it meant.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-14 12:41 +0200 |
| Message-ID | <pdbp43$egj$1@dont-email.me> |
| In reply to | #130510 |
On 13/05/18 22:09, supercat@casperkitty.com wrote: > On Sunday, May 13, 2018 at 2:42:18 PM UTC-5, David Brown wrote: >> I don't program in English. I program in C, Python, Pascal, assembly, >> or whatever. > > In many cases, it is useful for computer languages to have spoken forms > that do not require explicit enumeration of all the characters therein. That may be true for some people - it is not true for me. I don't try to vocalise or read aloud programming code. To me, programming is written, not spoken. I am willing to accept that this is not the same for everyone. It may also be why some people find punctuation annoying in programming languages, while it does not bother me noticeably.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-05-14 14:25 +0100 |
| Message-ID | <87bmdijrn5.fsf@bsb.me.uk> |
| In reply to | #130533 |
David Brown <david.brown@hesbynett.no> writes: > On 13/05/18 22:09, supercat@casperkitty.com wrote: >> On Sunday, May 13, 2018 at 2:42:18 PM UTC-5, David Brown wrote: >>> I don't program in English. I program in C, Python, Pascal, assembly, >>> or whatever. >> >> In many cases, it is useful for computer languages to have spoken forms >> that do not require explicit enumeration of all the characters therein. > > That may be true for some people - it is not true for me. I don't try > to vocalise or read aloud programming code. To me, programming is > written, not spoken. As a lecturer my case is not typical, but I was "speaking code" a lot of the time. It did not have to be unambiguous (since there were always printed notes), but I did have to have vocalisations for many things. > I am willing to accept that this is not the same for everyone. It may > also be why some people find punctuation annoying in programming > languages, while it does not bother me noticeably. Victor Borge comes to mind: https://www.youtube.com/watch?v=Qf_TDuhk3No I can only imagine what he'd do with C or C++! -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-12 15:36 -0700 |
| Message-ID | <fd341a91-7dc5-434f-9cab-ab1ef9a5d88f@googlegroups.com> |
| In reply to | #130474 |
On Saturday, May 12, 2018 at 4:48:57 PM UTC-5, Bart wrote:
> Being able to use & willy-nilly on both variables and objects which are
> supposed to be just named constants shows disregard for the type system.
I can see some slight benefit to having a qualifier which would waive
the requirement that an immutable object have a consistent or unique
address, such that given e.g.
magickeyword const double v1 = 1.25;
magickeyword const double v2 = 1.25;
int test(double *p1, double *p2, double *p3)
{
return (p1==p2)+2*(p1==p3)+4*(p2==p3);
}
...
a call to test(&v1, &v1, &v2) would be allowed to return 0, 1, 2, 4, or
7, since &v1 would be allowed to yield a pointer to any double which
is immutably equal to 1.25, and &v2 would be allowed likewise. Requiring
that every declaration of a constant yield an object with a distinct
address may impair what would otherwise be useful optimizations.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-13 12:05 -0700 |
| Message-ID | <4af60cbc-5660-491b-bcd9-1f280a46d310@googlegroups.com> |
| In reply to | #130476 |
On Saturday, May 12, 2018 at 3:36:41 PM UTC-7, supe...@casperkitty.com wrote:
> On Saturday, May 12, 2018 at 4:48:57 PM UTC-5, Bart wrote:
> > Being able to use & willy-nilly on both variables and objects which are
> > supposed to be just named constants shows disregard for the type system.
>
> I can see some slight benefit to having a qualifier which would waive
> the requirement that an immutable object have a consistent or unique
> address, such that given e.g.
>
> magickeyword const double v1 = 1.25;
> magickeyword const double v2 = 1.25;
>
> int test(double *p1, double *p2, double *p3)
> {
> return (p1==p2)+2*(p1==p3)+4*(p2==p3);
> }
> ...
>
> a call to test(&v1, &v1, &v2) would be allowed to return 0, 1, 2, 4, or
> 7, since &v1 would be allowed to yield a pointer to any double which
> is immutably equal to 1.25, and &v2 would be allowed likewise. Requiring
> that every declaration of a constant yield an object with a distinct
> address may impair what would otherwise be useful optimizations.
With no reason at all, as is the norm for Barry Margolin.
Do you have a high school diploma?
Nobody gets it, I barely understand it.
--
Get Rich Slow!!
http://www.5z8.info/creditscore_g7f8du_launchexe
http://prescottcomputerguy.com
https://redd.it/6sfhq6
Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-12 15:53 -0700 |
| Message-ID | <ln8t8oa3kh.fsf@kst-u.example.com> |
| In reply to | #130474 |
bartc <bc@freeuk.com> writes:
[...]
> & works with a normal variable, because when you write:
>
> double x;
>
> then the type of 'x' - the name, not the contents of the location it
> refers to - is really double*. When used in an expression, it is
> automatically dereferenced to yield the contents of the location:
>
> *(&x); // equivalent to just x in a HLL
>
> When you write &x, then that is really this:
>
> &*(&x);
>
> The & and * cancel to leave you with &x, of type double*.
"That's not how this works. That's not how any of this works."
The object named `x` is of type double. The definition `double x;` does
not create anything of type `double*`, any more than it creates anything
of type `size_t`.
The *expression* `&x` is of type `double*`. That value, of pointer
type, doesn't exist until the expression `&x` is evaluated. Similarly,
`sizeof x` is of type size_t, and that value doesn't exist until the
expression `sizeof x` is evaluated.
An lvalue is an expression that "designates" an object. That is not at
all the same thing as a *pointer* to an object.
[...]
> This why I think few people 'get it'; they certainly don't get the need
> for an ultra-simple feature with straightforward rules.
You should understand the existing rules before proposing new ones.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-13 00:14 +0100 |
| Message-ID | <3zKJC.11239$3a1.5531@fx11.am4> |
| In reply to | #130477 |
On 12/05/2018 23:53, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
> [...]
>> & works with a normal variable, because when you write:
>>
>> double x;
>>
>> then the type of 'x' - the name, not the contents of the location it
>> refers to - is really double*. When used in an expression, it is
>> automatically dereferenced to yield the contents of the location:
>>
>> *(&x); // equivalent to just x in a HLL
>>
>> When you write &x, then that is really this:
>>
>> &*(&x);
>>
>> The & and * cancel to leave you with &x, of type double*.
>
> "That's not how this works. That's not how any of this works."
>
> The object named `x` is of type double.
I said the type of the name 'x', not the contents of the location it
refers to. Suppose my 'double x' declaration was represented by this
assembly sequence:
x:
resb 8 # reserve 8 bytes
What would be the type, in C terms, of the address designated by label
x? What would be the type, in C terms, of the contents of those 8 bytes
it refers to?
The definition `double x;` does
> not create anything of type `double*`, any more than it creates anything
> of type `size_t`.
>
> The *expression* `&x` is of type `double*`. That value, of pointer
> type, doesn't exist until the expression `&x` is evaluated. Similarly,
> `sizeof x` is of type size_t, and that value doesn't exist until the
> expression `sizeof x` is evaluated.
>
> An lvalue is an expression that "designates" an object. That is not at
> all the same thing as a *pointer* to an object.
And yet, &x and &pi both yield a double* pointer. What does that tell
you about about x and pi? The pi is supposed to be a replacement for
writing 3.14159... all over your code.
> [...]
>
>> This why I think few people 'get it'; they certainly don't get the need
>> for an ultra-simple feature with straightforward rules.
>
> You should understand the existing rules before proposing new ones.
I've been implementing this stuff most of my life. You can't do that
without having some inkling of how it has to work.
And I can tell you that my named constant feature (it's not really a
proposal as that's never going to happen) is simpler and works much
better than any near equivalent that C has.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-12 18:05 -0700 |
| Message-ID | <ln4ljc9xh8.fsf@kst-u.example.com> |
| In reply to | #130479 |
bartc <bc@freeuk.com> writes:
> On 12/05/2018 23:53, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>> [...]
>>> & works with a normal variable, because when you write:
>>>
>>> double x;
>>>
>>> then the type of 'x' - the name, not the contents of the location it
>>> refers to - is really double*. When used in an expression, it is
>>> automatically dereferenced to yield the contents of the location:
>>>
>>> *(&x); // equivalent to just x in a HLL
>>>
>>> When you write &x, then that is really this:
>>>
>>> &*(&x);
>>>
>>> The & and * cancel to leave you with &x, of type double*.
>>
>> "That's not how this works. That's not how any of this works."
>>
>> The object named `x` is of type double.
>
> I said the type of the name 'x', not the contents of the location it
> refers to.
Yes, I know what you said. What I don't know is what "the type of
the name" is supposed to mean.
x is of type double, whether by "x" you mean the object whose name is
x or the expression x (which is an lvalue referring to the object).
> Suppose my 'double x' declaration was represented by this
> assembly sequence:
>
> x:
> resb 8 # reserve 8 bytes
>
> What would be the type, in C terms, of the address designated by label
> x? What would be the type, in C terms, of the contents of those 8 bytes
> it refers to?
You're asking about the C type of some assembly language construct?
It has no type in C terms because it's not C.
> The definition `double x;` does
>> not create anything of type `double*`, any more than it creates anything
>> of type `size_t`.
>>
>> The *expression* `&x` is of type `double*`. That value, of pointer
>> type, doesn't exist until the expression `&x` is evaluated. Similarly,
>> `sizeof x` is of type size_t, and that value doesn't exist until the
>> expression `sizeof x` is evaluated.
>>
>> An lvalue is an expression that "designates" an object. That is not at
>> all the same thing as a *pointer* to an object.
>
> And yet, &x and &pi both yield a double* pointer. What does that tell
> you about about x and pi? The pi is supposed to be a replacement for
> writing 3.14159... all over your code.
That x and pi are of type double.
I think the pi you're referring to, from upthread, is:
constexpr double pi = 3.14159265358979323846264338327950288419716939937511;
which isn't even valid C. But if it were, presumably pi would be of
type double. Your claim was the "name" is of type double*. I invite
you to cite the C standard to support that claim.
[...]
>>> This why I think few people 'get it'; they certainly don't get the need
>>> for an ultra-simple feature with straightforward rules.
>>
>> You should understand the existing rules before proposing new ones.
>
> I've been implementing this stuff most of my life. You can't do that
> without having some inkling of how it has to work.
You have demonstrated in this thread that you do not understand
the rules of C as it's currently defined, by making incorrect
statements about them. I can't see your years of experience.
I can see what you write here.
> And I can tell you that my named constant feature (it's not really a
> proposal as that's never going to happen) is simpler and works much
> better than any near equivalent that C has.
You know what? I'd like to see something like what you're proposing
added to C. I'd like to have a way to define a named constant
(not at all the same thing as "const") without relying on the
preprocessor. There are workarounds. For example
enum { answer = 42 };
does pretty much exactly what I want, except that can only be of
type int.
C++ already has some features in this area, and there's considerable
advantage in avoiding too much inconsistency with C++. Adopting
C++'s constexpr might be a good solution. (The fact that you *can*
abuse it using pointer casts is at worst mildly annoying. Any decent
C programmer needs to have an abiding mistrust of pointer casts.)
If we ignore C++ compatibility, I might suggest something like:
constant int answer = 42;
where "constant" is a new keyword. (It might have to be "_Constant",
perhaps with a header to define "constant" as a macro, as was done
for _Bool.) The initializer would have to be a constant expression,
and the name `answer` would also be a constant expression. It would
have no address. It could be of any scalar type.
It's entirely possible that this idea has flaws I haven't thought of.
I haven't said that your fundamental idea is a bad one. The problem
is that you misrepresent C as it currently exists while arguing
for it.
--
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]
Page 7 of 12 — ← Prev page 1 … 5 6 [7] 8 9 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web