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 6 of 12 — ← Prev page 1 … 4 5 [6] 7 8 … 12 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-12 13:33 -0700 |
| Message-ID | <ff92036a-f45c-434f-9ad0-0f66108efd27@googlegroups.com> |
| In reply to | #130443 |
On Saturday, May 12, 2018 at 5:53:15 AM UTC-5, Bart wrote: > const still allows something that can have a different value each time > the declaration is encountered. constexpr still allows a writeable > pointer to the value that is declared (via a cast): The address of a constexpr or const-qualified object may be converted to a non-qualified pointer via cast, but use of the pointer to actually write the object would invoke Undefined Behavior, and could thus alter the value of numeric literals regardless of how they're defined. I don't see how taking the address of a const-qualified object makes it any more susceptible to corruption than it would be otherwise. If code which receives pointers to const-qualified object can be relied upon to refrain from writing them, such objects won't be corrupted. If code cannot be relied upon, nothing will be immune from corruption.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-13 22:56 +0100 |
| Message-ID | <%v2KC.118745$9t.57180@fx26.am4> |
| In reply to | #130443 |
On 12/05/2018 11:53, bartc wrote:
> On 12/05/2018 00:41, Thiago Adams wrote:
>> On Friday, May 11, 2018 at 7:39:06 PM UTC-3, Keith Thompson wrote:
>
>>> I can see the point of wanting a construct that creates a constant
>>> value (as `enum { answer = 42 };` does for constants of type int).
>>> But what problem does the fact that PI2 has an address actually
>>> cause?
>>
>> The compiler is allowed to remove storage for
>> const as well.
>> The problem with constexpr for C, in this context,
>> if adds more rules and complexity almost for nothing.
>> I would like a feature that I have control. I dont like
>> the const either. I would prefer that const were just
>> a type modifier that avoids writing, not something related
>> with immutability, that is confuse.
>>
>> 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?
>
> I've discussed this a few times in this group, and it appears that most
> people here just don't get it.
It seems they still don't get it, and they don't want it. It's got to be
'constexpr' or nothing.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-13 15:18 -0700 |
| Message-ID | <bb40e839-0eab-4fcd-a967-4a2f645c7f3a@googlegroups.com> |
| In reply to | #130517 |
On Sunday, May 13, 2018 at 4:56:18 PM UTC-5, Bart wrote:
> It seems they still don't get it, and they don't want it. It's got to be
> 'constexpr' or nothing.
I'm not sure I understand your objection to a constexpr object being able
to have its address taken. I could see a legitimate basis for requiring
that every named object be given a *distinct* address, but in cases where
a function accepts a pointer argument as a proxy for the value of the
object identified thereby, being able to pass the address of a constant
would seem in every way better than having to create a temporary object
for that purpose.
In what way does blocking the use of & with a particular kind of constant
offer any real protection against anything? If a programmer who is
unable to say:
foo(&constantValue);
is compelled instead to say:
typeofThing const temp = constantValue;
foo(&temp);
then the circumstance in which the function would have tried to modify
constnatValue in the first version above would invoke Undefined
Behavior in the second, and could modify the storage used for
constantValue whether or not its address is taken. So what's really
being protected?
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-13 23:41 +0100 |
| Message-ID | <ia3KC.118746$9t.97515@fx26.am4> |
| In reply to | #130518 |
On 13/05/2018 23:18, supercat@casperkitty.com wrote:
> On Sunday, May 13, 2018 at 4:56:18 PM UTC-5, Bart wrote:
>> It seems they still don't get it, and they don't want it. It's got to be
>> 'constexpr' or nothing.
>
> I'm not sure I understand your objection to a constexpr object being able
> to have its address taken.
It's the same objection to trying to take the address of (a+b). The
latter is some transient value that doesn't really exist in any location
where applying & would be meaningful.
The same argument as being able to take the address of the number 26.
With named constants, the constant value involved is similarly an
abstract value that is not associated with any location. There might
well be a location required in making use of it, in the same way there
might be one for a+b, but that is behind the scenes of the language.
I could see a legitimate basis for requiring
> that every named object
Where the object is just a value, rather than a container for a value,
then there should be no address of the container, because there is no
container.
(The language can of course decide to create such a container, in order
to 'box' those troublesome entities and yield a meaningful value for &26
that contains a copy of 26, but I don't think C is doing that. Although
some seem keen for that to happen.)
> In what way does blocking the use of & with a particular kind of constant
> offer any real protection against anything? If a programmer who is
> unable to say:
>
> foo(&constantValue);
>
> is compelled instead to say:
>
> typeofThing const temp = constantValue;
> foo(&temp);
>
> then the circumstance in which the function would have tried to modify
> constnatValue in the first version above would invoke Undefined
> Behavior in the second, and could modify the storage used for
> constantValue ...
What storage? If expressed in assembly:
constantValue equ 42
constantvalue is some symbol inside the assembler associated with the
value 42. And actually, if constantValue is not used anywhere in the
program, then it is impossible for the running program to change the
value of constantValue because neither the symbol nor its value exists.
Where constantValue /is/ used, then there will be multiple copies of 42,
in the form of immediate operands of instructions, or initialisation
data for actual variables, such of which are intended to be mutable anyway.
If the concept of & was applied here, which of those dozens of instances
would be the target of the 'address' of 42? It is a meaningless idea.
So the protection works by making the value an abstract one that is
inaccessible, for the purposes of mutation, to the usual mechanisms of
the language
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-14 12:05 +0200 |
| Message-ID | <pdbn19$1pv$1@dont-email.me> |
| In reply to | #130520 |
On 14/05/18 00:41, bartc wrote:
> On 13/05/2018 23:18, supercat@casperkitty.com wrote:
>> On Sunday, May 13, 2018 at 4:56:18 PM UTC-5, Bart wrote:
>>> It seems they still don't get it, and they don't want it. It's got to be
>>> 'constexpr' or nothing.
>>
>> I'm not sure I understand your objection to a constexpr object being able
>> to have its address taken.
>
> It's the same objection to trying to take the address of (a+b). The
> latter is some transient value that doesn't really exist in any location
> where applying & would be meaningful.
>
> The same argument as being able to take the address of the number 26.
In many languages, you can do that. Like C++, for instance - you can
pass a literal or an expression by reference:
#include <stdio.h>
void foo(const int &x) {
printf("x = %i\n", x);
}
int main(void) {
int x = 20;
foo(x);
foo(20);
foo(15 + 5);
}
The compiler will act approximately as though it had seen:
void foo_p(const int *px) {
printf("x = %i\n", *px);
}
int main(void) {
int x = 20;
foo_p(&x);
const int temp1 = 20;
foo_p(&temp1);
const int temp2 = 15 + 5;
foo_p(&temp2);
}
>
> With named constants, the constant value involved is similarly an
> abstract value that is not associated with any location. There might
> well be a location required in making use of it, in the same way there
> might be one for a+b, but that is behind the scenes of the language.
Equally, you can say that even though the language (C and C++) allow you
to take the address of a "const" object, there may well /not/ be a
location involved - but that is behind the scenes, optimised by the
compiler.
But this appears to be going round in circles. You think being unable
to take the address is an advantage, I think it is a disadvantage. I
don't expect either of us to change.
(I do, of course, appreciate the benefit of compilers making it hard to
write code that looks like you are using the address of a constant in
order to change it. C and C++ give you that. In the above C++ code,
for example, if you had "foo(int &x)" without the "const" then it would
not compile.)
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-14 04:30 -0700 |
| Message-ID | <7b28b490-4321-481d-a813-4d18c6bca07b@googlegroups.com> |
| In reply to | #130531 |
On Monday, May 14, 2018 at 3:05:37 AM UTC-7, David Brown wrote:
> On 14/05/18 00:41, bartc wrote:
> > On 13/05/2018 23:18, supercat@casperkitty.com wrote:
> >> On Sunday, May 13, 2018 at 4:56:18 PM UTC-5, Bart wrote:
> >>> It seems they still don't get it, and they don't want it. It's got to be
> >>> 'constexpr' or nothing.
> >>
> >> I'm not sure I understand your objection to a constexpr object being able
> >> to have its address taken.
> >
> > It's the same objection to trying to take the address of (a+b). The
> > latter is some transient value that doesn't really exist in any location
> > where applying & would be meaningful.
> >
> > The same argument as being able to take the address of the number 26.
>
> In many languages, you can do that. Like C++, for instance - you can
> pass a literal or an expression by reference:
>
> #include <stdio.h>
> void foo(const int &x) {
> printf("x = %i\n", x);
> }
>
> int main(void) {
> int x = 20;
> foo(x);
> foo(20);
> foo(15 + 5);
> }
>
> The compiler will act approximately as though it had seen:
>
> void foo_p(const int *px) {
> printf("x = %i\n", *px);
> }
>
> int main(void) {
> int x = 20;
> foo_p(&x);
>
> const int temp1 = 20;
> foo_p(&temp1);
>
> const int temp2 = 15 + 5;
> foo_p(&temp2);
> }
>
> >
> > With named constants, the constant value involved is similarly an
> > abstract value that is not associated with any location. There might
> > well be a location required in making use of it, in the same way there
> > might be one for a+b, but that is behind the scenes of the language.
>
> Equally, you can say that even though the language (C and C++) allow you
> to take the address of a "const" object, there may well /not/ be a
> location involved - but that is behind the scenes, optimised by the
> compiler.
>
>
> But this appears to be going round in circles. You think being unable
> to take the address is an advantage, I think it is a disadvantage. I
> don't expect either of us to change.
>
> (I do, of course, appreciate the benefit of compilers making it hard to
> write code that looks like you are using the address of a constant in
> order to change it. C and C++ give you that. In the above C++ code,
> for example, if you had "foo(int &x)" without the "const" then it would
> not compile.)
Thomas 'The Fool' E must understand everyone knows he is just lying.
Regardless of my reasoned avoidance of Elementary OS, I even now continue to use it for users who've had problems with Windows.
dorayme just wiped his ass with Thomas 'The Fool' E. dorayme and Thomas 'The Fool' E had their snafus and their predicaments. One played it off as someone else's mistake and didn't do anything too outrageous that could not be tricking people until it was too late.
No one here has ever read my code, much less found a bug; still, in the back of my mind, I'm thinking, "What if the program crashes".
I don't know if there is a no-cost open sores that promotes PEE.
-
This broke the Internet
http://prescottcomputerguy.com
Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-14 08:31 -0700 |
| Message-ID | <d9107c4f-6132-4017-b14d-dffd5739ec1f@googlegroups.com> |
| In reply to | #130520 |
On Sunday, May 13, 2018 at 5:41:26 PM UTC-5, Bart wrote:
> It's the same objection to trying to take the address of (a+b). The
> latter is some transient value that doesn't really exist in any location
> where applying & would be meaningful.
The address won't exist in any meaningful location unless the compiler
puts it there. The easy solution is to have the compiler put it there.
Consider:
#include <stdio.h>
void print_double(double const * restrict p);
/* Sample implementation:
{
printf("%12.6f", *p);
}*/
void test(double x, double y)
{
print_double( &(double){x+y} );
}
During the execution of "print_double", the address would have meaning.
Outside that context, it wouldn't. I'm not sure I see the problem. The
Standard makes compound literals inefficient in cases where the value is
constant, but if anything that would be an argument in favor of allowing
code to take the address of constants in such contexts.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-14 08:39 -0700 |
| Message-ID | <4dc2282b-ed3e-4954-93b8-43141dc98ddb@googlegroups.com> |
| In reply to | #130548 |
On Monday, May 14, 2018 at 8:32:05 AM UTC-7, supe...@casperkitty.com wrote:
> On Sunday, May 13, 2018 at 5:41:26 PM UTC-5, Bart wrote:
> > It's the same objection to trying to take the address of (a+b). The
> > latter is some transient value that doesn't really exist in any location
> > where applying & would be meaningful.
>
> The address won't exist in any meaningful location unless the compiler
> puts it there. The easy solution is to have the compiler put it there.
>
> Consider:
>
> #include <stdio.h>
>
> void print_double(double const * restrict p);
> /* Sample implementation:
> {
> printf("%12.6f", *p);
> }*/
>
> void test(double x, double y)
> {
> print_double( &(double){x+y} );
> }
>
> During the execution of "print_double", the address would have meaning.
> Outside that context, it wouldn't. I'm not sure I see the problem. The
> Standard makes compound literals inefficient in cases where the value is
> constant, but if anything that would be an argument in favor of allowing
> code to take the address of constants in such contexts.
I just set a filter and don't see the flooding. Carlos E.R.'s attack has made a veritable disaster of cola via Google Groups, so I don't endeavor replying to your posts with my phone anymore. A good thing he has succeeded at with this behavior is that the Carlos E.R. ban will forever stay. A shadow of justification, projected wisely, at the wrong time.
benj's computer has more memory than Carlos E.R.'s. benj wins. Carlos E.R. loses. So take that, Carlos E.R..
Not only did benj's question not mention the "DE", it has not a thing to do with Elementary OS. Carlos E.R. should learn to read ;)
--
One Smart Penny!!
http://www.5z8.info/horse-slaughter_w8c4en_launchexe
Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-14 17:21 +0100 |
| Message-ID | <CIiKC.211446$Pv4.406@fx23.am4> |
| In reply to | #130548 |
On 14/05/2018 16:31, supercat@casperkitty.com wrote:
> On Sunday, May 13, 2018 at 5:41:26 PM UTC-5, Bart wrote:
>> It's the same objection to trying to take the address of (a+b). The
>> latter is some transient value that doesn't really exist in any location
>> where applying & would be meaningful.
>
> The address won't exist in any meaningful location unless the compiler
> puts it there. The easy solution is to have the compiler put it there.
>
> Consider:
>
> #include <stdio.h>
>
> void print_double(double const * restrict p);
> /* Sample implementation:
> {
> printf("%12.6f", *p);
> }*/
>
> void test(double x, double y)
> {
> print_double( &(double){x+y} );
> }
>
> During the execution of "print_double", the address would have meaning.
> Outside that context, it wouldn't. I'm not sure I see the problem. The
> Standard makes compound literals inefficient in cases where the value is
> constant, but if anything that would be an argument in favor of allowing
> code to take the address of constants in such contexts.
>
Well, then it would be setting aside separate storage and copying the
value involved into it. It would be equivalent to doing this:
double temp = x+y;
print_double(&temp);
But this not quite the same as & operating directly on x+y. You need to
signal that intent to the language by wrapping it in (T){...}.
I think I covered that in my post: it's creating a container or box for
the value, for the purposes of creating a reference to that copy of the
value. That's always going to possible, and doesn't affect being unable
to use & directly on named constants:
enum {a = 100};
Here, you can't use &a either, but this is not seen as a problem. You
can always use &(int){a}.
In this form, it seems unlikely that a malicious program would be able
to use that address to alter the value of a. It might be able to change
the copy created with &(int){a}.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-14 09:33 -0700 |
| Message-ID | <4b823a2a-e57a-468f-94fa-e2d8d6f1018a@googlegroups.com> |
| In reply to | #130552 |
On Monday, May 14, 2018 at 11:22:03 AM UTC-5, Bart wrote:
> Well, then it would be setting aside separate storage and copying the
> value involved into it. It would be equivalent to doing this:
>
> double temp = x+y;
>
> print_double(&temp);
>
> But this not quite the same as & operating directly on x+y. You need to
> signal that intent to the language by wrapping it in (T){...}.
What benefit is there to requiring that constants be wrapped in such
fashion? It adds clutter to the source code and compels compilers to
generate less efficient machine code than they could if the constants'
address could be taken directly. And as I've shown elsewhere, failure
to specify a means by which code can get the address used to hold a
literal doesn't mean that code could never receive such a pointer.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-14 17:55 +0100 |
| Message-ID | <scjKC.248170$Cd3.66133@fx33.am4> |
| In reply to | #130555 |
On 14/05/2018 17:33, supercat@casperkitty.com wrote:
> On Monday, May 14, 2018 at 11:22:03 AM UTC-5, Bart wrote:
>> Well, then it would be setting aside separate storage and copying the
>> value involved into it. It would be equivalent to doing this:
>>
>> double temp = x+y;
>>
>> print_double(&temp);
>>
>> But this not quite the same as & operating directly on x+y. You need to
>> signal that intent to the language by wrapping it in (T){...}.
>
> What benefit is there to requiring that constants be wrapped in such
> fashion?
For values such as x+y and 343, and for enum names, C already says that
you can't use & directly, and have to use compound literal.
Why have a different rule for a feature that doesn't even exist yet?
I'm in favour of not allowing direct & because such uses would be rare.
It adds clutter to the source code and compels compilers to
> generate less efficient machine code than they could if the constants'
> address could be taken directly.
Compilers such as gcc would not be fazed by them and would generate
exactly the same code.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-14 11:26 -0700 |
| Message-ID | <9645bcf5-5cff-4428-bc30-139a3ef14041@googlegroups.com> |
| In reply to | #130557 |
On Monday, May 14, 2018 at 11:56:02 AM UTC-5, Bart wrote: > On 14/05/2018 17:33, supercat@casperkitty.com wrote: > > What benefit is there to requiring that constants be wrapped in such > > fashion? > > For values such as x+y and 343, and for enum names, C already says that > you can't use & directly, and have to use compound literal. > > Why have a different rule for a feature that doesn't even exist yet? Why create a new features if not to overcome limitations of existing ones?
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-14 20:24 +0100 |
| Message-ID | <4olKC.214475$jZ.130292@fx20.am4> |
| In reply to | #130567 |
On 14/05/2018 19:26, supercat@casperkitty.com wrote:
> On Monday, May 14, 2018 at 11:56:02 AM UTC-5, Bart wrote:
>> On 14/05/2018 17:33, supercat@casperkitty.com wrote:
>>> What benefit is there to requiring that constants be wrapped in such
>>> fashion?
>>
>> For values such as x+y and 343, and for enum names, C already says that
>> you can't use & directly, and have to use compound literal.
>>
>> Why have a different rule for a feature that doesn't even exist yet?
>
> Why create a new features if not to overcome limitations of existing ones?
The reason for the new all-in-one 'constant' was to use instead of a mix
of #define, enum, and various kinds of const-qualified variables.
It wasn't because some of those couldn't use & on some of those.
To bring up my ASM example one more time, I want to define a constant
like N here:
N = 8
mov rax,[R8 + N]
mov ecx,N
shl edx,N
Here, N is used an an immediate value; there is rarely any need to
obtain the address of it, and when there is, I'd have to use this:
Naddr:
dq N
Which uses a copy of N.
In C, most uses can be accommodated with enum, but enums are
specifically for int types. There is no general purpose construct at the
moment for any scalar type, with normal scope rules, and without the
&-capable, linkage, storage, array bounds, switch-case and other issues
associated with using const-qualified variables for the purpose.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-05-14 13:07 -0700 |
| Message-ID | <8a7de295-2586-4856-8e34-2f19ecf1225d@googlegroups.com> |
| In reply to | #130571 |
On Monday, May 14, 2018 at 4:24:58 PM UTC-3, Bart wrote:
> On 14/05/2018 19:26, wrote:
> > On Monday, May 14, 2018 at 11:56:02 AM UTC-5, Bart wrote:
> >> On 14/05/2018 17:33, supercat@casperkitty.com wrote:
> >>> What benefit is there to requiring that constants be wrapped in such
> >>> fashion?
> >>
> >> For values such as x+y and 343, and for enum names, C already says that
> >> you can't use & directly, and have to use compound literal.
> >>
> >> Why have a different rule for a feature that doesn't even exist yet?
> >
> > Why create a new features if not to overcome limitations of existing ones?
>
> The reason for the new all-in-one 'constant' was to use instead of a mix
> of #define, enum, and various kinds of const-qualified variables.
>
> It wasn't because some of those couldn't use & on some of those.
>
> To bring up my ASM example one more time, I want to define a constant
> like N here:
>
> N = 8
> mov rax,[R8 + N]
> mov ecx,N
> shl edx,N
>
> Here, N is used an an immediate value; there is rarely any need to
> obtain the address of it, and when there is, I'd have to use this:
>
> Naddr:
> dq N
> Which uses a copy of N.
>
> In C, most uses can be accommodated with enum, but enums are
> specifically for int types. There is no general purpose construct at the
> moment for any scalar type, with normal scope rules, and without the
> &-capable, linkage, storage, array bounds, switch-case and other issues
> associated with using const-qualified variables for the purpose.
>
> --
> bartc
My suggestion (currently incomplete) for constants is try
to reuse #define and avoid new concepts.
The suggestion is based on move preprocessor tasks
to the parser phase.
The preprocessor as it is, could be used surround by pragmas
#pragma classic_preprocessor_on
#include "header1.h"
#pragma classic_preprocessor_off
If the preprocessor was moved to parser, is possible
to give error messages about already used name.
Sample:
#define PI 3.14
void PI(){}
instead of :
error: expected identifier or '(' before numeric constant
#define PI 3.14
note: in expansion of macro 'PI'
void PI(){}
The error would be:
error: 'PI' redeclared as different kind of symbol
The compiler will know the type of PI.
(
Sometimes the tokens used in define will not make any sense,
for the compiler in this case is that this suggestion is
incomplete.
Sample:
#define CRAZYMACRO 1 +
One alternative is use the crazymacro expansion surrounded
by
#pragma classic_preprocessor_on
#pragma classic_preprocessor_off
The bad point is that the compiler must have two models
implemented.
)
The expansion for macros needs to be compatible.
For instance:
double x = 2 * PI; //fine, pi is like 3.14 the compiler knows
void PI F() //error..
{
}
The other advantage is that #if could use compiler information.
I don't see much problem in to move preprocessor to parser
for #if, #else, #define, #undef, #line, etc..
They will have to be used in some defined places in the grammar.
This is similar of [[attributes]] in C++, or static assert.
In some cases we can just re-arrange #if to be used in the correct
place.
For instance:
void F(
#ifdef X
int i
#endif
);
In case #ifdef was disallowed at this position
I could change the code to:
#ifdef X
void F(int i);
#else
void F();
#endif
The most notable differences would happen in expansion.
Considering this feature is ready to use..
#define PI 3.14
void F()
{
..
}
void F2()
{
...
}
#undef PI
I have the control of scope, the PI will be used as '3.14'
and the code still compatible with compilers written decades ago.
The other feature that is useful for scope is push and pop
states.
#push
#define PI 3.14
//here new PI is defined
#pop
//we could have an previous PI declared...
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-13 15:28 -0700 |
| Message-ID | <lnr2mf8a2p.fsf@kst-u.example.com> |
| In reply to | #130517 |
bartc <bc@freeuk.com> writes:
> On 12/05/2018 11:53, bartc wrote:
[...]
>> I've discussed this a few times in this group, and it appears that most
>> people here just don't get it.
>
> It seems they still don't get it, and they don't want it. It's got to be
> 'constexpr' or nothing.
It seems that you haven't been reading this thread, or are willfully
ignoring what other people have written in it.
Did you see my suggestion for a new "constant" keyword?
Message-ID: <ln4ljc9xh8.fsf@kst-u.example.com>
Or am I not part of "they"?
--
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 23:43 +0100 |
| Message-ID | <Oc3KC.118747$9t.13250@fx26.am4> |
| In reply to | #130519 |
On 13/05/2018 23:28, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: >> On 12/05/2018 11:53, bartc wrote: > [...] >>> I've discussed this a few times in this group, and it appears that most >>> people here just don't get it. >> >> It seems they still don't get it, and they don't want it. It's got to be >> 'constexpr' or nothing. > > It seems that you haven't been reading this thread, or are willfully > ignoring what other people have written in it. > > Did you see my suggestion for a new "constant" keyword? > Message-ID: <ln4ljc9xh8.fsf@kst-u.example.com> > > Or am I not part of "they"? Sorry, yes I did see it. By 'they' I suppose I largely mean David Brown, as I can't make any impression on him at all.
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2018-05-14 00:50 -0700 |
| Message-ID | <88aafeef-31b1-4083-bf07-85a29d8e09f7@googlegroups.com> |
| In reply to | #130521 |
On Sunday, 13 May 2018 23:44:05 UTC+1, Bart wrote: > Sorry, yes I did see it. By 'they' I suppose I largely mean David Brown, > as I can't make any impression on him at all. That works in two directions.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-14 12:37 +0200 |
| Message-ID | <pdbotq$daf$1@dont-email.me> |
| In reply to | #130521 |
On 14/05/18 00:43, bartc wrote: > On 13/05/2018 23:28, Keith Thompson wrote: >> bartc <bc@freeuk.com> writes: >>> On 12/05/2018 11:53, bartc wrote: >> [...] >>>> I've discussed this a few times in this group, and it appears that most >>>> people here just don't get it. >>> >>> It seems they still don't get it, and they don't want it. It's got to be >>> 'constexpr' or nothing. >> >> It seems that you haven't been reading this thread, or are willfully >> ignoring what other people have written in it. >> >> Did you see my suggestion for a new "constant" keyword? >> Message-ID: <ln4ljc9xh8.fsf@kst-u.example.com> >> >> Or am I not part of "they"? > > Sorry, yes I did see it. By 'they' I suppose I largely mean David Brown, > as I can't make any impression on him at all. > Should I be flattered that you view me as the spokesperson for "they", or some sort of general "C programmers" group? Keith and I agree on many things, but we also have different opinions on other things. The same, I believe, applies to pretty much everyone here (including you - contrary to your claims, we agree on many points). For example, I agree with Keith that there could be a better constant system in C. I am not convinced that it needs to be a /new/ system and a new keyword for the purpose - I think C++ const covers the main points that I see. And as noted before, I understand that you want some sort of super-constant that is simple and yet all-powerful, and that being unable to take its address is one of the powers you want it to have. I still do not really understand /why/ you want it, and cannot see any benefit in being unable to take the address of your constants, but there we have it. If by "they still don't get it" you mean "David does not agree with me", then fair enough.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-05-13 08:32 +1200 |
| Message-ID | <flp1bgFua2iU4@mid.individual.net> |
| In reply to | #130435 |
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 );
}
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-12 22:48 +0100 |
| Message-ID | <6jJJC.146191$MD7.27173@fx14.am4> |
| In reply to | #130468 |
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.)
& 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*.
If you can apply & to pi to also yield a double*, it means that pi and x
are of the same rank - both variables with the same level of indirection
to get to their value.
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.
Either that, or a complex set of rules are in force where sometimes pi
is used as though it's stored in a memory location, sometimes it can be
an immediate value, or maybe sometimes a memory location is synthesised
to contain a copy of the value as needed.
This why I think few people 'get it'; they certainly don't get the need
for an ultra-simple feature with straightforward rules.
--
bartc
[toc] | [prev] | [next] | [standalone]
Page 6 of 12 — ← Prev page 1 … 4 5 [6] 7 8 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web