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 8 of 12 — ← Prev page 1 … 6 7 [8] 9 10 … 12 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-13 21:59 +0200 |
| Message-ID | <pda5ef$nmh$1@dont-email.me> |
| In reply to | #130479 |
On 13/05/18 01:14, bartc wrote:
> On 12/05/2018 23:53, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>> [...]
>>> & works with a normal variable, because when you write:
>>>
>>> double x;
>>>
>>> then the type of 'x' - the name, not the contents of the location it
>>> refers to - is really double*. When used in an expression, it is
>>> automatically dereferenced to yield the contents of the location:
>>>
>>> *(&x); // equivalent to just x in a HLL
>>>
>>> When you write &x, then that is really this:
>>>
>>> &*(&x);
>>>
>>> The & and * cancel to leave you with &x, of type double*.
>>
>> "That's not how this works. That's not how any of this works."
>>
>> The object named `x` is of type double.
>
> I said the type of the name 'x', not the contents of the location it
> refers to. Suppose my 'double x' declaration was represented by this
> assembly sequence:
>
> x:
> resb 8 # reserve 8 bytes
>
> What would be the type, in C terms, of the address designated by label
> x? What would be the type, in C terms, of the contents of those 8 bytes
> it refers to?
>
Why would you think that "double x;" would always lead to an assembly
sequence such as that? It /might/ - but it might not. If the
declaration is local to a function, compilers will usually try to keep
it in a register or remove it altogether - failing that, it will go on
the stack. If it is a "const" (suiting this thread), it might get an
initialised area in the read-only initialised data section of the
program - but it might only ever be used directly (such as with a "load
immediate" instruction) if it is a "static const", or you are using C++,
or you are using whole-program optimisation, and you have not used its
address.
Even if you /do/ use the address of something, it does not mean it has
to be put in storage somewhere, and it certainly does not mean that a
pointer is created.
For example, consider this function:
uint32_t rev(uint32_t x) {
uint32_t a = x;
uint32_t b;
uint8_t *pa = (uint8_t*) &a;
uint8_t *pb = (uint8_t*) (&b + 1);
for (int i = 0; i < 4; i++) {
*--pb = *pa++;
}
return b;
}
Here we have two uint32_t variables, two pointer variables, an int
variable. We have pointers, addresses, treating a single variable as an
array in order to get a pointer to its end. gcc (admittedly with -O3,
as it involves a fair amount of analysis) implements this as:
rev:
mov eax, edi # x, x
bswap eax # x
ret
No storage, pointers, or anything else involved.
Going back to your "double x;" example, "&x" does /not/ "yield a double*
pointer". "&x" is an /expression/ of type "double * const". There is
no pointer.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-13 13:23 -0700 |
| Message-ID | <809cc995-ade5-4ad1-9d75-f12883a026a1@googlegroups.com> |
| In reply to | #130509 |
On Sunday, May 13, 2018 at 2:59:20 PM UTC-5, David Brown wrote:
> Even if you /do/ use the address of something, it does not mean it has
> to be put in storage somewhere, and it certainly does not mean that a
> pointer is created.
In some cases defined by the Standard, using the address of something
may yield to behavior being defined in cases where it otherwise wouldn't
be.
For example, given something like:
uint16_t volatile x;
uint16_t weird(int mode)
{
uint16_t a,b;
if (mode==0) a=x;
b=0;
((unsinged char*)&b)[0] = ((unsinged char*)&a)[0];
((unsinged char*)&b)[1] = ((unsinged char*)&a)[1];
return b;
}
Any time 'a' has a defined value, the two operations done using the
address of 'a' and 'b' will be equivalent to 'b=a'. A compiler that
optimizes such code in that fashion, however, would be required to
ensure that the value in 'b' gets clipped to the range 0-65535 even
if 'a' had been optimized to a register which was not in that range.
The Standard explicitly recognizes unsigned-character reads of storage
whose address has been taken as having defined behavior without regard
for whether the storage has been initialized. While a defect report
allows compilers to treat behavioral guarantees as very weak, I don't
think they leave room for the function above to do something other
than yield an Unspecified value 0-65535, with no side effects, when
"mode" is a non-zero value.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-13 22:05 +0100 |
| Message-ID | <yM1KC.305075$gE6.248707@fx06.am4> |
| In reply to | #130509 |
On 13/05/2018 20:59, David Brown wrote: > On 13/05/18 01:14, bartc wrote: >> x: >> resb 8 # reserve 8 bytes >> >> What would be the type, in C terms, of the address designated by label >> x? What would be the type, in C terms, of the contents of those 8 >> bytes it refers to? >> > > Why would you think that "double x;" would always lead to an assembly > sequence such as that? I said suppose it did, in a futile attempt to illustrate how a language might treat the difference between a CONST-like name and VAR-like name, to use Pascal terms. Futile because it is clear that most people involved in the discussion (not Thiago or supercat who seem to have open minds) are not interested in there being a difference. > No storage, pointers, or anything else involved. So a compiler might optimise out code so that constants, variables, functions and perhaps a bunch of other things might disappear from existence. What does that add to a discussion of the relations between constants and variables? It seems that you like to thrown gcc and its O2 and O3 behaviour into the ring every so often just to win some argument. This is like being able to prove anything in mathematics by making use of a term that incorporates a division by zero. > Going back to your "double x;" example, "&x" does /not/ "yield a double* > pointer". "&x" is an /expression/ of type "double * const". There is > no pointer. I see. So it would not be possible to dereference such a pointer via *(&x) because according to you, that pointer does not exist. I will bear that in mind. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-14 12:55 +0200 |
| Message-ID | <pdbpv2$jb3$1@dont-email.me> |
| In reply to | #130514 |
On 13/05/18 23:05, bartc wrote: > On 13/05/2018 20:59, David Brown wrote: >> On 13/05/18 01:14, bartc wrote: > >>> x: >>> resb 8 # reserve 8 bytes >>> >>> What would be the type, in C terms, of the address designated by >>> label x? What would be the type, in C terms, of the contents of those >>> 8 bytes it refers to? >>> >> >> Why would you think that "double x;" would always lead to an assembly >> sequence such as that? > > I said suppose it did, in a futile attempt to illustrate how a language > might treat the difference between a CONST-like name and VAR-like name, > to use Pascal terms. > > Futile because it is clear that most people involved in the discussion > (not Thiago or supercat who seem to have open minds) are not interested > in there being a difference. > >> No storage, pointers, or anything else involved. > > So a compiler might optimise out code so that constants, variables, > functions and perhaps a bunch of other things might disappear from > existence. Yes. > > What does that add to a discussion of the relations between constants > and variables? It seems that you like to thrown gcc and its O2 and O3 > behaviour into the ring every so often just to win some argument. The point is that trying to make a language concept where you can't take an address does not stop there being storage for the object, and conversely allowing the address to be taken does not force storage allocation for the object. Allowing the address to be taken does not make the constant vulnerable to being changed - you have to write deliberately bad or dangerous code to have any chance of having such an effect. Similarly, banning taking the address does not make the code invulnerable to problems - at most, it makes some problems harder to cause. Thus your justification for wanting to ban taking the address of constants is moot as far as I can see. > >> Going back to your "double x;" example, "&x" does /not/ "yield a >> double* pointer". "&x" is an /expression/ of type "double * const". >> There is no pointer. > > I see. So it would not be possible to dereference such a pointer via > *(&x) because according to you, that pointer does not exist. > > I will bear that in mind. > The unary * operator needs an operand of pointer /type/, not a pointer. It needs to be something that points somewhere - that is not the same thing as a pointer itself. &x is an expression of pointer type, but it is not a pointer. You cannot take its address, or increment it, or set its value. It is like "1 + 2" is an expression of int type, it is not an int.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-14 12:57 +0200 |
| Message-ID | <pdbq31$jb3$2@dont-email.me> |
| In reply to | #130535 |
On 14/05/18 12:55, David Brown wrote: > On 13/05/18 23:05, bartc wrote: >> On 13/05/2018 20:59, David Brown wrote: >>> On 13/05/18 01:14, bartc wrote: <snip> >> >>> Going back to your "double x;" example, "&x" does /not/ "yield a >>> double* pointer". "&x" is an /expression/ of type "double * const". >>> There is no pointer. >> >> I see. So it would not be possible to dereference such a pointer via >> *(&x) because according to you, that pointer does not exist. >> >> I will bear that in mind. >> > > The unary * operator needs an operand of pointer /type/, not a pointer. > It needs to be something that points somewhere - that is not the same > thing as a pointer itself. &x is an expression of pointer type, but it > is not a pointer. You cannot take its address, or increment it, or set > its value. It is like "1 + 2" is an expression of int type, it is not > an int. > Look at Keith's next post - it is is clearer and more accurate than mine, and better expresses what I have been trying to say. I should have read it before writing this one.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-14 10:57 -0700 |
| Message-ID | <ln8t8m86ht.fsf@kst-u.example.com> |
| In reply to | #130535 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> The unary * operator needs an operand of pointer /type/, not a pointer.
> It needs to be something that points somewhere - that is not the same
> thing as a pointer itself. &x is an expression of pointer type, but it
> is not a pointer. You cannot take its address, or increment it, or set
> its value. It is like "1 + 2" is an expression of int type, it is not
> an int.
What you mean is that it is not a pointer *object*.
The standard itself sometimes uses the unqualified term "pointer" to
refer to a pointer value that is not the value of any pointer object.
See, for example, the definition of malloc(): "The malloc function
returns either a null pointer or a pointer to the allocated space."
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-15 09:14 +0200 |
| Message-ID | <pde1de$uv2$1@dont-email.me> |
| In reply to | #130563 |
On 14/05/18 19:57, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> The unary * operator needs an operand of pointer /type/, not a pointer. >> It needs to be something that points somewhere - that is not the same >> thing as a pointer itself. &x is an expression of pointer type, but it >> is not a pointer. You cannot take its address, or increment it, or set >> its value. It is like "1 + 2" is an expression of int type, it is not >> an int. > > What you mean is that it is not a pointer *object*. Yes, that is exactly what I meant. (Or if it wasn't what I meant, I'm going to pretend it was - as it is what I should have meant :-) ). Thanks for the correction and clarification here. > > The standard itself sometimes uses the unqualified term "pointer" to > refer to a pointer value that is not the value of any pointer object. > See, for example, the definition of malloc(): "The malloc function > returns either a null pointer or a pointer to the allocated space." >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-13 14:10 -0700 |
| Message-ID | <lnvabr8dog.fsf@kst-u.example.com> |
| In reply to | #130509 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> Going back to your "double x;" example, "&x" does /not/ "yield a double*
> pointer".
I'm not sure what you're trying to say, but yes, it does. More
precisely, evaluating the expression `&x` yields a value of type
`double*`.
> "&x" is an /expression/ of type "double * const". There is
> no pointer.
There is no const. &x is of type double*, which is a pointer type. (&x
is not an lvalue, so of course its value can't be modified, but "const"
isn't used that way).
I think the point you're making is that given
double x;
there is no pointer *object*. Evaluating `&x` does yield a pointer
*value*. (Using pointer as a noun rather than as an adjective can lead
to a lot of confusion.)
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-13 17:31 +0200 |
| Message-ID | <pd9lp9$a9v$1@dont-email.me> |
| In reply to | #130474 |
On 12/05/18 23:48, bartc wrote:
> On 12/05/2018 21:32, Ian Collins wrote:
>> On 05/12/2018 11:41 AM, Thiago Adams wrote:
>>>
>>> The feature to define PI should not define a variable, but
>>> a named literal or compound literal.
>>> I cannot take the address of &3.14 why I would like to
>>> take the address of pi?
>>
>>
>> constexpr double pi =
>> 3.14159265358979323846264338327950288419716939937511;
>> constexpr double e =
>> 2.71828182845904523536028747135266249775724709369995;
>> constexpr double constants[] = {pi,e};
>>
>> void f( const double* values, size_t count )
>> {
>> for( size_t n = 0; n < count; ++n )
>> {
>> printf( "%f\n", values[n] );
>> }
>> }
>>
>> int main()
>> {
>> f( constants, 2 );
>> f( &pi, 1 );
>> }
>
> > People do "get it", they just don't see the need for it.
>
> I doubt it. I want a named literal that can be used in exactly the same
> as a raw literal. And that includes not being able to apply & to it.
Let's split this up. People "get it" in the sense that we all
understand that you want literals whose address cannot be taken. What
we all (or at least, so it appears to me) don't get is /why/ that would
be an advantage. I cannot comprehend why you might see the inability to
take the address of something to be an advantage.
>
> (And in your example, I was able to write a function to change the value
> of pi, but it only failed at runtime because pi must have been stored in
> read-only memory.)
No, you were not able to write a function to change the value of pi.
You were able to write a function that told the compiler "believe me, I
/know/ what I am doing, and I am writing this odd code that is
syntactically correct even though it is semantically meaningless". C
and C++ are both languages that trust the programmer to a large extent,
and let you write and compile that code. As you noted from trying to
run it, you totally failed to write a function that changed pi.
The language /allows/ you to make a non-const pointer to const data.
This is useful if you want to pass the pointer around, such as to
functions that read the data but take non-const pointers. The language
does not allow you to modify the const data through such a pointer.
For example, you may have a function declared :
void displayDouble(double * x);
In C and C++, you could write:
displayDouble((double *) &pi);
If "displayDouble" tries to modify the object point at, it is undefined
behaviour. And certainly would have been better to add the "const" in
the declaration of displayDouble. But you don't always have full
control of the code you are working with.
>
> & works with a normal variable, because when you write:
>
> double x;
>
> then the type of 'x' - the name, not the contents of the location it
> refers to - is really double*. When used in an expression, it is
> automatically dereferenced to yield the contents of the location:
>
> *(&x); // equivalent to just x in a HLL
>
> When you write &x, then that is really this:
>
> &*(&x);
>
> The & and * cancel to leave you with &x, of type double*.
>
> If you can apply & to pi to also yield a double*, it means that pi and x
> are of the same rank - both variables with the same level of indirection
> to get to their value.
>
> Being able to use & willy-nilly on both variables and objects which are
> supposed to be just named constants shows disregard for the type system.
>
It shows regard for the programmer, not disregard for typing. (Note
that neither C nor C++ is as strongly typed as some other languages.
Strong typing is associated with safety, but also with inflexibility.)
> Either that, or a complex set of rules are in force where sometimes pi
> is used as though it's stored in a memory location, sometimes it can be
> an immediate value, or maybe sometimes a memory location is synthesised
> to contain a copy of the value as needed.
>
> This why I think few people 'get it'; they certainly don't get the need
> for an ultra-simple feature with straightforward rules.
>
We have heard lots of moans from you about C and C++ constants, and lots
of claims about what people "need" - and some your "straightforward
rules". But I haven't seen any reasoning behind them, justification for
them, or basis for claiming that we "need" them.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-05-14 10:19 -0700 |
| Message-ID | <f4fa083c-243e-44eb-8373-ed72171da862@googlegroups.com> |
| In reply to | #130468 |
On Saturday, May 12, 2018 at 5:32:58 PM UTC-3, Ian Collins wrote:
> On 05/12/2018 11:41 AM, Thiago Adams wrote:
> >
> > The feature to define PI should not define a variable, but
> > a named literal or compound literal.
> > I cannot take the address of &3.14 why I would like to
> > take the address of pi?
>
>
> constexpr double pi = 3.14159265358979323846264338327950288419716939937511;
> constexpr double e = 2.71828182845904523536028747135266249775724709369995;
> constexpr double constants[] = {pi,e};
>
> void f( const double* values, size_t count )
> {
> for( size_t n = 0; n < count; ++n )
> {
> printf( "%f\n", values[n] );
> }
> }
>
> int main()
> {
> f( constants, 2 );
> f( &pi, 1 );
> }
I didn't see the utility of your sample.
Just to clarify, from my perceptive, the problem is not only
take the address but is not have a precise and explicit control
about storage.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-05-15 08:06 +1200 |
| Message-ID | <flu8hnF3h2kU1@mid.individual.net> |
| In reply to | #130560 |
On 15/05/18 05:19, Thiago Adams wrote:
> On Saturday, May 12, 2018 at 5:32:58 PM UTC-3, Ian Collins wrote:
>> On 05/12/2018 11:41 AM, Thiago Adams wrote:
>>>
>>> The feature to define PI should not define a variable, but
>>> a named literal or compound literal.
>>> I cannot take the address of &3.14 why I would like to
>>> take the address of pi?
>>
>>
>> constexpr double pi = 3.14159265358979323846264338327950288419716939937511;
>> constexpr double e = 2.71828182845904523536028747135266249775724709369995;
>> constexpr double constants[] = {pi,e};
>>
>> void f( const double* values, size_t count )
>> {
>> for( size_t n = 0; n < count; ++n )
>> {
>> printf( "%f\n", values[n] );
>> }
>> }
>>
>> int main()
>> {
>> f( constants, 2 );
>> f( &pi, 1 );
>> }
>
> I didn't see the utility of your sample.
You can't see the utility of being able to use something?
> Just to clarify, from my perceptive, the problem is not only
> take the address but is not have a precise and explicit control
> about storage.
I'm not sure what you are trying to say here.
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-05-14 13:20 -0700 |
| Message-ID | <bfdcca8e-5d96-4d93-9565-d30e24297f55@googlegroups.com> |
| In reply to | #130573 |
On Monday, May 14, 2018 at 5:06:26 PM UTC-3, Ian Collins wrote:
> On 15/05/18 05:19, Thiago Adams wrote:
> > On Saturday, May 12, 2018 at 5:32:58 PM UTC-3, Ian Collins wrote:
> >> On 05/12/2018 11:41 AM, Thiago Adams wrote:
> >>>
> >>> The feature to define PI should not define a variable, but
> >>> a named literal or compound literal.
> >>> I cannot take the address of &3.14 why I would like to
> >>> take the address of pi?
> >>
> >>
> >> constexpr double pi = 3.14159265358979323846264338327950288419716939937511;
> >> constexpr double e = 2.71828182845904523536028747135266249775724709369995;
> >> constexpr double constants[] = {pi,e};
> >>
> >> void f( const double* values, size_t count )
> >> {
> >> for( size_t n = 0; n < count; ++n )
> >> {
> >> printf( "%f\n", values[n] );
> >> }
> >> }
> >>
> >> int main()
> >> {
> >> f( constants, 2 );
> >> f( &pi, 1 );
> >> }
> >
> > I didn't see the utility of your sample.
>
> You can't see the utility of being able to use something?
I don't see in this case, a usage to take the address of PI.
PI is not a variable. If I need a variable then I can declare
a variable, or something with storage and constant and set PI.
A variable has type and some size. PI doesn't.
#define PI 3.14
const double DoublePiVar = PI;
const float FloatPiVar = PI;
> > Just to clarify, from my perceptive, the problem is not only
> > take the address but is not have a precise and explicit control
> > about storage.
>
> I'm not sure what you are trying to say here.
I don't want to leave the storage decision
(if the constant use memory or not ) for the compiler
or affect by my colleague checkin.
I prefer to be sure that the value is not using memory.
Particularity I don't feel conformable with the idea.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-14 13:46 -0700 |
| Message-ID | <ln4lja7ypi.fsf@kst-u.example.com> |
| In reply to | #130575 |
Thiago Adams <thiago.adams@gmail.com> writes:
[...]
> I don't see in this case, a usage to take the address of PI.
> PI is not a variable. If I need a variable then I can declare
> a variable, or something with storage and constant and set PI.
>
> A variable has type and some size. PI doesn't.
>
> #define PI 3.14
> const double DoublePiVar = PI;
> const float FloatPiVar = PI;
>
>
>
>
>> > Just to clarify, from my perceptive, the problem is not only
>> > take the address but is not have a precise and explicit control
>> > about storage.
>>
>> I'm not sure what you are trying to say here.
>
> I don't want to leave the storage decision
> (if the constant use memory or not ) for the compiler
> or affect by my colleague checkin.
> I prefer to be sure that the value is not using memory.
> Particularity I don't feel conformable with the idea.
PI (more precisely, the result of expanding the macro PI) does have a
type and a size. Its type is double (like any unsuffixed floating-point
constant), and its size is sizeof (double).
`sizeof PI` and `sizeof 3.14` are both likely to yield 8 under typical
implementations.
That type and size information is discarded when the value is converted
as it is in the initializations of DoublePiVar and FloatPiVar.
I agree that there's no great benefit in being able to evaluate &PI.
--
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-14 14:12 -0700 |
| Message-ID | <0b469345-76d9-4ef4-b16f-6f2941b99d5e@googlegroups.com> |
| In reply to | #130576 |
On Monday, May 14, 2018 at 5:46:11 PM UTC-3, Keith Thompson wrote: > Thiago Adams <thiago.adams@gmail.com> writes: > [...] > > I don't see in this case, a usage to take the address of PI. > > PI is not a variable. If I need a variable then I can declare > > a variable, or something with storage and constant and set PI. > > > > A variable has type and some size. PI doesn't. > > > > #define PI 3.14 > > const double DoublePiVar = PI; > > const float FloatPiVar = PI; > > > > > > > > > >> > Just to clarify, from my perceptive, the problem is not only > >> > take the address but is not have a precise and explicit control > >> > about storage. > >> > >> I'm not sure what you are trying to say here. > > > > I don't want to leave the storage decision > > (if the constant use memory or not ) for the compiler > > or affect by my colleague checkin. > > I prefer to be sure that the value is not using memory. > > Particularity I don't feel conformable with the idea. > > PI (more precisely, the result of expanding the macro PI) does have a > type and a size. Its type is double (like any unsuffixed floating-point > constant), and its size is sizeof (double). > > `sizeof PI` and `sizeof 3.14` are both likely to yield 8 under typical > implementations. Sure, literals have some rules and size. Actually I was thinking that PI doesn't have size and compiler could use bigints or 128 doubles etc.. But also in this case what happens must be well defined and compiler emit the same code. (I will try in some compiler what happens with int overflow for enuns for instance. Some expression can overflow and then returns for the int range. )
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-14 14:27 -0700 |
| Message-ID | <lnzi126i7x.fsf@kst-u.example.com> |
| In reply to | #130578 |
Thiago Adams <thiago.adams@gmail.com> writes:
> On Monday, May 14, 2018 at 5:46:11 PM UTC-3, Keith Thompson wrote:
>> Thiago Adams <thiago.adams@gmail.com> writes:
>> [...]
>> > I don't see in this case, a usage to take the address of PI.
>> > PI is not a variable. If I need a variable then I can declare
>> > a variable, or something with storage and constant and set PI.
>> >
>> > A variable has type and some size. PI doesn't.
>> >
>> > #define PI 3.14
>> > const double DoublePiVar = PI;
>> > const float FloatPiVar = PI;
>> >
>> >
>> >
>> >
>> >> > Just to clarify, from my perceptive, the problem is not only
>> >> > take the address but is not have a precise and explicit control
>> >> > about storage.
>> >>
>> >> I'm not sure what you are trying to say here.
>> >
>> > I don't want to leave the storage decision
>> > (if the constant use memory or not ) for the compiler
>> > or affect by my colleague checkin.
>> > I prefer to be sure that the value is not using memory.
>> > Particularity I don't feel conformable with the idea.
>>
>> PI (more precisely, the result of expanding the macro PI) does have a
>> type and a size. Its type is double (like any unsuffixed floating-point
>> constant), and its size is sizeof (double).
>>
>> `sizeof PI` and `sizeof 3.14` are both likely to yield 8 under typical
>> implementations.
>
> Sure, literals have some rules and size.
> Actually I was thinking that PI doesn't have size and compiler
> could use bigints or 128 doubles etc..
No, 3.14 is of type double. Consider this program:
#include <stdio.h>
int main(void) {
#define PI_D 3.14
#define PI_LD 3.14L
long double pi_d = PI_D;
long double pi_ld = PI_LD;
printf("pi_d = %.64Lf\n", pi_d);
printf("pi_ld = %.64Lf\n", pi_ld);
}
and its output on my system:
pi_d = 3.1400000000000001243449787580175325274467468261718750000000000000
pi_ld = 3.1400000000000000000954097911787243901926558464765548706054687500
The compiler can't treat PI_D as having more precision than type double.
> (I will try in some compiler what happens with int overflow
> for enuns for instance. Some expression can overflow and then
> returns for the int range.
> )
Specifying a value outside the range of int for an enumerator is a
constraint violation (N1570 6.7.2.2p2).
There's a loophole for an implicit value outside the range of int, which
the standard doesn't say is a constraint violation, but at least some
compilers treat it as one anyway. Example:
enum { foo=INT_MAX, bar };
gcc 7.3.0 treats this as a fatal error, clang warns and sets bar to
INT_MIN, and tcc quietly sets bar to INT_MIN.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-14 15:21 -0700 |
| Message-ID | <8a2ecdb1-cde4-45dc-a0b9-c641b3028079@googlegroups.com> |
| In reply to | #130579 |
On Monday, May 14, 2018 at 4:27:38 PM UTC-5, Keith Thompson wrote:
> No, 3.14 is of type double. Consider this program:
>
> #include <stdio.h>
> int main(void) {
> #define PI_D 3.14
> #define PI_LD 3.14L
> long double pi_d = PI_D;
> long double pi_ld = PI_LD;
> printf("pi_d = %.64Lf\n", pi_d);
> printf("pi_ld = %.64Lf\n", pi_ld);
> }
>
> and its output on my system:
>
> pi_d = 3.1400000000000001243449787580175325274467468261718750000000000000
> pi_ld = 3.1400000000000000000954097911787243901926558464765548706054687500
>
> The compiler can't treat PI_D as having more precision than type double.
That would depend upon whether/how it defines FLT_EVAL_METHOD. If it defines
that as 2, it would be not only allowed but required to evaluate floating-
point literals and expressions using the "long double" type and only round
floating-point values to fit smaller types when values are actually stored
into objects of those types. If it defines it as -1, such behavior would
not be required, but would still be allowable.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-14 15:24 -0700 |
| Message-ID | <5f800d3a-1bef-4f34-98dd-4b5e8954a77b@googlegroups.com> |
| In reply to | #130579 |
On Monday, May 14, 2018 at 2:27:38 PM UTC-7, Keith Thompson wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
> > On Monday, May 14, 2018 at 5:46:11 PM UTC-3, Keith Thompson wrote:
> >> Thiago Adams <thiago.adams@gmail.com> writes:
> >> [...]
> >> > I don't see in this case, a usage to take the address of PI.
> >> > PI is not a variable. If I need a variable then I can declare
> >> > a variable, or something with storage and constant and set PI.
> >> >
> >> > A variable has type and some size. PI doesn't.
> >> >
> >> > #define PI 3.14
> >> > const double DoublePiVar = PI;
> >> > const float FloatPiVar = PI;
> >> >
> >> >
> >> >
> >> >
> >> >> > Just to clarify, from my perceptive, the problem is not only
> >> >> > take the address but is not have a precise and explicit control
> >> >> > about storage.
> >> >>
> >> >> I'm not sure what you are trying to say here.
> >> >
> >> > I don't want to leave the storage decision
> >> > (if the constant use memory or not ) for the compiler
> >> > or affect by my colleague checkin.
> >> > I prefer to be sure that the value is not using memory.
> >> > Particularity I don't feel conformable with the idea.
> >>
> >> PI (more precisely, the result of expanding the macro PI) does have a
> >> type and a size. Its type is double (like any unsuffixed floating-point
> >> constant), and its size is sizeof (double).
> >>
> >> `sizeof PI` and `sizeof 3.14` are both likely to yield 8 under typical
> >> implementations.
> >
> > Sure, literals have some rules and size.
> > Actually I was thinking that PI doesn't have size and compiler
> > could use bigints or 128 doubles etc..
>
> No, 3.14 is of type double. Consider this program:
>
> #include <stdio.h>
> int main(void) {
> #define PI_D 3.14
> #define PI_LD 3.14L
> long double pi_d = PI_D;
> long double pi_ld = PI_LD;
> printf("pi_d = %.64Lf\n", pi_d);
> printf("pi_ld = %.64Lf\n", pi_ld);
> }
>
> and its output on my system:
>
> pi_d = 3.1400000000000001243449787580175325274467468261718750000000000000
> pi_ld = 3.1400000000000000000954097911787243901926558464765548706054687500
>
> The compiler can't treat PI_D as having more precision than type double.
>
> > (I will try in some compiler what happens with int overflow
> > for enuns for instance. Some expression can overflow and then
> > returns for the int range.
> > )
>
> Specifying a value outside the range of int for an enumerator is a
> constraint violation (N1570 6.7.2.2p2).
>
> There's a loophole for an implicit value outside the range of int, which
> the standard doesn't say is a constraint violation, but at least some
> compilers treat it as one anyway. Example:
>
> enum { foo=INT_MAX, bar };
>
> gcc 7.3.0 treats this as a fatal error, clang warns and sets bar to
> INT_MIN, and tcc quietly sets bar to INT_MIN.
>
> --
> 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"
And what did Allah have to say about this long list of "convenient friends" who popped up at just the right moment? Most of the time he would try to push the reader to believe they're "honest and honorable" posters who just happened to have great timing. Utterly impossible.
I am not going to play like Jesus didn't save my skin with this crap and I am thankful for his advice. Allah has Jesus to study and could learn to appear like he knows something about it from here on out. Having to suffer the use of Slrn is not what most want to do.
--
My Snoring Solution
http://www.5z8.info/trojan_p4g1zy_how-to-skin-a-gerbil
https://youtu.be/OffkiSAsYo8
https://www.facebook.com/jenny.eklund
Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-15 09:26 +0200 |
| Message-ID | <pde22q$30t$1@dont-email.me> |
| In reply to | #130576 |
On 14/05/18 22:46, Keith Thompson wrote: > Thiago Adams <thiago.adams@gmail.com> writes: > [...] >> I don't see in this case, a usage to take the address of PI. >> PI is not a variable. If I need a variable then I can declare >> a variable, or something with storage and constant and set PI. >> >> A variable has type and some size. PI doesn't. >> >> #define PI 3.14 >> const double DoublePiVar = PI; >> const float FloatPiVar = PI; >> >> >> >> >>>> Just to clarify, from my perceptive, the problem is not only >>>> take the address but is not have a precise and explicit control >>>> about storage. >>> >>> I'm not sure what you are trying to say here. >> >> I don't want to leave the storage decision >> (if the constant use memory or not ) for the compiler >> or affect by my colleague checkin. >> I prefer to be sure that the value is not using memory. >> Particularity I don't feel conformable with the idea. That is not something you have direct control over in C. A compiler can put literals or #define'd values in memory - conversely, it can avoid memory storage for const objects. All you get is that the object code will act as though the compiler followed your source code slavishly, to the extend that the behaviour is visible via defined behaviour in the code. Exactly how this is achieved, and what is placed where, is up to the implementation. If you want direct micro-management over such storage decisions, C is not the language you want. (Or at least, C using common off-the-shelf compilers is not what you want - an implementation /can/ give you more control.) > > PI (more precisely, the result of expanding the macro PI) does have a > type and a size. Its type is double (like any unsuffixed floating-point > constant), and its size is sizeof (double). > > `sizeof PI` and `sizeof 3.14` are both likely to yield 8 under typical > implementations. > > That type and size information is discarded when the value is converted > as it is in the initializations of DoublePiVar and FloatPiVar. > > I agree that there's no great benefit in being able to evaluate &PI. > I also don't see a big benefit in being able to evaluate &PI - but there might occasionally be use in passing such fixed values by reference. It would make a bigger difference if the type were of bigger size, enough to make pass-by-reference more efficient. But what I really don't see is any benefit in /not/ being able to evaluate &PI. (I see a benefit in language or compiler protections against abusing that &PI pointer.)
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-15 11:28 +0100 |
| Message-ID | <aDyKC.150182$tw.20166@fx42.am4> |
| In reply to | #130589 |
On 15/05/2018 08:26, David Brown wrote: > On 14/05/18 22:46, Keith Thompson wrote: >> Thiago Adams <thiago.adams@gmail.com> writes: >>> I don't want to leave the storage decision >>> (if the constant use memory or not ) for the compiler >>> or affect by my colleague checkin. >>> I prefer to be sure that the value is not using memory. >>> Particularity I don't feel conformable with the idea. > > That is not something you have direct control over in C. It can be enough that the abstract execution model for the language states whether it uses notional 'storage' or doesn't. Then what the compiler may or may not do is irrelevant. >> I agree that there's no great benefit in being able to evaluate &PI. > But what I really don't see is any benefit in /not/ being able to > evaluate &PI. The benefit is consistency with every other case where you can't use &: results of operations, results of functions, integer literals, float literals**, and enum names. In all cases where there no named storage location to which it can sensibly apply. The only reason to object to not allowing &PI seems to be to be able to piss on any proposals which similarly forbid it. Just because no proposals are ever going to match C++'s constexpr and this is one way to ensure they can't! (And, AIUI, you can apply & to any of those values by wrapping a compound literal around it, if you really wanted &.) (** There is an odd exception in being able to apply & to string literals, although &"abc" and "abc" do the same thing. "abc" already results in the address of a location where "abc" is stored, an address which doesn't itself have any location, so that & of that address is meaningless. But it works because & is applied before that address is derived.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-15 13:18 +0200 |
| Message-ID | <pdefle$mpi$1@dont-email.me> |
| In reply to | #130591 |
On 15/05/18 12:28, bartc wrote: > On 15/05/2018 08:26, David Brown wrote: >> On 14/05/18 22:46, Keith Thompson wrote: >>> Thiago Adams <thiago.adams@gmail.com> writes: > >>>> I don't want to leave the storage decision >>>> (if the constant use memory or not ) for the compiler >>>> or affect by my colleague checkin. >>>> I prefer to be sure that the value is not using memory. >>>> Particularity I don't feel conformable with the idea. >> >> That is not something you have direct control over in C. > > It can be enough that the abstract execution model for the language > states whether it uses notional 'storage' or doesn't. Then what the > compiler may or may not do is irrelevant. > I agree that what the compiler may or may not do is irrelevant. It is precisely because of that, that you cannot directly control whether you have storage or not (or multiple storage). And since you cannot have direct control of it, there is no point in pretending you have a sort-of control that sort-of works. >>> I agree that there's no great benefit in being able to evaluate &PI. > >> But what I really don't see is any benefit in /not/ being able to >> evaluate &PI. > > The benefit is consistency with every other case where you can't use &: > results of operations, results of functions, integer literals, float > literals**, and enum names. In all cases where there no named storage > location to which it can sensibly apply. Why should you specifically want to be consistent with these? Consistency is a good thing when it matters, but not in itself. Sometimes I want my "non-variable things" (I am trying to avoid "constant" because, as has been pointed out, this is a specific term in the C standards) to be addressable. Such uses would be rare, but not unknown. So a general concept for these /has/ to be addressable for me. (With compiler optimisations keeping everything efficient.) (And again, let me stress that I would like language and/or compiler restrictions and warnings if you try to abuse the address to pretend to change the non-variable thing.) > > The only reason to object to not allowing &PI seems to be to be able to > piss on any proposals which similarly forbid it. Not at all. I object to not allowing &PI because I want to allow &PI. It is /that/ simple. I also object to what I see as an arbitrary restriction on such new non-variable things. Restrictions can be good if they prevent mistakes, or if they allow optimisations that could not be achieved otherwise. We already know that the optimisations are not an issue - compilers treat "static const" objects, whose address can be taken, with the same efficiency as literals and C constants. And mistakes can be prevented to a large extent by warnings or errors when trying to cast pointer-to-const to pointer-to-non-const - or simply by not intentionally writing code that has such errors (as you have to do it intentionally and explicitly). If there is to be a point in having a new, generalised non-variable thing that replaces much of the need of #define, const, enum, etc., then it has to be /better/ than them. It has to be able to do all the things that these can do, and do them more efficiently, more simply, more correctly (i.e., less risk of mistakes). If you can't take the address of the new thing, it can't replace many uses of const objects. It already fails to replace many of the uses of #define and enum. It becomes - at best - yet another type of non-variable thingy in C and C++, adding to the complexity rather than reducing it.
[toc] | [prev] | [next] | [standalone]
Page 8 of 12 — ← Prev page 1 … 6 7 [8] 9 10 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web