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 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-14 13:15 +0200 |
| Message-ID | <pdbr57$qqc$1@dont-email.me> |
| In reply to | #130536 |
On 14/05/18 12:56, bartc wrote: > 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; > Casting pointers /is/ dangerous coding - you do it when you have to for special purposes, but it should be a rare thing. It is an unfortunate case that old C did not have const, people have been lazy about const, and you might need duplications for functions that sometimes take const data and sometimes non-const data (strchr being a classic example). This means getting "const" right in every case is not practical, and you do sometimes legitimately need to make such casts from pointer-to-const to pointer-to-non-const. Thus it can't be an error, or even a warning by default (gcc needs "-Wcast-qual" explicitly - it is not even in -Wextra, which I think is questionable). I would be happier to see compilers being smarter at spotting undefined behaviour, such as this, and warning on it or giving errors in cases like this. > which all C compilers will accept. But it will only work on > implementations that don't store that 100 in read-only memory > Testing will quickly reveal the problem. I'd prefer it to be spotted by tools earlier. Disabling taking the address of const objects would be too much. Just be careful when writing dangerous code constructs like pointer casts. Prefer to write code without a cast: int * p = &a; *p = 999; Then you will get an error or warning in many more cases. > 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. Sometimes you will get the original value, sometimes the changed value, yes. > > So you see, it depends on various different things. It is undefined behaviour - of course it depends on 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. If you know that "a" is declared const, then you know with 100% certainty that the code is bad. If you don't know how "a" is declared, you don't know anything anyway. > > 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. > I'd rather the compiler gave a hard error (or at least a warning) when it saw the undefined behaviour. That does not need to limit the functionality of const. But I fully agree with you that an error here of some sort would be a good idea.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-14 09:28 -0700 |
| Message-ID | <7585f336-9e52-4432-961f-85d0473f3b97@googlegroups.com> |
| In reply to | #130536 |
On Monday, May 14, 2018 at 5:56:06 AM UTC-5, Bart wrote:
> 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
Given:
#include <stdio.h>
void doSomethingWith(int const *a);
// Implementation: { *(int*)&a = 999; }
int test(void)
{
static const int a = 12345678;
doSomethingWith(&a);
printf("%d\n", 12345678);
}
is there any reason you would expect that the value of the literal 12345678
could not be changed by the call to doSomethingWith() ? Some platforms like
the ARM don't have a load-immediate that can accept arbitrary values, and
instead require that code wanting to load r0 with 0x12345678 must either:
(1) Load R0 with 0x12340000 and then OR it with 0x5678, or
(2) Load R0 from an address which is within some distance of the current
code location.
The former approach would require two four-byte instructions. The latter
approach requires one two-byte instruction, and then requires that a
four-byte value be stored somewhere nearby. If 'a' could be placed anywhere
in memory, a compiler wanting to load its address would need to use one of
the above approaches at a cost of at least 6 bytes. If 'a' were stored
within a short distance of the code needing its address, however, that
address could be computed with a two-byte instruction. I don't know that
any ARM compilers would actually perform this optimization, but placing 'a'
at the address of the literal constant 12345678 would be more efficient
than doing anything else, would conform to the C Standard, and shouldn't
violate any reasonable programmer expectations.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-14 17:44 +0100 |
| Message-ID | <b2jKC.155666$MD7.70207@fx14.am4> |
| In reply to | #130553 |
On 14/05/2018 17:28, supercat@casperkitty.com wrote:
> On Monday, May 14, 2018 at 5:56:06 AM UTC-5, Bart wrote:
>> 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
>
> Given:
>
> #include <stdio.h>
> void doSomethingWith(int const *a);
> // Implementation: { *(int*)&a = 999; }
>
> int test(void)
> {
> static const int a = 12345678;
> doSomethingWith(&a);
> printf("%d\n", 12345678);
> }
>
> is there any reason you would expect that the value of the literal 12345678
> could not be changed by the call to doSomethingWith() ?
Compilers such as gcc will put 'a' into a read-only section (.rdata),
which will not have the memory flags needed to write to it.
So it will crash on Windows, and it gives a segmentation fault on Linux
running on ARM32.
But take out the static, and a is changed to 999. Presumably 'a' must
then reside in normal read-write memory within the stack frame, even
though gcc can see it should only ever have the value 12345678.
Some platforms like
> the ARM don't have a load-immediate that can accept arbitrary values,
That's not the issue here (and anyway the limited immediate loads, I
believe 12 bits plus optional shift, probably cover 99% of all such values).
You wouldn't allow & on some constants, and not on others, depending on
which can be immediate loads on the target hardware. It's a language issue.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-14 10:13 -0700 |
| Message-ID | <9251941c-3230-4f9d-b87e-ea49e0f2001f@googlegroups.com> |
| In reply to | #130556 |
On Monday, May 14, 2018 at 11:45:05 AM UTC-5, Bart wrote:
> On 14/05/2018 17:28, supercat@casperkitty.com wrote:
> > On Monday, May 14, 2018 at 5:56:06 AM UTC-5, Bart wrote:
> >> 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
> >
> > Given:
> >
> > #include <stdio.h>
> > void doSomethingWith(int const *a);
> > // Implementation: { *(int*)&a = 999; }
> >
> > int test(void)
> > {
> > static const int a = 12345678;
> > doSomethingWith(&a);
> > printf("%d\n", 12345678);
> > }
> >
> > is there any reason you would expect that the value of the literal 12345678
> > could not be changed by the call to doSomethingWith() ?
>
> Compilers such as gcc will put 'a' into a read-only section (.rdata),
> which will not have the memory flags needed to write to it.
Indeed, that seems to be a common practice, and there are some good
reasons that projects may rely upon such behavior for objects of
external scope. It seems unlikely that very many (if any) programs
would rely upon such behavior for static objects with function scope.
While gcc does not presently optimize by storing such objects within
the 'text' segment, I see no reason to believe that other compilers
or future versions of gcc will never do so since it would be fairly
low-hanging fruit.
> But take out the static, and a is changed to 999. Presumably 'a' must
> then reside in normal read-write memory within the stack frame, even
> though gcc can see it should only ever have the value 12345678.
Suppose doSomethingWith were defined as:
void doSomethingWith(int const *a)
{
static int *lastValue = 0;
if (!lastValue)
{
lastValue = a;
test();
}
else
{
printf("%d", a==lastValue);
lastValue = 0;
}
}
Even though 'a' is const, the doSomethingWith() function would be entitled
to expect that nested invocations will receive pointers that compare unequal.
This would be true not only for named automatic objects, but also for
compound literals.
I don't know if any non-contrived programs would be broken by changing
the Standard to say that a const-qualified compound literal may share its
address with any other const-qualified compound literal having the same
byte representation, but the Standard does not presently allow that
even though it would be a useful optimization. Applying such behavior to
all const-qualified objects of file scope would be a breaking change, but
there should be a way of inviting similar optimizations in those cases
where it wouldn't break anything.
> > Some platforms like
> > the ARM don't have a load-immediate that can accept arbitrary values,
>
> That's not the issue here (and anyway the limited immediate loads, I
> believe 12 bits plus optional shift, probably cover 99% of all such values).
My point is that if code writes to const-qualified objects, a compiler
may quite reasonably generate code where constants no longer behave as
expected.
> You wouldn't allow & on some constants, and not on others, depending on
> which can be immediate loads on the target hardware. It's a language issue.
No, instead I'd say that if code employs & on a named constant, a compiler
would be required to behave as though it yields the address of a static
object that holds that value. A compiler would be free to use any existing
static object it knows about with the right value, or create a new static
value just for purposes of handling a particular "&", whichever would be
more efficient in a particular context.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-05-14 17:46 +0000 |
| Message-ID | <6YjKC.80654$oR2.58004@fx25.iad> |
| In reply to | #130559 |
supercat@casperkitty.com writes:
>On Monday, May 14, 2018 at 11:45:05 AM UTC-5, Bart wrote:
>> On 14/05/2018 17:28, supercat@casperkitty.com wrote:
>> > On Monday, May 14, 2018 at 5:56:06 AM UTC-5, Bart wrote:
>> >> 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
>> >
>> > Given:
>> >
>> > #include <stdio.h>
>> > void doSomethingWith(int const *a);
>> > // Implementation: { *(int*)&a = 999; }
>> >
>> > int test(void)
>> > {
>> > static const int a = 12345678;
>> > doSomethingWith(&a);
>> > printf("%d\n", 12345678);
>> > }
>> >
>> > is there any reason you would expect that the value of the literal 12345678
>> > could not be changed by the call to doSomethingWith() ?
>>
>> Compilers such as gcc will put 'a' into a read-only section (.rdata),
>> which will not have the memory flags needed to write to it.
>
>Indeed, that seems to be a common practice [snip].
For very good reasons related to correctness and security.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-05-14 17:13 +0000 |
| Message-ID | <IsjKC.125981$yc1.23682@fx40.iad> |
| In reply to | #130553 |
supercat@casperkitty.com writes:
>On Monday, May 14, 2018 at 5:56:06 AM UTC-5, Bart wrote:
>> 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
>
>Given:
>
> #include <stdio.h>
> void doSomethingWith(int const *a);
> // Implementation: { *(int*)&a = 999; }
>
> int test(void)
> {
> static const int a = 12345678;
> doSomethingWith(&a);
> printf("%d\n", 12345678);
> }
>
>is there any reason you would expect that the value of the literal 12345678
>could not be changed by the call to doSomethingWith() ? Some platforms like
>the ARM don't have a load-immediate that can accept arbitrary values, and
>instead require that code wanting to load r0 with 0x12345678 must either:
>
> (1) Load R0 with 0x12340000 and then OR it with 0x5678, or
>
> (2) Load R0 from an address which is within some distance of the current
> code location.
(3) Load R0 from any address in memory using a base address register.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-14 11:23 -0700 |
| Message-ID | <cf46dcf1-00ca-427e-9880-28393fc0ab39@googlegroups.com> |
| In reply to | #130558 |
On Monday, May 14, 2018 at 12:13:21 PM UTC-5, Scott Lurndal wrote:
> supercat@casperkitty.com writes:
> >On Monday, May 14, 2018 at 5:56:06 AM UTC-5, Bart wrote:
> >> 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
> >
> >Given:
> >
> > #include <stdio.h>
> > void doSomethingWith(int const *a);
> > // Implementation: { *(int*)&a = 999; }
> >
> > int test(void)
> > {
> > static const int a = 12345678;
> > doSomethingWith(&a);
> > printf("%d\n", 12345678);
> > }
> >
> >is there any reason you would expect that the value of the literal 12345678
> >could not be changed by the call to doSomethingWith() ? Some platforms like
> >the ARM don't have a load-immediate that can accept arbitrary values, and
> >instead require that code wanting to load r0 with 0x12345678 must either:
> >
> > (1) Load R0 with 0x12340000 and then OR it with 0x5678, or
> >
> > (2) Load R0 from an address which is within some distance of the current
> > code location.
>
> (3) Load R0 from any address in memory using a base address register.
If one has a base address register that already holds a suitable value,
great. If the compiler knew that "foo" and "bar" were within the first
1020 bytes [or more, depending upon architecture] of the same linker
section, something like "foo+bar" could be computed by loading a register
with the base address of that section and then loading foo and bar
relative to that base. Unless a programmer wants to manually group widely
static-duration objects into a structure, however, there's no way a
compiler can exploit the fact that two external objects will be close
enough to allow one base address to serve both.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-14 14:06 -0700 |
| Message-ID | <dd76a0f4-b150-4d44-8cb3-70ea0409caee@googlegroups.com> |
| In reply to | #130553 |
On Monday, May 14, 2018 at 9:28:38 AM UTC-7, supe...@casperkitty.com wrote:
> On Monday, May 14, 2018 at 5:56:06 AM UTC-5, Bart wrote:
> > 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
>
> Given:
>
> #include <stdio.h>
> void doSomethingWith(int const *a);
> // Implementation: { *(int*)&a = 999; }
>
> int test(void)
> {
> static const int a = 12345678;
> doSomethingWith(&a);
> printf("%d\n", 12345678);
> }
>
> is there any reason you would expect that the value of the literal 12345678
> could not be changed by the call to doSomethingWith() ? Some platforms like
> the ARM don't have a load-immediate that can accept arbitrary values, and
> instead require that code wanting to load r0 with 0x12345678 must either:
>
> (1) Load R0 with 0x12340000 and then OR it with 0x5678, or
>
> (2) Load R0 from an address which is within some distance of the current
> code location.
>
> The former approach would require two four-byte instructions. The latter
> approach requires one two-byte instruction, and then requires that a
> four-byte value be stored somewhere nearby. If 'a' could be placed anywhere
> in memory, a compiler wanting to load its address would need to use one of
> the above approaches at a cost of at least 6 bytes. If 'a' were stored
> within a short distance of the code needing its address, however, that
> address could be computed with a two-byte instruction. I don't know that
> any ARM compilers would actually perform this optimization, but placing 'a'
> at the address of the literal constant 12345678 would be more efficient
> than doing anything else, would conform to the C Standard, and shouldn't
> violate any reasonable programmer expectations.
For the record, spending effort educating yourself is never a waste. Insisting you know more than everyone else and taking it on yourself to 'prove' people that it is true, as benj tries to do? That is a waste. Being independent as it is, the listserv concept will never go away but it'll never be known by the general public. It was benj who was openly asking how better to obscure his nonsense. These morons get their jollies out of eliciting emotional replies to their insults, which is the very definition of a troll.
This is clearly an interest of mine. benj doesn't have any clue what he is crying about. I noted specific examples of benj attacking Alan Baker -- showing off insecurity, etc. His response: to change the topic.
-
"You'll notice how quickly he loses interest when everything is about him. He clearly wants the attention"
Steven Petruzzellis, making the dumbest comment ever uttered.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-13 12:40 -0700 |
| Message-ID | <5f0f809f-1372-4b20-bf65-4d6e7cd422e8@googlegroups.com> |
| In reply to | #130501 |
On Sunday, May 13, 2018 at 2:00:33 PM UTC-5, David Brown wrote: > 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. The choice of syntax was quirky, but Borland's typed constants were nontheless a useful semantic innovation. The way typed constants worked in Borland's Turbo Pascal 2.0 and 3.0 was that they were stored within the program image. The choice of syntax was a bit weird, but on the 8086 this design had an advantage (which did not unfortunately carry through in Turbo Pascal 4.0) of keeping those variables out of the data segment. Since the data segment was limited to 64K, having large constants not be counted against that was helpful. The design could also be beneficial within inline assembly code which needed to fetch some data from a heap-stored object, convert it to bitmaps using a shape table, and then store it to the screen. Loading segment registers within that loop would have been expensive. Instead, it took advantage of the fact that data in the code segment will remain accessible even if the DS register is set up to access a heap object and ES is set up to access the screen. While it would not have been practical to place within the code segment constants which are accessed within other units (that might be located in other code segments), it would have been nice to have allowed a means of exploiting the old semantics at least in cases where constants were only accessed within one particular unit.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-14 09:11 +0200 |
| Message-ID | <pdbcr7$vui$2@dont-email.me> |
| In reply to | #130507 |
On 13/05/18 21:40, supercat@casperkitty.com wrote: > On Sunday, May 13, 2018 at 2:00:33 PM UTC-5, David Brown wrote: >> 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. > > The choice of syntax was quirky, but Borland's typed constants were > nontheless a useful semantic innovation. Of course it was useful to have a way of defining and initialising a variable in one place - rather than defining them in a "var" section and initialising them in code. What was /not/ useful was to call them "const". (Modern Pascal's usually allow initialisation of "var" variables directly, which makes much more sense.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-12 18:03 +0200 |
| Message-ID | <pd739f$ekd$1@dont-email.me> |
| In reply to | #130443 |
On 12/05/18 12: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.
>
> A named constant or literal is a no-brainer, like binary literals or
> separators within numbers, yet neither C nor C++ have the feature.
C++ has binary literals and separators within numbers. A good many C
compilers support binary literals, but they are not standard. (I agree
that C should support them - copying both binary literals and digit
separators from C++ would seem a fine idea.)
>
> 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.
>
With all constant data of any form, the compiler may produce storage for
it - this will depend on the type of constant, the type of processor,
and the type of code generated. Whether such values are protected from
change or not depends on the target, the OS, and various other factors.
Usually, when you have a "const" object defined in C or C++, it will be
allocated a specific address - but placed in a section of memory that is
protected from writing (just like code). You /can/ use casts to make a
non-const pointer to it - but using that to try to modify the value is
not something the language allows and is typically blocked by hardware,
read-only memory pages, etc. So the fact that you can take the address
is almost totally irrelevant.
I note that - as usual - you have missed "static const" from your list.
static const definitions will lead to allocated storage only if it is
the most efficient implementation - just like for #define or enum values.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-12 17:45 +0100 |
| Message-ID | <qSEJC.125911$Hc3.102747@fx30.am4> |
| In reply to | #130453 |
On 12/05/2018 17:03, David Brown wrote:
> On 12/05/18 12:53, bartc wrote:
>> A named constant or literal is a no-brainer, like binary literals or
>> separators within numbers, yet neither C nor C++ have the feature.
>
> C++ has binary literals and separators within numbers.
By 'the feature' I mean named constants. (But didn't the other two have
to wait until 2014 to be official?)
>> 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.
>>
>
> With all constant data of any form, the compiler may produce storage for
> it - this will depend on the type of constant, the type of processor,
> and the type of code generated. Whether such values are protected from
> change or not depends on the target, the OS, and various other factors.
>
> Usually, when you have a "const" object defined in C or C++, it will be
> allocated a specific address - but placed in a section of memory that is
> protected from writing (just like code). You /can/ use casts to make a
> non-const pointer to it - but using that to try to modify the value is
> not something the language allows and is typically blocked by hardware,
> read-only memory pages, etc. So the fact that you can take the address
> is almost totally irrelevant.
> I note that - as usual - you have missed "static const" from your list.
> static const definitions will lead to allocated storage only if it is
> the most efficient implementation - just like for #define or enum values.
Thanks, another for my list. So to define what /I/ call a constant, you
have to use one of these forms:
const int abc=100;
static const int abc=100;
register const int abc=100;
enum {abc=100};
#define abc 100
all with different attributes.
If I had 'const T abc=expr' in my language, is there just ONE way to
express it in C so that it behaves the same way:
* Is an immediate load (if T and target instruction set allows)
* Never allocates storage (unless T or instruction set require it)
* Never allows &, whether it needs storage or not
* Can be used to declare a non-VLA (when convertible to int)
* Can be used as a switch-case value (when convertible to int)
* Dropping the =expr part is a hard error
* Obeys normal scoping rules
* Works at least for any int or float type
?
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2018-05-12 18:00 +0000 |
| Message-ID | <slrn3sj8pfeash.fsc.ike@iceland.freeshell.org> |
| In reply to | #130456 |
On 2018-05-12, bartc <bc@freeuk.com> wrote: > If I had 'const T abc=expr' in my language, is there just ONE way to > express it in C so that it behaves the same way: > > * Is an immediate load (if T and target instruction set allows) Imagine an instruction set that allows immediate loads as well as loads from storage (e.g. from a register), and suppose that load-from-register is faster/cheaper than immediate load. Would you require an immediate load under those circumstances? The SPARC is a concrete example of such an instruction set. Loading zero is such a common operation that the SPARC compiler reserves register R0 to always contain zero, so that when the value zero has to be loaded, it can use load-from-R0 instead of the more expensive load-immediate-zero.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-12 20:31 +0100 |
| Message-ID | <siHJC.218732$B36.61131@fx22.am4> |
| In reply to | #130458 |
On 12/05/2018 19:00, Ike Naar wrote:
> On 2018-05-12, bartc <bc@freeuk.com> wrote:
>> If I had 'const T abc=expr' in my language, is there just ONE way to
>> express it in C so that it behaves the same way:
>>
>> * Is an immediate load (if T and target instruction set allows)
>
> Imagine an instruction set that allows immediate loads as well as
> loads from storage (e.g. from a register), and suppose that
> load-from-register is faster/cheaper than immediate load.
>
> Would you require an immediate load under those circumstances?
>
> The SPARC is a concrete example of such an instruction set.
> Loading zero is such a common operation that the SPARC compiler
> reserves register R0 to always contain zero, so that when the value
> zero has to be loaded, it can use load-from-R0 instead of the more
> expensive load-immediate-zero.
None of this stops the usual optimisations. So on x86, loading zero can
be done with:
xor eax,eax
rather than an actual immediate load. But you need to know that the
value is definitely zero.
Being capable of being used as immediate data, subject to the hardware
cooperating, is one way of distinguishing the two type of names.
Look at this pattern:
Access to the int requires:
int** a; // three data memory accesses
int* b; // two memory accesses
int c; // one memory access
constant int d; // zero memory accesses (ie. immediate)
That's all this is about; it's removing a level of indirection in the
same way that "*" adds a level.
What does C have to do the same as that 'constant int'? That is,
something which you know will solidly apply, and not just depend on what
a compiler may or may not do.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-13 16:57 +0200 |
| Message-ID | <pd9joh$snm$1@dont-email.me> |
| In reply to | #130456 |
On 12/05/18 18:45, bartc wrote:
> On 12/05/2018 17:03, David Brown wrote:
>> On 12/05/18 12:53, bartc wrote:
>
>>> A named constant or literal is a no-brainer, like binary literals or
>>> separators within numbers, yet neither C nor C++ have the feature.
>>
>> C++ has binary literals and separators within numbers.
>
> By 'the feature' I mean named constants.
Except that they do - C++ has had decent named constants since its
beginnings. They don't happen to fit the particular set of features
that you personally want, but they fit the features that most people
want. (C's constants are poorer - no doubts there. They are usable,
but not as good as C++'s.)
> (But didn't the other two have
> to wait until 2014 to be official?)
Yes. Binary literals were available in many compilers before that, but
not part of the standard. I agree that the standards were slow here
(and C still hasn't got them officially).
>
>>> 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.
>>>
>>
>> With all constant data of any form, the compiler may produce storage
>> for it - this will depend on the type of constant, the type of
>> processor, and the type of code generated. Whether such values are
>> protected from change or not depends on the target, the OS, and
>> various other factors.
>>
>> Usually, when you have a "const" object defined in C or C++, it will
>> be allocated a specific address - but placed in a section of memory
>> that is protected from writing (just like code). You /can/ use casts
>> to make a non-const pointer to it - but using that to try to modify
>> the value is not something the language allows and is typically
>> blocked by hardware, read-only memory pages, etc. So the fact that
>> you can take the address is almost totally irrelevant.
>
>> I note that - as usual - you have missed "static const" from your
>> list. static const definitions will lead to allocated storage only if
>> it is the most efficient implementation - just like for #define or
>> enum values.
>
> Thanks, another for my list. So to define what /I/ call a constant, you
> have to use one of these forms:
>
> const int abc=100;
> static const int abc=100;
> register const int abc=100;
> enum {abc=100};
> #define abc 100
>
> all with different attributes.
Different tools for different purposes. Many people prefer a toolbox
rather than a single Swiss-army knife. (Nobody would use "register
const" in practice - but then, nobody other than you sees "cannot take
the address" as a useful feature.)
>
> If I had 'const T abc=expr' in my language, is there just ONE way to
> express it in C so that it behaves the same way:
>
> * Is an immediate load (if T and target instruction set allows)
This is purely a matter of implementation. I can't answer for /your/
language and /your/ compiler, but a quality compiler will do this for
any type of constant, literal or other data of any sort, in any language
on any target, if the language guarantees that the value cannot legally
be changed and this is the most efficient implementation.
In C and C++, all the types of constant data that you list above cannot
be changed. If the compiler knows the value (i.e., it is not an "extern
const" defined in another translation unit), the compiler can use the
most efficient mechanism.
Note that immediate loads are frequently /not/ the best method. In a
great many cases, fixed data in a read-only memory section is more
efficient. And in other cases, using the value directly makes more
sense. (For example, if the value was 8 and you were using it for
multiplication, then changing the multiplication to a shift is more
efficient than using an immediate load of 8 and then a multiply.)
So on this point, all types of C and C++ constants are fine - as always,
on the assumption of a half-decent compiler. (For other compilers, you
don't care about efficiency anyway.)
> * Never allocates storage (unless T or instruction set require it)
See above - all kinds of constants may be most efficient with storage.
The only kind of constants in C and C++ that might unnecessarily use
storage are if you have a "const" that is declared with external linkage
(for C, that is the default if you don't use "static" - for C++, you
need an explicit "extern" declaration) but don't actually need it
externally. The answer here, of course, is to write your program
correctly - if a "const" is only used in the one translation file, make
it "static".
So all types of C and C++ constants are fine here - C++ having the edge
because "const" constants are static by default.
(I hesitate to tell you, but good tools can also be used to remove the
extra storage later if you are lazy about using "static" appropriately
but are obsessed with storage sizes.)
> * Never allows &, whether it needs storage or not
This is, of course, utterly irrelevant and provides no benefits.
Again, C and C++ constants of all sorts are fine.
> * Can be used to declare a non-VLA (when convertible to int)
Here C++ is better than C, in that "const" data can be used for such
declarations. #define and enum constants are fine in both languages.
> * Can be used as a switch-case value (when convertible to int)
Fine for #define and enum, and fine for "const" in C++. Accepted as an
extension in C by some compilers.
> * Dropping the =expr part is a hard error
By that, you mean you don't like that C and C++ allow "const x;" where
"x" is defined elsewhere? That is a /feature/, not an error. (I would
prefer that you needed the "extern" for a const declaration that is not
a definition, but that's just my preference.)
> * Obeys normal scoping rules
"const" and "enum" in C and C++ obey scopes. #define constants obey
pre-processor scoping, which is different. So you have a choice.
> * Works at least for any int or float type
>
All the constant types listed for C and C++ support int type - and all
except "enum" support any type at all.
So as far as I can see, you have everything you need in C and C++
constants. You do need to know when to use "static" - and some people
(including you) appear to find that difficult. I have no explanation
for why that is the case.
C++ "const" are clearly better than C "const", as they can be used in
more contexts. They cover most needs fine.
"enum" is mainly for defining groups of related constants - a feature
that appears to be missing from your language. Enumerated types have
features beyond simply defining some constants - they give a reusable
type. They are weak types - mixable with ints - but tools can use them
for static checking, debugging, IDE hints, etc. And C++ has strong
enumerate types.
#define is less strict and has poorer scoping - but is more flexible and
provides many features that non-preprocessor constructs cannot.
The main complaints I have with constants in C is the same as most
people's - and that could be fixed by copying the "const" features of C++.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-13 17:14 +0100 |
| Message-ID | <VvZJC.198278$r6.44077@fx10.am4> |
| In reply to | #130489 |
On 13/05/2018 15:57, David Brown wrote: > On 12/05/18 18:45, bartc wrote: >> all with different attributes. > > Different tools for different purposes. None of which do exactly the job of simply attaching a scoped name to a literal value, and nothing else. enum is the closest if the type involved is an int, but even that is intended for a different purpose. > So as far as I can see, you have everything you need in C and C++ > constants. As far as I can see, I have to choose some combination of static, register, const, enum or #define. I can choose to assign a value or not. Some choices might allow &, some don't. Some may involve allocating storage, others not, or it might depend on whether & is used. It may or may not be exported. And if I use 'const double pi=3.1416;" in a shared header, then I am likely to end up with multiple definitions of 'pi'. This must be the famous so-called flexibility of C in action. Seriously, can no one else see what a hopeless mess all this is? > "enum" is mainly for defining groups of related constants - a feature > that appears to be missing from your language. I have enums, but normally use the more sophisticated table-building features. But when needing a stand-alone named constant, then my 'const' feature does that job perfectly without any ifs and buts of the assortment of features used in C. It is simple (an attribute that few appreciate in this group). > The main complaints I have with constants in C is the same as most > people's - and that could be fixed by copying the "const" features of C++. I've just spent 30 minutes adding 'constant' to my new C compiler. But it's clear it will take much longer to do properly. Still, it illustrates how it works, but with these limitations: * Only at module scope * Type can't be omitted (ie. can't be inferred from expression) * Only for char, int, float types But it does illustrate these attributes: * Initialisation /must/ be provided * & is not allowed on a constant name (so no worry about possibility of modifying the value) * Not allowed as an lvalue * Substituting 'constant' for 'const' in my pi example above, then the multiple definitions magically disappear * I can shadow the module-scope constant name inside a function * If I write 'constant abc = 123' and then use 'int a=abc', it will generate code using immediate data even with my crappy compiler. So not bad for 30 minutes' work. (This monolithic C source file may or may not work: https://github.com/bartg/langs/blob/master/C/bcc64.c. It includes that quick 'constant' implementation. It will convert .c to .asm on any OS, but the asm is for Win64.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-13 11:38 -0700 |
| Message-ID | <f2f3ec01-e5a6-4ea7-9ff4-4113aba9a7c0@googlegroups.com> |
| In reply to | #130493 |
On Sunday, May 13, 2018 at 11:14:53 AM UTC-5, Bart wrote:
> * & is not allowed on a constant name (so no worry about possibility
> of modifying the value)
I'm not sure how you figure that. Given [within a function]
static const double foo = 1.25;
register const double bar = 1.25;
a compiler would be allowed to use the same storage for both. The
fact that bar is declared "register const" and cannot have its address
taken would provide no protection if code takes the address of "foo" and, after converting it to a non-const pointer, invokes Undefined Behavior
by using it to modify "foo". Further, on platforms which lack a means
of "load double immediate", a compiler given something like:
doSomething(1.25, &foo);
might load 1.25 by fetching a double from the address of "foo", since
that address is guaranteed to hold the value 1.25. The fact that code
never officially takes the address of the constant 1.25 would not prevent
a compiler from behaving as though that constant has an address.
BTW, this behavior was especially commonplace in the early days of
FORTRAN, which lead to the saying
"Variables won't; constants aren't"
since parameters were implicitly passed by reference, and the compiler
would create a compiler-use-only variable for each floating-point constant
used in a program. Calling a function FOO(123.4) would pass the compiler-
generated variable created for the constant 123.4, and if that function
modified the passed-in parameter, the value of the literal 123.4 might
change at some or all of the places it's used in the code.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-13 19:52 +0100 |
| Message-ID | <OP%JC.12759$463.12626@fx21.am4> |
| In reply to | #130498 |
On 13/05/2018 19:38, supercat@casperkitty.com wrote: > On Sunday, May 13, 2018 at 11:14:53 AM UTC-5, Bart wrote: >> * & is not allowed on a constant name (so no worry about possibility >> of modifying the value) > > I'm not sure how you figure that. By 'constant name' I mean one declared with my new 'constant' keyword. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-13 21:18 +0200 |
| Message-ID | <pda31p$7sn$1@dont-email.me> |
| In reply to | #130493 |
On 13/05/18 18:14, bartc wrote: > On 13/05/2018 15:57, David Brown wrote: >> On 12/05/18 18:45, bartc wrote: > >>> all with different attributes. >> >> Different tools for different purposes. > > None of which do exactly the job of simply attaching a scoped name to a > literal value, and nothing else. So what? That is not a feature I see any value in. For everything you would want to use /your/ constants for, C and C++ have a way to do it (with C++ making many of them more convenient). The only way to pretend that C cannot make the kind of constants you want is to invent artificial restrictions. > > enum is the closest if the type involved is an int, but even that is > intended for a different purpose. > >> So as far as I can see, you have everything you need in C and C++ >> constants. > > As far as I can see, I have to choose some combination of static, > register, const, enum or #define. I can choose to assign a value or not. const, enum and #define do different things - though for some purposes, you have a choice of which one to use. "static" is a type qualifier that appears to give you a lot of trouble. It is unfortunate that C (and C++) use it in a number of circumstances for somewhat different concepts, but I am sure you could learn what it means if you tried. You don't get to choose to assign a value or not - a constant always has a single definition with a single value. But you can (for "const") make declarations that are not a definition - this is a vital feature that seems to have escaped your understanding. > Some choices might allow &, some don't. Some may involve allocating > storage, others not, or it might depend on whether & is used. It may or > may not be exported. It turns out that people like variety. Maybe your programs are small enough, or simple enough that you don't need many features in a language. Maybe you are so used to a limited and restricted language that you make do with it, and it is good enough for you. Other people use real programming languages, and need a variety of tools and features. The various types of constants in C and C++ are not that hard to learn or use. The only advantage of trying to invent a "super constant" that does "everything" is for someone writing a compiler. Personally, I would rather have the different constant methods that do what I need and want, than to have a single method that does not do what I need. > > And if I use 'const double pi=3.1416;" in a shared header, then I am > likely to end up with multiple definitions of 'pi'. What is it that people keep saying to you? "Doctor, it hurts when I do this..." In C++, you can write "const double pi = 3.1416;" in a header and have it do what you want. In C, you cannot. It does not mean what you think it means. If you had learned how C linking, declarations and definitions work, and how multiple translation units work - instead of obsessing about how much you can put in /one/ file and avoid any build processes - you would know this. > > This must be the famous so-called flexibility of C in action. > > Seriously, can no one else see what a hopeless mess all this is? > I can't answer for everyone else, but it is easy to see why /you/ are in a hopeless mess whereas C and C++ programmers do fine. (That does not mean we don't see room for improvement - for starters, I think most people familiar with C and C++ would like C to inherit C++'s const features.) >> "enum" is mainly for defining groups of related constants - a feature >> that appears to be missing from your language. > > I have enums, but normally use the more sophisticated table-building > features. enums in C are not about tables - they are about types and identifiers. > > But when needing a stand-alone named constant, then my 'const' feature > does that job perfectly without any ifs and buts of the assortment of > features used in C. > > It is simple (an attribute that few appreciate in this group). Most constants in C are simple too. But for some uses, simple doesn't cut it. > >> The main complaints I have with constants in C is the same as most >> people's - and that could be fixed by copying the "const" features of >> C++. > > I've just spent 30 minutes adding 'constant' to my new C compiler. But > it's clear it will take much longer to do properly. Still, it > illustrates how it works, but with these limitations: > It is amazing what you can do when you don't have to think further than your own navel.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-13 12:35 -0700 |
| Message-ID | <c83cc38d-7884-43ba-938d-26991ca7e934@googlegroups.com> |
| In reply to | #130503 |
On Sunday, May 13, 2018 at 12:18:24 PM UTC-7, David Brown wrote: > On 13/05/18 18:14, bartc wrote: > > On 13/05/2018 15:57, David Brown wrote: > >> On 12/05/18 18:45, bartc wrote: > > > >>> all with different attributes. > >> > >> Different tools for different purposes. > > > > None of which do exactly the job of simply attaching a scoped name to a > > literal value, and nothing else. > > So what? That is not a feature I see any value in. For everything you > would want to use /your/ constants for, C and C++ have a way to do it > (with C++ making many of them more convenient). The only way to pretend > that C cannot make the kind of constants you want is to invent > artificial restrictions. > > > > > enum is the closest if the type involved is an int, but even that is > > intended for a different purpose. > > > >> So as far as I can see, you have everything you need in C and C++ > >> constants. > > > > As far as I can see, I have to choose some combination of static, > > register, const, enum or #define. I can choose to assign a value or not. > > const, enum and #define do different things - though for some purposes, > you have a choice of which one to use. "static" is a type qualifier > that appears to give you a lot of trouble. It is unfortunate that C > (and C++) use it in a number of circumstances for somewhat different > concepts, but I am sure you could learn what it means if you tried. > > You don't get to choose to assign a value or not - a constant always has > a single definition with a single value. But you can (for "const") make > declarations that are not a definition - this is a vital feature that > seems to have escaped your understanding. > > > Some choices might allow &, some don't. Some may involve allocating > > storage, others not, or it might depend on whether & is used. It may or > > may not be exported. > > It turns out that people like variety. Maybe your programs are small > enough, or simple enough that you don't need many features in a > language. Maybe you are so used to a limited and restricted language > that you make do with it, and it is good enough for you. Other people > use real programming languages, and need a variety of tools and features. > > The various types of constants in C and C++ are not that hard to learn > or use. The only advantage of trying to invent a "super constant" that > does "everything" is for someone writing a compiler. Personally, I > would rather have the different constant methods that do what I need and > want, than to have a single method that does not do what I need. > > > > > And if I use 'const double pi=3.1416;" in a shared header, then I am > > likely to end up with multiple definitions of 'pi'. > > What is it that people keep saying to you? "Doctor, it hurts when I do > this..." > > In C++, you can write "const double pi = 3.1416;" in a header and have > it do what you want. In C, you cannot. It does not mean what you think > it means. If you had learned how C linking, declarations and > definitions work, and how multiple translation units work - instead of > obsessing about how much you can put in /one/ file and avoid any build > processes - you would know this. > > > > > This must be the famous so-called flexibility of C in action. > > > > Seriously, can no one else see what a hopeless mess all this is? > > > > I can't answer for everyone else, but it is easy to see why /you/ are in > a hopeless mess whereas C and C++ programmers do fine. (That does not > mean we don't see room for improvement - for starters, I think most > people familiar with C and C++ would like C to inherit C++'s const > features.) > > >> "enum" is mainly for defining groups of related constants - a feature > >> that appears to be missing from your language. > > > > I have enums, but normally use the more sophisticated table-building > > features. > > enums in C are not about tables - they are about types and identifiers. > > > > > But when needing a stand-alone named constant, then my 'const' feature > > does that job perfectly without any ifs and buts of the assortment of > > features used in C. > > > > It is simple (an attribute that few appreciate in this group). > > Most constants in C are simple too. But for some uses, simple doesn't > cut it. > > > > >> The main complaints I have with constants in C is the same as most > >> people's - and that could be fixed by copying the "const" features of > >> C++. > > > > I've just spent 30 minutes adding 'constant' to my new C compiler. But > > it's clear it will take much longer to do properly. Still, it > > illustrates how it works, but with these limitations: > > > > It is amazing what you can do when you don't have to think further than > your own navel. Once Steve Carroll appreciated how convincing The Flying Spaghetti Monster is at playing 'target' he understands this isn't nearly as crazy as it was claimed. What did Steve Carroll expect from the lying imbecile? That The Flying Spaghetti Monster idiot has nothing to blow but time. He has nothing else, especially not a caring family. He lies that he uses Linux, while you know he never installed it on a modern device and honesty pushed it. -- I Left My Husband & Daughter At Home And THIS happened! http://www.5z8.info/killallimmigrants_t8w8io_asian-brides Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
Page 4 of 12 — ← Prev page 1 2 3 [4] 5 6 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web