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 3 of 12 — ← Prev page 1 2 [3] 4 5 … 12 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-11 15:36 -0700 |
| Message-ID | <b126bb90-9a5d-436c-b92b-3024f4c45c69@googlegroups.com> |
| In reply to | #130428 |
On Friday, May 11, 2018 at 3:28:49 PM UTC-5, Thiago Adams wrote:
> On Friday, May 11, 2018 at 4:59:34 PM UTC-3, Ian Collins wrote:
> > On 05/12/2018 05:13 AM, Thiago Adams wrote:
> > >
> > > I have a list of features from C++ I would like to
> > > see in C.
> > >
> > > Most of these features can be experimented today in C++.
> > >
> > > One C++ feature list very easy to read is available together
> > > with Visual C++ compiler updates.
> > >
> > > https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/
> > >
> > > Features I would like in C:
> >
> > You overlooked the potentially most useful feature: real constants and
> > constant expressions.
> >
>
> Do you mean?
>
> constexpr double PI2 = 3.141592653589793;
>
>
> I don't like because of this:
>
> int main() {
> constexpr double PI2 = 3.141592653589793;
> const double *PI = &PI2;
>
> printf("%p\n", PI);
> return 0;
> }
>
> Why it has address?
There are many situations, especially in C (as opposed to C++) where
the address of an immutable object may be used as a proxy for the value
thereof (passing around pointers is cheaper than passing around larger
objects), or may be used as a temporary reference only during the
evaluation of the enclosing expression (as with something like
memcpy(&dest, &src, sizeof src);).
Is there any reason bona fide constants shouldn't be usable in such contexts?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-11 15:38 -0700 |
| Message-ID | <lnwow9akcd.fsf@kst-u.example.com> |
| In reply to | #130428 |
Thiago Adams <thiago.adams@gmail.com> writes:
> On Friday, May 11, 2018 at 4:59:34 PM UTC-3, Ian Collins wrote:
[...]
>> You overlooked the potentially most useful feature: real constants and
>> constant expressions.
>
> Do you mean?
>
> constexpr double PI2 = 3.141592653589793;
>
> I don't like because of this:
>
> int main() {
> constexpr double PI2 = 3.141592653589793;
> const double *PI = &PI2;
>
> printf("%p\n", PI);
> return 0;
> }
>
> Why it has address?
Apparently the `constexpr double ...` declaration defines an object
that, like any object, has an address -- and ensures that the name
of that object is a constant expression. (I haven't checked the C++
standard on this point so I'm not certain of the details.)
Presumably if you don't refer to the address of PI2, the compiler
could choose not to allocate storage for it.
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?
--
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 | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-05-11 16:41 -0700 |
| Message-ID | <13efc313-d10c-4357-9aa7-6fa55b09d948@googlegroups.com> |
| In reply to | #130432 |
On Friday, May 11, 2018 at 7:39:06 PM UTC-3, Keith Thompson wrote:
> Thiago Adams writes:
> > On Friday, May 11, 2018 at 4:59:34 PM UTC-3, Ian Collins wrote:
> [...]
> >> You overlooked the potentially most useful feature: real constants and
> >> constant expressions.
> >
> > Do you mean?
> >
> > constexpr double PI2 = 3.141592653589793;
> >
> > I don't like because of this:
> >
> > int main() {
> > constexpr double PI2 = 3.141592653589793;
> > const double *PI = &PI2;
> >
> > printf("%p\n", PI);
> > return 0;
> > }
> >
> > Why it has address?
>
> Apparently the `constexpr double ...` declaration defines an object
> that, like any object, has an address -- and ensures that the name
> of that object is a constant expression. (I haven't checked the C++
> standard on this point so I'm not certain of the details.)
>
> Presumably if you don't refer to the address of PI2, the compiler
> could choose not to allocate storage for it.
>
> 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?
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-12 11:53 +0100 |
| Message-ID | <kIzJC.117349$9t.42512@fx26.am4> |
| In reply to | #130435 |
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.
A named constant or literal is a no-brainer, like binary literals or
separators within numbers, yet neither C nor C++ have the feature.
With const or constexpr, you have to trust the compiler not to generate
the addressable storage, or provide some means to inadvertently change
the value.
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):
Scoped name & illegal Typed value No storage
#define No Yes No Yes
enum Yes Yes Only int Yes
const Yes No Yes No*
constexpr Yes No Yes No*
(my const Yes Yes Yes Yes)
The first four rows here show the options available to C and C++
(constexpr only for C++). None of them show Yes in all columns. No*
means it's up to the whim of the compiler, or whether & is used.
(The last row show my implementation of how named constants work. They
are only used for types for which literal constants exist: ints, floats
and strings.
The No Storage is a language concept since, depending on target
processor, there might not be immediate data versions of instructions,
especially for float values. But it would be difficult to maliciously or
inadvertently change the value of a scalar type (int, float, pointer).
However string literals will necessary reside in memory, and there is no
protection against changing them when passing them to a function, except
by putting them into a read-only section.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-05-12 13:30 +0200 |
| Message-ID | <pd6j8r$ge8$1@solani.org> |
| In reply to | #130443 |
The "No storage" is just an implementation detail. register const should give you a "Yes" in the other three columns of your table. Philipp
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-12 13:48 +0100 |
| Message-ID | <OnBJC.263027$5v7.111642@fx02.am4> |
| In reply to | #130444 |
On 12/05/2018 12:30, Philipp Klaus Krause wrote: > The "No storage" is just an implementation detail. > register const should give you a "Yes" in the other three columns of > your table. I didn't know about that, but I tried it with mixed results. But first, I could have added a few more columns to my table, both requiring Yes: * Error if not initialised (ie. hard error not a warning). * Error if not set to a value that is a compile-time constant (Possibly, can be relaxed if the expression is a relocatable address known at load time.) * Can be used as a case label or non-VLA array bound (for int types) As for the issues with 'register const': * IME named constants are typically defined outside of functions, but using 'register const' there seems problematical with some compilers * I had problems using a register const name as a case label. (I can't test for array bounds as C99 compilers will silently create a VLA.) * Register consts inside functions can be assigned non-compile-time expressions Maybe some people can't see the problems here, for example you can just use enums for case labels or array bounds. But it still seems that an all-on-one solution to the very simple requirement of scoped, named literals is elusive. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-12 12:17 -0700 |
| Message-ID | <lnsh6wadkl.fsf@kst-u.example.com> |
| In reply to | #130446 |
bartc <bc@freeuk.com> writes:
[...]
> As for the issues with 'register const':
>
> * IME named constants are typically defined outside of functions,
> but using 'register const' there seems problematical with some
> compilers
It's not just "problematical with some compilers". Using "register" on
the definition of an object outside a function definition is a
constraint violation.
> * I had problems using a register const name as a case label. (I can't
> test for array bounds as C99 compilers will silently create a VLA.)
A case label must be a constant expression. The name of a
const-qualified object (register or not) is not a constant expression.
> * Register consts inside functions can be assigned non-compile-time
> expressions
Certainly. "const" means read-only. It never makes something a
constant expression.
And to preempt what you're probably about to say, I am describing the
language, not defending it.
> Maybe some people can't see the problems here, for example you can just
> use enums for case labels or array bounds. But it still seems that an
> all-on-one solution to the very simple requirement of scoped, named
> literals is elusive.
Some people can't see the problems, which is why nobody is proposing
better ways to define named compile-time constants.
Oh, wait, that's what we're doing in this thread. And most of us
realize that it's important to understand the existing language rules
before proposing new features.
--
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 | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-05-13 09:44 +0200 |
| Message-ID | <pd8qck$u0a$1@solani.org> |
| In reply to | #130446 |
You might want to have a look at Jens Gustedt's proposal on the behaviour of register const for a future C standard (see chapter 21 of his book "Modern C"). Philipp
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-05-12 14:46 +0100 |
| Message-ID | <87r2mhm1g0.fsf@bsb.me.uk> |
| In reply to | #130443 |
bartc <bc@freeuk.com> writes:
> On 12/05/2018 00:41, Thiago Adams wrote:
<snip>
>> 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?
The example was something like
const double pi = 3.14;
to prevent taking the address (at least as much as C prevents anything)
you can use
register const double pi = 3.14;
I'm not sure that's worth it though.
> I've discussed this a few times in this group, and it appears that
> most people here just don't get it.
Your posts might get a better reception if you did not conflate all the
various opinions into a simplistic notion that other people "just don't
get it".
> Scoped name & illegal Typed value No storage
>
> #define No Yes No Yes
This line is wrong unless I am missing what the columns mean. The
#define names have some notion of scope, just like file-scope
declarations have scope. What's more, the "scope" can be terminated at
any point. You probably mean "not properly scoped" or "not scoped like
any other declaration" or something like that.
As for the other three, it depends on what you define and how you
interpret the columns headings. Given
#define f1 1.2
#define f2 (float){1.2}
both f1 and f2 have a type in some sense -- for example, the compiler
must complain about using either where a float is not permitted --
though it's the expansion and not the name itslef that has a type.
Further, in the case of f2, & is permitted and storage is used.
> (my const Yes Yes Yes Yes)
It's hard to evaluate "your" const because we don't have a definition of
the language, but I don't see why all "yes" answers is necessarily a
good thing in all cases. It might make perfect sense in the context of
the rest of the language, but there's no way for me to tell.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-12 17:23 +0100 |
| Message-ID | <MxEJC.116731$%L2.55118@fx40.am4> |
| In reply to | #130447 |
On 12/05/2018 14:46, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
>
>> On 12/05/2018 00:41, Thiago Adams wrote:
> <snip>
>>> 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.
>
> Your posts might get a better reception if you did not conflate all the
> various opinions into a simplistic notion that other people "just don't
> get it".
I can't remember anyone being in favour of a /simple/ all-in-one named
literal feature that ticks all the boxes. The only thing that was
preferred over what C already has, was C++'s even more complex 'constexpr'.
>> Scoped name & illegal Typed value No storage
>>
>> #define No Yes No Yes
>
> This line is wrong unless I am missing what the columns mean. The
> #define names have some notion of scope, just like file-scope
> declarations have scope. What's more, the "scope" can be terminated at
> any point. You probably mean "not properly scoped" or "not scoped like
> any other declaration" or something like that.
>
> As for the other three, it depends on what you define and how you
> interpret the columns headings. Given
>
> #define f1 1.2
> #define f2 (float){1.2}
>
> both f1 and f2 have a type in some sense -- for example, the compiler
> must complain about using either where a float is not permitted --
> though it's the expansion and not the name itslef that has a type.
> Further, in the case of f2, & is permitted and storage is used.
And this shows some of the problems with what C already has: #defines
may or may not have 'some sort' of scope; or they might be coercible
into having a type (by building a cast into the expansion of the macro);
and some kinds of #defines can have &applied.
There is no one feature that just does it all with no fuss.
>
>> (my const Yes Yes Yes Yes)
>
> It's hard to evaluate "your" const because we don't have a definition of
> the language, but I don't see why all "yes" answers is necessarily a
> good thing in all cases. It might make perfect sense in the context of
> the rest of the language, but there's no way for me to tell.
I explained something about how it worked. The difference between a
named literal, and a variable, is the same as the difference between
these two names in assembly:
abc = 100 # 'abc' is name with value of '100' attached
def: dd 200 # 'def' is name of location containing 200
Now a compiler might be able to figure out that 'const int def=200' can
also be loaded as an immediate value, but you are then relying on the
compiler, not the language. And def still can't be used as a switch case
value.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-05-12 19:46 +0100 |
| Message-ID | <878t8on23y.fsf@bsb.me.uk> |
| In reply to | #130455 |
bartc <bc@freeuk.com> writes: > On 12/05/2018 14:46, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: >> >>> On 12/05/2018 00:41, Thiago Adams wrote: >> <snip> >>>> 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. >> >> Your posts might get a better reception if you did not conflate all the >> various opinions into a simplistic notion that other people "just don't >> get it". > > I can't remember anyone being in favour of a /simple/ all-in-one named > literal feature that ticks all the boxes. That's your classic equivocation. You talked about "just not getting it" but your evidence is not having seen anyone being in favour of some not entirely well-specified suggestion. Is it an extension or a change? Exactly what are the semantics? Who knows? But if you are not in favour you "just don't get it". Also, you might be confusing people talking about other things as not agreeing with you. I'm pretty sure you've done this in the past. >>> (my const Yes Yes Yes Yes) >> >> It's hard to evaluate "your" const because we don't have a definition of >> the language, but I don't see why all "yes" answers is necessarily a >> good thing in all cases. It might make perfect sense in the context of >> the rest of the language, but there's no way for me to tell. > > I explained something about how it worked. But not enough for me to form an opinion about it (which is fine -- the Internet has enough opinions without mine). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-12 21:05 +0100 |
| Message-ID | <lOHJC.218733$B36.19053@fx22.am4> |
| In reply to | #130459 |
On 12/05/2018 19:46, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: >> I can't remember anyone being in favour of a /simple/ all-in-one named >> literal feature that ticks all the boxes. > > That's your classic equivocation. You talked about "just not getting > it" but your evidence is not having seen anyone being in favour of some > not entirely well-specified suggestion. Is it an extension or a change? > Exactly what are the semantics? Who knows? But if you are not in > favour you "just don't get it". There's not much to specify. The feature is very simple. Given the requirement to name a literal value (say of int or float type for now), such that you can't use & on it, you /have/ to initialise it with a compile-time value, and it has to be usable for non-VLA bounds and for switch cases, how would /you/ specify it? I explained in my last post that it can also be seen as removing a level of indirection that is normally present in every variable access in a HLL. If people really do get it, then I don't remember seeing other proposals which are classed as simple and without even more issues than there are with 'const'. Which suggests that they don't. > But not enough for me to form an opinion about it (which is fine -- the > Internet has enough opinions without mine). I'm sure you know exactly what I'm talking about. What is the difference between these two Algol68 declarations: INT a = 100; INT b := 200 ? -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-05-13 02:16 +0100 |
| Message-ID | <87y3gol5if.fsf@bsb.me.uk> |
| In reply to | #130465 |
bartc <bc@freeuk.com> writes: > On 12/05/2018 19:46, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: > >>> I can't remember anyone being in favour of a /simple/ all-in-one named >>> literal feature that ticks all the boxes. >> >> That's your classic equivocation. You talked about "just not getting >> it" but your evidence is not having seen anyone being in favour of some >> not entirely well-specified suggestion. Is it an extension or a change? >> Exactly what are the semantics? Who knows? But if you are not in >> favour you "just don't get it". > > > There's not much to specify. The feature is very simple. Yet it remains un-specified. According to you, everyone else must either be in favour of this unspecified feature or we "just don't get it". Just in case you "don't get it" -- my point has nothing to do with the feature and everything to do with your characterisation of everyone else's position. > Given the requirement to name a literal value (say of int or float > type for now), such that you can't use & on it, you /have/ to > initialise it with a compile-time value, and it has to be usable for > non-VLA bounds and for switch cases, how would /you/ specify it? I'd use a #define in C, but if you mean how would I design a change to C to add that facility then I wouldn't. I don't have the time. > If people really do get it, then I don't remember seeing other > proposals which are classed as simple and without even more issues > than there are with 'const'. Which suggests that they don't. Why is "getting it" signalled by pointlessly working to define an extension to C? Or maybe "getting it" would be suitably signified by wild speculation about how one small part of C could have been designed with no reference to C as it is or even was. >> But not enough for me to form an opinion about it (which is fine -- the >> Internet has enough opinions without mine). > > I'm sure you know exactly what I'm talking about. Obviously I know what you are talking about but I'd need to know more than just what you are talking about to be able to form an opinion of a language feature. > What is the > difference between these two Algol68 declarations: > > INT a = 100; > INT b := 200 > > ? Yes I know that distinction well. If your language is essentially a re-implementation of Algol 68 then that was a good choice of design and it's a shame it is not more widely available (though why you need the keyword const is then a mystery). If it isn't like Algol 68, knowing what an Algol 68 identity declaration means, won't help that much. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-13 12:06 +0100 |
| Message-ID | <d%UJC.126944$oo.108152@fx35.am4> |
| In reply to | #130484 |
On 13/05/2018 02:16, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: >> What is the >> difference between these two Algol68 declarations: >> >> INT a = 100; >> INT b := 200 >> >> ? > > Yes I know that distinction well. If your language is essentially a > re-implementation of Algol 68 then that was a good choice of design and > it's a shame it is not more widely available (though why you need the > keyword const is then a mystery). As it is I felt there was not enough distinction between the two INTs, and what there was would be better reflected in how the type was written. Hence the use of a 'const' prefix (NOT C's const), which makes things pretty clear, and it also allows the type to be omitted so that it can be inferred from the value, which the presence of 'const' now mandates. So much better all round in my opinion. (I also prefer to use ":=" for an actual run-time assignment, and "=" for any identity or equivalence which is set up at compile- or load-time.) > If it isn't like Algol 68, knowing > what an Algol 68 identity declaration means, won't help that much. The outcome should be the same, that 'int a' has one level of indirection less than 'int b' - the /name/ a has type INT, and the /name/ b has type REF INT. (As for how it actually works inside my language, then it uses name-identity rather than type. Given the declaration 'const ghi = 300', the const-id name 'ghi' is converted during type analysis pass to the actual integer constant '300', and behaves just as though a 300 had been written in the source code. Which is why you can't use & on it or use it as an lvalue, because you can't do those with '300' either. A little more elaborate in practice, but it always is (constant expressions can be complex, and my new language allows out-of-order declarations both within a module and across modules).) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-05-13 14:20 +0100 |
| Message-ID | <87603rlmjq.fsf@bsb.me.uk> |
| In reply to | #130487 |
bartc <bc@freeuk.com> writes: > On 13/05/2018 02:16, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: > >>> What is the >>> difference between these two Algol68 declarations: >>> >>> INT a = 100; >>> INT b := 200 >>> >>> ? >> >> Yes I know that distinction well. If your language is essentially a >> re-implementation of Algol 68 then that was a good choice of design and >> it's a shame it is not more widely available (though why you need the >> keyword const is then a mystery). > > As it is I felt there was not enough distinction between the two INTs, > and what there was would be better reflected in how the type was > written. As you know, you can expand the second to make the ref type explicit but it gets clumsy. > Hence the use of a 'const' prefix (NOT C's const), which makes things > pretty clear, It makes it clear to you -- it's your language after all. What's not clear to me is how, if at all, you do C's const. It's not (IIRC) possible in Algol 68 to simulate C's "read only" meaning of const but it doesn't matter much because of the rest of the design of the language. You don't usually use REF REF modes in the same way you use pointer types in C, so marking the target "read only" is rarely needed. But no one except you knows the rest of your design -- not even the intended purpose of the design -- so I can't form an opinion. And I wouldn't anyway -- not here -- as it's off topic. The merits of C's "read only" meaning of const (well, "read-only through this lvalue expression") is still, just about, on topic. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-13 16:19 +0100 |
| Message-ID | <VHYJC.83441$jb7.60431@fx34.am4> |
| In reply to | #130488 |
On 13/05/2018 14:20, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: >> Hence the use of a 'const' prefix (NOT C's const), which makes things >> pretty clear, > > It makes it clear to you -- it's your language after all. What's not > clear to me is how, if at all, you do C's const. My 'const' tries to do what Pascal's 'const' does rather C's 'const'. That's why I sometimes use 'constant' for proposed examples in C syntax. If such a feature was added to C, then it wouldn't be able to use 'const'. > It's not (IIRC) possible in Algol 68 to simulate C's "read only" meaning > of const but it doesn't matter much because of the rest of the design of > the language. You don't usually use REF REF modes in the same way you > use pointer types in C, so marking the target "read only" is rarely > needed. I haven't tried to do the equivalent of C's 'const' at all. I don't think C-const works very well; it just introduces extra clutter for little benefit, and as protection against modifying a data structure, there are too many holes giving a false sense of security. But I haven't found a satisfactory alternative. (At the low level, it may not matter, and doesn't really need much more than a way to denote that certain tables need to reside in a read-only section. At the next level, I use mutability flags to ensure literal data in the program can't be modified.) But no one except you knows the rest of your design -- not even > the intended purpose of the design -- so I can't form an opinion. > > And I wouldn't anyway -- not here -- as it's off topic. The merits of > C's "read only" meaning of const (well, "read-only through this lvalue > expression") is still, just about, on topic. C's choice of 'const' to mean 'read-only' may have a lot to answer for. And often it doesn't even mean that, but write-once-read-many. But there is never any suggestion that it is declaring anything other than something that is stored in memory (or even in a register). -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-13 21:00 +0200 |
| Message-ID | <pda209$go$1@dont-email.me> |
| In reply to | #130490 |
On 13/05/18 17:19, bartc wrote: > On 13/05/2018 14:20, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: > >>> Hence the use of a 'const' prefix (NOT C's const), which makes things >>> pretty clear, >> >> It makes it clear to you -- it's your language after all. What's not >> clear to me is how, if at all, you do C's const. > > My 'const' tries to do what Pascal's 'const' does rather C's 'const'. > That's why I sometimes use 'constant' for proposed examples in C syntax. Ironically, "const" is famous in Pascal (particularly Borland's flavours) for being /completely/ wrong. "const x : Integer = 123;" in Pascal does /not/ make "x" a constant. It makes x a variable with an initial value. Without a specified type - like "const x = 123;" - it defines a real constant "x". But then you can't specify the type of the constant, and you can't use initialisers other than a very limited set of operations on constant values (unlike "const" in C++). It is a little like an inflexible version of "#define", but with better scoping. All in all, Pascal's "const" is a rather poor model to copy. > > If such a feature was added to C, then it wouldn't be able to use 'const'. > >> It's not (IIRC) possible in Algol 68 to simulate C's "read only" meaning >> of const but it doesn't matter much because of the rest of the design of >> the language. You don't usually use REF REF modes in the same way you >> use pointer types in C, so marking the target "read only" is rarely >> needed. > > I haven't tried to do the equivalent of C's 'const' at all. I don't > think C-const works very well; it just introduces extra clutter for > little benefit, and as protection against modifying a data structure, > there are too many holes giving a false sense of security. > > But I haven't found a satisfactory alternative. (At the low level, it > may not matter, and doesn't really need much more than a way to denote > that certain tables need to reside in a read-only section. At the next > level, I use mutability flags to ensure literal data in the program > can't be modified.) > > But no one except you knows the rest of your design -- not even >> the intended purpose of the design -- so I can't form an opinion. >> >> And I wouldn't anyway -- not here -- as it's off topic. The merits of >> C's "read only" meaning of const (well, "read-only through this lvalue >> expression") is still, just about, on topic. > > C's choice of 'const' to mean 'read-only' may have a lot to answer for. It is hard to get a consistent idea of "constant" in coding, and one that can be used in all cases. C's version is rather limited - C++'s is a good deal better, but still has compromises. I am solidly convinced that you can't have a single "constant" idea that covers all aspects that would be needed - certainly your attempt at one "simple" version does not. > And often it doesn't even mean that, but write-once-read-many. Objects defined as "const" are not writeable at all in C or C++ - they can (indeed, must) be /initialised/, but not written. > But there > is never any suggestion that it is declaring anything other than > something that is stored in memory (or even in a register). > There is never any suggestion that anyone cares if it is stored in memory (unless, of course, you want to use its address and /want/ it to be in memory).
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-13 20:30 +0100 |
| Message-ID | <en0KC.126946$oo.96240@fx35.am4> |
| In reply to | #130501 |
On 13/05/2018 20:00, David Brown wrote:
> On 13/05/18 17:19, bartc wrote:
> All in all, Pascal's "const" is a rather poor model to copy.
I more than likely copied the CONST keyword, with the concept of having
one indirection level less than VAR, taken from Algol68. But I would
also have been /very/ familiar with the distinction between constant and
label from assembler:
a = 100 # or 'a equ 100'
b: dd 200
load R,a # immediate load of 100
load R,[b] # memory load of (for now) 200
This is all this is about. As I keep saying, it is VERY simple.
And there is NO way to modify that 100 (short of disassembling the code
looking for immediate values of 100s, but you won't know which is which;
and then the code won't usually have write access).
There may not always be 100% correspondence between ASM and HLL, but
there won't be; that's what makes a HLL a HLL and not ASM. Providing a
consistent model with clear separation between CONST and VAR is easy for
a high level language.
>>> And I wouldn't anyway -- not here -- as it's off topic. The merits of
>>> C's "read only" meaning of const (well, "read-only through this lvalue
>>> expression") is still, just about, on topic.
>>
>> C's choice of 'const' to mean 'read-only' may have a lot to answer for.
>
> It is hard to get a consistent idea of "constant" in coding, and one
> that can be used in all cases. C's version is rather limited - C++'s is
> a good deal better, but still has compromises. I am solidly convinced
> that you can't have a single "constant" idea that covers all aspects
> that would be needed - certainly your attempt at one "simple" version
> does not.
>
>> And often it doesn't even mean that, but write-once-read-many.
>
> Objects defined as "const" are not writeable at all in C or C++ - they
> can (indeed, must) be /initialised/, but not written.
Any non-static const objects in C must be initialised at runtime, and
that requires write access. (You won't get help by being in a read-only
section either.)
Perhaps you mean static-const rather than mere const, but now it's
getting messy again.
>> But there is never any suggestion that it is declaring anything other
>> than something that is stored in memory (or even in a register).
>>
>
> There is never any suggestion that anyone cares if it is stored in
> memory (unless, of course, you want to use its address and /want/ it to
> be in memory).
Well, you might care when you put a const variable into a shared header,
and you end up with multiple definitions of the same name.
So then you need to put static in front, which solves that problem, but
presumably now you have multiple copies of each constant, one per
module. It MIGHT be an issue, but the way I do CONST, it is NEVER an issue.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-14 09:49 +0200 |
| Message-ID | <pdbf1k$de1$1@dont-email.me> |
| In reply to | #130504 |
On 13/05/18 21:30, bartc wrote: > On 13/05/2018 20:00, David Brown wrote: >> On 13/05/18 17:19, bartc wrote: > >> All in all, Pascal's "const" is a rather poor model to copy. > > I more than likely copied the CONST keyword, with the concept of having > one indirection level less than VAR, taken from Algol68. I don't know Algol except by reputation, so I can't compare it here. > But I would > also have been /very/ familiar with the distinction between constant and > label from assembler: > > a = 100 # or 'a equ 100' > b: dd 200 > > load R,a # immediate load of 100 > load R,[b] # memory load of (for now) 200 > > This is all this is about. As I keep saying, it is VERY simple. That is assembly. C is not assembly. The comparison is basically irrelevant. (If you want your language to be a directly translated language closer to assembly - letting you get accurate control of the code and a simple compiler, but forcing the programmer to deal with far more small details - then that's absolutely fine. But C is not such a language.) > > And there is NO way to modify that 100 (short of disassembling the code > looking for immediate values of 100s, but you won't know which is which; > and then the code won't usually have write access). When you write "const int a = 100;" in C, there is NO way to modify that 100, short of intentionally writing undefined behaviour by clearly dangerous code, and /hoping/ it will have the modification effect. It is not really that different. > > There may not always be 100% correspondence between ASM and HLL, but > there won't be; that's what makes a HLL a HLL and not ASM. Providing a > consistent model with clear separation between CONST and VAR is easy for > a high level language. > >>>> And I wouldn't anyway -- not here -- as it's off topic. The merits of >>>> C's "read only" meaning of const (well, "read-only through this lvalue >>>> expression") is still, just about, on topic. >>> >>> C's choice of 'const' to mean 'read-only' may have a lot to answer for. >> >> It is hard to get a consistent idea of "constant" in coding, and one >> that can be used in all cases. C's version is rather limited - C++'s >> is a good deal better, but still has compromises. I am solidly >> convinced that you can't have a single "constant" idea that covers all >> aspects that would be needed - certainly your attempt at one "simple" >> version does not. >> >>> And often it doesn't even mean that, but write-once-read-many. >> >> Objects defined as "const" are not writeable at all in C or C++ - they >> can (indeed, must) be /initialised/, but not written. > > Any non-static const objects in C must be initialised at runtime, and > that requires write access. (You won't get help by being in a read-only > section either.) No, any const objects in C that have static allocation (i.e., file-scope "const", file-scope "static const" or function block scope "static const") are initialised in some way by the pre-main() startup code. In most binary formats on most platforms, this is done by simply having them in a read-only section in the binary, just like the code sections (but with no "execute" privileges). They are never "written", in the sense of program-generated executable code storing a value to a memory address. (The exception here is C++ const objects that have initialisers that do involve user-level code - these get assigned once before main() starts, by a similar process to the construction of statically allocated class objects.) > > Perhaps you mean static-const rather than mere const, but now it's > getting messy again. No, I don't. > >>> But there is never any suggestion that it is declaring anything other >>> than something that is stored in memory (or even in a register). >>> >> >> There is never any suggestion that anyone cares if it is stored in >> memory (unless, of course, you want to use its address and /want/ it >> to be in memory). > > Well, you might care when you put a const variable into a shared header, > and you end up with multiple definitions of the same name. Why should I care about what happens with clearly and obviously incorrect code that no experienced C programmer would ever write? I /understand/ how to write C code correctly - in particular, I know how linkage works in C programming. I know how to structure my code to avoid mistakes like this that are syntactically acceptable to the compiler, and sometimes happen to work in code, but are still undefined behaviour and can lead to weird errors. I have known this since the earliest days of my C programming. My workmates all know how to write C correctly, and why you use "extern" in headers, and why you use "static" for file-local data and functions. So do people writing serious third-party libraries and code for embedded systems - and I don't use non-serious code from people who /don't/ know what they are doing. I also understand the benefit of good tools, and of learning how to use them properly, letting me enforce good practices. (I would always get an error from the compiler and/or linker on this sort of thing.) I understand about testing, code reviews, and generally doing good software development. (I don't claim to be perfect by any means - or even to carry out all the good practices. But I understand what is important.) This sort of mistake - putting object /definitions/ in header files used by multiple translation units - is /easy/ to avoid. It is an utterly irrelevant error for me, because it simply does not happen. > > So then you need to put static in front, which solves that problem, but > presumably now you have multiple copies of each constant, one per > module. It MIGHT be an issue, but the way I do CONST, it is NEVER an issue. > Write C /correctly/, and there is never an issue.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-14 11:56 +0100 |
| Message-ID | <2XdKC.101874$ny5.26355@fx17.am4> |
| In reply to | #130525 |
On 14/05/2018 08:49, David Brown wrote: > On 13/05/18 21:30, bartc wrote: >> And there is NO way to modify that 100 (short of disassembling the code >> looking for immediate values of 100s, but you won't know which is which; >> and then the code won't usually have write access). > > When you write "const int a = 100;" in C, there is NO way to modify that > 100, short of intentionally writing undefined behaviour by clearly > dangerous code, and /hoping/ it will have the modification effect. It > is not really that different. It's very easy, you write: *(int*)&a = 999; which all C compilers will accept. But it will only work on implementations that don't store that 100 in read-only memory Also, if it is modified, whether that will affect any of the instances of 'a' in a program depends on whether the compiler used an immediate 100 or loaded its value from memory. When explicitly using &a to pass its value, then likely the 100 will then be seen as 999. So you see, it depends on various different things. If you see this in C source, without knowing the compiler or machine to be used, then you cannot say with 100% certainty that the 100 will not be changed. On the other hand, you can be 100% certain that it can't happen in either my language, or C using the 'constant' feature. Because writing &a is a hard error. -- bartc
[toc] | [prev] | [next] | [standalone]
Page 3 of 12 — ← Prev page 1 2 [3] 4 5 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web