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 5 of 12 — ← Prev page 1 … 3 4 [5] 6 7 … 12 Next page →
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-13 21:22 +0100 |
| Message-ID | <P71KC.281716$6D.185003@fx19.am4> |
| In reply to | #130503 |
On 13/05/2018 20:18, 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. This is patently obvious. My feature for named constant values is simple, safe, easy to implement, easy to understand, and ticks all the boxes. But you don't like it and prefer using your array of assorted C features none of which do everything mine does and as simply. And you resort to dragging in the heavyweight constexpr feature from C++ to tick a few extra boxes (except the one of simplicity). >> 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 static should have nothing whatever to do with named constants. const controls write access to data in memory and should also have nothing whatever to do with named constants. #define just creates macros and is the traditional stone-age method that C uses to name literal values, but it is dumb feature that knows nothing whatever about named constants. So that if you wrote: #define N = 2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2 then used N in a 1000 places in the code, it would parse, analyse and reduce that long expression 1000 times. > 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. We're talking about named constants. One feature, not half a dozen. > 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. Real or not, my language has a named constant feature, and C doesn't, not matter how much you try to pretend it doesn't matter because real programmers know to how to use const and static and register to get something that looks like a named constant, but isn't really. >> 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..." The fact is that it happens when you use const for that purpose. It doesn't happen with my constant feature for C, nor with the const feature in my language (which anyway doesn't need anything so crude as a header to be created - you just write 'global const') > 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. I've written linkers; I might know something about it. >> 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. You are determined not to be impressed and to denigrate everything I do, aren't you?! -- bartc
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2018-05-14 00:49 -0700 |
| Message-ID | <1680cac7-b746-4328-9415-b93afe001dc3@googlegroups.com> |
| In reply to | #130512 |
On Sunday, 13 May 2018 21:22:15 UTC+1, Bart wrote: > You are determined not to be impressed and to denigrate everything I do, > aren't you?! What's sauce for the goose...
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-14 01:05 -0700 |
| Message-ID | <ff0ee0b9-d4c0-45d7-bafd-c2ec05de3326@googlegroups.com> |
| In reply to | #130526 |
On Monday, May 14, 2018 at 12:49:31 AM UTC-7, mark.b...@gmail.com wrote: > On Sunday, 13 May 2018 21:22:15 UTC+1, Bart wrote: > > > You are determined not to be impressed and to denigrate everything I do, > > aren't you?! > > What's sauce for the goose... Now benj on the other end of the line doesn't matter. All that matters is Ant gets to deliver the punchline. So how to win? Don't pay attention the nonsense. Honest discussion isn't part of the plan and never was. That's what Ant does when he gets humiliated. He immediately creates a sock, starts a cross posted thread so he can claim here made a mistake. Don't blame me it was my left hand... and then he responds to it with his right hand. Right, Ant is trying to market an API variable, which benj can get for free, that I taught myself. If he could stop being so screwed up he would understand how slow he looks. Why does Ant focus on benj's ego so much? - Eight things to never feed your cat https://youtu.be/VxLiH-x0aeY Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-14 10:14 +0200 |
| Message-ID | <pdbgha$ln5$1@dont-email.me> |
| In reply to | #130512 |
On 13/05/18 22:22, bartc wrote:
> On 13/05/2018 20:18, 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.
>
> This is patently obvious.
>
> My feature for named constant values is simple, safe, easy to implement,
> easy to understand, and ticks all the boxes.
>
> But you don't like it and prefer using your array of assorted C features
> none of which do everything mine does and as simply. And you resort to
> dragging in the heavyweight constexpr feature from C++ to tick a few
> extra boxes (except the one of simplicity).
constexpr is a marvellous idea that opens up a range of possibilities in
C++. It took a few versions of C++ to get settled, but lets you do lots
more at compile time (its main point is for functions rather than const
objects). I have many C programs that could be made simpler and more
efficient with constexpr, and more where the build process would be
simpler and more efficient.
It is C++ "const" that I think is particularly useful, and a good deal
better than C "const".
Note that it is not your particular type of constant that I don't like.
I'm sure it is fine. If it were added to C, I'd probably use it sometimes.
It is the idea of "one size fits all" that I think is wrong, the idea
that constants in C (and in particular, C++) can't do what programmers
need, the idea that "simple is always best", and the idea that
artificial restrictions are helpful or realistic (and, even more
bizarrely, the idea that artificial restrictions are good in a
one-size-fits-all solution).
And on top of all this, your complaints about C constants are heavily
coloured by your misunderstandings about C.
>
>>> 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
>
> static should have nothing whatever to do with named constants.
Of course "static" has a role to play with named constants. "static"
affects linkage - sometimes you want constants that are defined in one
translation unit but available from others, and sometimes you want them
contained entirely within a single translation unit.
>
> const controls write access to data in memory and should also have
> nothing whatever to do with named constants.
Like many keywords in C and C++ ("static" being a prime example),
"const" has several related but not identical meanings. I will happily
agree that this is not always a helpful thing, and can be confusing for
people learning C (and occasionally also for those with long experience).
>
> #define just creates macros and is the traditional stone-age method that
> C uses to name literal values, but it is dumb feature that knows nothing
> whatever about named constants. So that if you wrote:
>
> #define N = 2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2*2
>
> then used N in a 1000 places in the code, it would parse, analyse and
> reduce that long expression 1000 times.
Yes. Fortunately, computers are /really/ good at doing simple things
thousands of times, and so it does not matter.
Because #define works at the preprocessor level, its macros have a great
deal of flexibility beyond what could be achieved by constructs that are
part of the "real" language and follow real scopes, declarations, etc.
That can be a good thing or a bad thing - thus it is a good tool to have
in C, but equally good that it is not the only tool.
>
>> 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.
>
> We're talking about named constants. One feature, not half a dozen.
You listed half a dozen features for your constants.
>
>> 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.
>
> Real or not, my language has a named constant feature, and C doesn't,
> not matter how much you try to pretend it doesn't matter because real
> programmers know to how to use const and static and register to get
> something that looks like a named constant, but isn't really.
>
>>> 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..."
>
> The fact is that it happens when you use const for that purpose.
No, it does /not/ happen - not if you know how to program in C. You
don't put non-static object or function definitions in shared headers.
It is /that/ simple.
> It
> doesn't happen with my constant feature for C, nor with the const
> feature in my language (which anyway doesn't need anything so crude as a
> header to be created - you just write 'global const')
>
>> 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.
>
> I've written linkers; I might know something about it.
You have also written a C compiler. One might be forgiven for expecting
you to understand this. Oddly, however, you apparently don't understand
C linkage.
>
>>> 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.
>
> You are determined not to be impressed and to denigrate everything I do,
> aren't you?!
>
The point is that when you are thinking about your own needs, your own
programs, your own preferences for writing these programs, your own
programming language, your own tools for these languages - then it is
/easy/ to come up with ideas that /you/ see as useful, and it is easy to
implement them in a way that works fine for /you/.
When trying to come up with a feature that satisfies a huge range of
programmers, can be implemented in a huge range of tools, does not
unnecessarily affect a huge range of existing code, will be useful in a
huge range of new code (to be worth the effort), will play nicely with
the existing language and not unduly affect future language changes -
/that/ involves a /little/ bit more effort.
As I have said before, I am sure your languages are great for /you/.
And it is no mean achievement to write your own language and tools. But
that does /not/ mean you are smarter than the rest of the programming
language world put together.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-14 11:43 +0100 |
| Message-ID | <JLdKC.178498$Z64.150484@fx36.am4> |
| In reply to | #130529 |
On 14/05/2018 09:14, David Brown wrote:
> On 13/05/18 22:22, bartc wrote:
> constexpr is a marvellous idea that opens up a range of possibilities in
> C++. It took a few versions of C++ to get settled, but lets you do lots
> more at compile time (its main point is for functions rather than const
> objects). I have many C programs that could be made simpler and more
> efficient with constexpr, and more where the build process would be
> simpler and more efficient.
The first constexpr example I can see online is this:
constexpr int factorial(int n)
{
return n <= 1 ? 1 : (n * factorial(n - 1));
}
Clearly it is not a simple feature, and bears as much resemblance to my
'const' as functions do to variables.
It is also conflating different ideas: that of evaluating a function at
compile-time, to the simpler one of attaching a name to a value derived
from a compile-time expression (in the simplest case, a literal value).
(BTW here's one thing it has trouble with:
constexpr int white = red+green+blue;
constexpr int red = 1, green=2, blue=4;
No such problem with my new language:
const red=1, green=2, blue=4
const white = red+green+blue
Perhaps by C++23 it might sort that out.)
> Of course "static" has a role to play with named constants. "static"
> affects linkage - sometimes you want constants that are defined in one
> translation unit but available from others,
That doesn't make sense. If a constant is to be useful in a program, its
value needs to be known to the compiler when it's compiling, not while
linking.
To share a constant name among different modules with only one point of
definition, then you put it in a shared header together with its
initialisation value. But if you forget to stick 'static' in front, then
you are apt to get multiple definitions all with the same name.
This won't happen if you use #define or enum. But those two features
have limitations and the 'constant' feature I proposed is purpose-made
and without the limitations.
> The point is that when you are thinking about your own needs,
The point is that I was able to suggest how a feature might work in C -
a 'constant' keyword to attach a name to compile-time expression - and
provide proof of concept.
*For C.*
Not /my/ language, which has had it since probably 1982, thank you very
much.
Who was intended to benefit here?
(Something that hasn't been mentioned, is that if inline assembly is
used, then when accessing names defined in the HLL, you need to know
their rank, that is, the address mode required to get to them.
In my language, it's straightforward:
const int bill = 200
int fred = 300
assem
mov eax, bill
mov eax, [fred]
end
How does it work in, say, gcc assembly?)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-14 12:05 +0100 |
| Message-ID | <Y3eKC.126771$Hc3.29221@fx30.am4> |
| In reply to | #130534 |
On 14/05/2018 11:43, bartc wrote:
> (BTW here's one thing it has trouble with:
>
> constexpr int white = red+green+blue;
> constexpr int red = 1, green=2, blue=4;
>
> No such problem with my new language:
>
> const red=1, green=2, blue=4
> const white = red+green+blue
Um, that will obviously work. It should be this way around:
const white = red+green+blue
const red=1, green=2, blue=4
Because I allow out-of-order declarations throughout a program, not even
just within a module.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-14 09:19 -0700 |
| Message-ID | <lnk1s68b1v.fsf@kst-u.example.com> |
| In reply to | #130538 |
bartc <bc@freeuk.com> writes:
> On 14/05/2018 11:43, bartc wrote:
>> (BTW here's one thing it has trouble with:
>>
>> constexpr int white = red+green+blue;
>> constexpr int red = 1, green=2, blue=4;
>>
>> No such problem with my new language:
>>
>> const red=1, green=2, blue=4
>> const white = red+green+blue
>
> Um, that will obviously work. It should be this way around:
>
> const white = red+green+blue
> const red=1, green=2, blue=4
>
> Because I allow out-of-order declarations throughout a program, not even
> just within a module.
Out-of-order declarations are obviously not permitted in C (or C++), and
have nothing to do with adding a feature for named constants.
The C++ compiler I tried had no trouble at all with your sample code.
It correctly diagnosed the errors.
I suggest dropping out-of-order declarations from the discussion, unless
you want to spawn a new huge subthread arguing about them.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-14 17:29 +0100 |
| Message-ID | <4QiKC.119678$7B3.43736@fx13.am4> |
| In reply to | #130551 |
On 14/05/2018 17:19, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: >> On 14/05/2018 11:43, bartc wrote: >>> (BTW here's one thing it has trouble with: >>> >>> constexpr int white = red+green+blue; >>> constexpr int red = 1, green=2, blue=4; >>> >>> No such problem with my new language: >>> >>> const red=1, green=2, blue=4 >>> const white = red+green+blue >> >> Um, that will obviously work. It should be this way around: >> >> const white = red+green+blue >> const red=1, green=2, blue=4 >> >> Because I allow out-of-order declarations throughout a program, not even >> just within a module. > > Out-of-order declarations are obviously not permitted in C (or C++), and > have nothing to do with adding a feature for named constants. > > The C++ compiler I tried had no trouble at all with your sample code. > It correctly diagnosed the errors. > > I suggest dropping out-of-order declarations from the discussion, unless > you want to spawn a new huge subthread arguing about them. > I was getting tired of everything in C++ being bigger and better than anything not in only in C but in any of my languages. And with no weight given to the fact that such C++ features are fantastically complicated to implement and probably don't help its already slow compile speed. Out-of-order functions (out-of-order everything is a little harder as I'm finding out) would be genuinely useful feature for C, not hard to do, and it would put it one up over C++. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-14 13:24 +0200 |
| Message-ID | <pdbrlt$tv9$1@dont-email.me> |
| In reply to | #130534 |
On 14/05/18 12:43, bartc wrote:
> On 14/05/2018 09:14, David Brown wrote:
>> On 13/05/18 22:22, bartc wrote:
>
>> constexpr is a marvellous idea that opens up a range of possibilities in
>> C++. It took a few versions of C++ to get settled, but lets you do lots
>> more at compile time (its main point is for functions rather than const
>> objects). I have many C programs that could be made simpler and more
>> efficient with constexpr, and more where the build process would be
>> simpler and more efficient.
>
> The first constexpr example I can see online is this:
>
> constexpr int factorial(int n)
> {
> return n <= 1 ? 1 : (n * factorial(n - 1));
> }
>
> Clearly it is not a simple feature, and bears as much resemblance to my
> 'const' as functions do to variables.
>
It is primarily for functions, as I said.
> It is also conflating different ideas: that of evaluating a function at
> compile-time, to the simpler one of attaching a name to a value derived
> from a compile-time expression (in the simplest case, a literal value).
>
> (BTW here's one thing it has trouble with:
>
> constexpr int white = red+green+blue;
> constexpr int red = 1, green=2, blue=4;
Of course it has trouble with it - C++ requires things to be declared
before use. Swap the two lines, and it works fine.
>
> No such problem with my new language:
>
> const red=1, green=2, blue=4
> const white = red+green+blue
>
> Perhaps by C++23 it might sort that out.)
>
>> Of course "static" has a role to play with named constants. "static"
>> affects linkage - sometimes you want constants that are defined in one
>> translation unit but available from others,
>
> That doesn't make sense. If a constant is to be useful in a program, its
> value needs to be known to the compiler when it's compiling, not while
> linking.
No, constant data from other parts of the code is also useful.
Certainly constant data whose value is known at compile time is /more/
useful, and offers more scope for optimisation.
As a general rule, if I have a C "module" that exports /small/ constant
data such as numbers, I'd have "static const int noOfWhatsits = 100;" in
the header. With /static/. If it is exporting something large, like a
table, I'd have "extern const int datatable[256];" in the header, and
the definition of the const table in in the implementation file.
>
> To share a constant name among different modules with only one point of
> definition, then you put it in a shared header together with its
> initialisation value. But if you forget to stick 'static' in front, then
> you are apt to get multiple definitions all with the same name.
That's one of the reasons why you should learn to use "static" and
"extern" appropriately. If you ever have data (const or not) declared
in a header without either "static" or "extern", you have got something
wrong. It's an easy rule to learn.
(I am sure some people will have exceptions to such a rule, but I can't
think of any good ones at the moment.)
>
> This won't happen if you use #define or enum. But those two features
> have limitations and the 'constant' feature I proposed is purpose-made
> and without the limitations.
They have different limitations - and different benefits - and can be
useful in different places.
(And again, let me reiterate that I'd like C const to have C++ const
features, allowing it to be used more often instead of #define or enum.)
>
>> The point is that when you are thinking about your own needs,
>
> The point is that I was able to suggest how a feature might work in C -
> a 'constant' keyword to attach a name to compile-time expression - and
> provide proof of concept.
>
> *For C.*
>
> Not /my/ language, which has had it since probably 1982, thank you very
> much.
>
> Who was intended to benefit here?
>
> (Something that hasn't been mentioned, is that if inline assembly is
> used, then when accessing names defined in the HLL, you need to know
> their rank, that is, the address mode required to get to them.
>
> In my language, it's straightforward:
>
> const int bill = 200
> int fred = 300
>
> assem
> mov eax, bill
> mov eax, [fred]
> end
>
> How does it work in, say, gcc assembly?)
>
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-14 14:07 +0100 |
| Message-ID | <_RfKC.81410$7b4.22023@fx12.am4> |
| In reply to | #130540 |
On 14/05/2018 12:24, David Brown wrote:
> On 14/05/18 12:43, bartc wrote:
>> On 14/05/2018 09:14, David Brown wrote:
>>> On 13/05/18 22:22, bartc wrote:
>>
>>> constexpr is a marvellous idea that opens up a range of possibilities in
>>> C++. It took a few versions of C++ to get settled, but lets you do lots
>>> more at compile time (its main point is for functions rather than const
>>> objects). I have many C programs that could be made simpler and more
>>> efficient with constexpr, and more where the build process would be
>>> simpler and more efficient.
>>
>> The first constexpr example I can see online is this:
>>
>> constexpr int factorial(int n)
>> {
>> return n <= 1 ? 1 : (n * factorial(n - 1));
>> }
>>
>> Clearly it is not a simple feature, and bears as much resemblance to my
>> 'const' as functions do to variables.
>>
>
> It is primarily for functions, as I said.
I think that feature could be added to a language like C without too
much difficulty, certainly for an example like the above.
But it would take a day or two to mock up something that will show it is
possible (evaluating the above example at compile-time when called with
constant argument) using my intended approach*.
(*To tentatively interpret the AST of the function at a particular
call-site, and to either end up with a result - an operand containing
the constant value - or to abort with a failure code so that it has to
be treated normally.)
Although I'd rather put the effort towards my language where it least it
might end up being used rather that just to make a point.
>> (BTW here's one thing it has trouble with:
>>
>> constexpr int white = red+green+blue;
>> constexpr int red = 1, green=2, blue=4;
>
> Of course it has trouble with it - C++ requires things to be declared
> before use. Swap the two lines, and it works fine.
I like the way you just lightly dismiss one of the best features of my
newer languages, which is not to have to care about the order things are
defined in, especially functions where it can involve some effort (to
arrange the functions in call order, or to add forward declarations).
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-14 16:19 +0200 |
| Message-ID | <pdc5sk$313$1@dont-email.me> |
| In reply to | #130543 |
On 14/05/18 15:07, bartc wrote:
> On 14/05/2018 12:24, David Brown wrote:
>> On 14/05/18 12:43, bartc wrote:
>>> On 14/05/2018 09:14, David Brown wrote:
>>>> On 13/05/18 22:22, bartc wrote:
>>>
>>>> constexpr is a marvellous idea that opens up a range of
>>>> possibilities in
>>>> C++. It took a few versions of C++ to get settled, but lets you do
>>>> lots
>>>> more at compile time (its main point is for functions rather than const
>>>> objects). I have many C programs that could be made simpler and more
>>>> efficient with constexpr, and more where the build process would be
>>>> simpler and more efficient.
>>>
>>> The first constexpr example I can see online is this:
>>>
>>> constexpr int factorial(int n)
>>> {
>>> return n <= 1 ? 1 : (n * factorial(n - 1));
>>> }
>>>
>>> Clearly it is not a simple feature, and bears as much resemblance to my
>>> 'const' as functions do to variables.
>>>
>>
>> It is primarily for functions, as I said.
>
> I think that feature could be added to a language like C without too
> much difficulty, certainly for an example like the above.
>
> But it would take a day or two to mock up something that will show it is
> possible (evaluating the above example at compile-time when called with
> constant argument) using my intended approach*.
>
> (*To tentatively interpret the AST of the function at a particular
> call-site, and to either end up with a result - an operand containing
> the constant value - or to abort with a failure code so that it has to
> be treated normally.)
>
> Although I'd rather put the effort towards my language where it least it
> might end up being used rather that just to make a point.
That makes sense to me.
>
>>> (BTW here's one thing it has trouble with:
>>>
>>> constexpr int white = red+green+blue;
>>> constexpr int red = 1, green=2, blue=4;
>>
>> Of course it has trouble with it - C++ requires things to be declared
>> before use. Swap the two lines, and it works fine.
>
> I like the way you just lightly dismiss one of the best features of my
> newer languages, which is not to have to care about the order things are
> defined in, especially functions where it can involve some effort (to
> arrange the functions in call order, or to add forward declarations).
>
Well, yes - I dismissed it because it is irrelevant to this thread. If
you want to start (yet) another thread about the pros and cons of
needing to declare things before use, then you could do that. But it
would be easier just to acknowledge:
1. You think it is important to be able to use identifiers before
declaring them - thus you see your language has a big win over C in this
aspect.
2. I don't think it is important - I see it as having some benefits, but
also some disadvantages. Thus I am quite happy with C's requirements of
definition before use. But equally, it does not bother me that in C++
you /can/ use identifiers before declarations (like fields in a class
that refer to each other - thus letting you write public methods before
private members, if you prefer).
3. No one will convince you that this is /not/ important. Equally, you
will convince no one (who does not already agree with you) that it /is/
important.
As long as you are happy to recognize that my opinion is based on
technical grounds and personal preferences, not some sort of conspiracy
to reject everything you say, then I hope we can simply agree to
disagree and skip that whole thread.
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2018-05-14 07:49 -0700 |
| Message-ID | <21dd45af-d88f-4aaa-89ba-13adb1eb9a99@googlegroups.com> |
| In reply to | #130545 |
On Monday, 14 May 2018 15:19:10 UTC+1, David Brown wrote: > As long as you are happy to recognize that my opinion is based on s/recognize/pretend/ > technical grounds and personal preferences, not some sort of conspiracy > to reject everything you say, then I hope we can simply agree to > disagree and skip that whole thread. Come on David, we all know that we've got this grand conspiracy against Bart - the Freemasons, the Illuminati and the Girl Guides have nothing on us for highly-organised subversive activity aimed at perpetuating our power and persecuting those who, like Bart, stand against us.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-14 08:07 -0700 |
| Message-ID | <4a19d231-ff8c-4461-b4e9-3b423e812396@googlegroups.com> |
| In reply to | #130545 |
On Monday, May 14, 2018 at 7:19:10 AM UTC-7, David Brown wrote:
> On 14/05/18 15:07, bartc wrote:
> > On 14/05/2018 12:24, David Brown wrote:
> >> On 14/05/18 12:43, bartc wrote:
> >>> On 14/05/2018 09:14, David Brown wrote:
> >>>> On 13/05/18 22:22, bartc wrote:
> >>>
> >>>> constexpr is a marvellous idea that opens up a range of
> >>>> possibilities in
> >>>> C++. It took a few versions of C++ to get settled, but lets you do
> >>>> lots
> >>>> more at compile time (its main point is for functions rather than const
> >>>> objects). I have many C programs that could be made simpler and more
> >>>> efficient with constexpr, and more where the build process would be
> >>>> simpler and more efficient.
> >>>
> >>> The first constexpr example I can see online is this:
> >>>
> >>> constexpr int factorial(int n)
> >>> {
> >>> return n <= 1 ? 1 : (n * factorial(n - 1));
> >>> }
> >>>
> >>> Clearly it is not a simple feature, and bears as much resemblance to my
> >>> 'const' as functions do to variables.
> >>>
> >>
> >> It is primarily for functions, as I said.
> >
> > I think that feature could be added to a language like C without too
> > much difficulty, certainly for an example like the above.
> >
> > But it would take a day or two to mock up something that will show it is
> > possible (evaluating the above example at compile-time when called with
> > constant argument) using my intended approach*.
> >
> > (*To tentatively interpret the AST of the function at a particular
> > call-site, and to either end up with a result - an operand containing
> > the constant value - or to abort with a failure code so that it has to
> > be treated normally.)
> >
> > Although I'd rather put the effort towards my language where it least it
> > might end up being used rather that just to make a point.
>
> That makes sense to me.
>
> >
> >>> (BTW here's one thing it has trouble with:
> >>>
> >>> constexpr int white = red+green+blue;
> >>> constexpr int red = 1, green=2, blue=4;
> >>
> >> Of course it has trouble with it - C++ requires things to be declared
> >> before use. Swap the two lines, and it works fine.
> >
> > I like the way you just lightly dismiss one of the best features of my
> > newer languages, which is not to have to care about the order things are
> > defined in, especially functions where it can involve some effort (to
> > arrange the functions in call order, or to add forward declarations).
> >
>
> Well, yes - I dismissed it because it is irrelevant to this thread. If
> you want to start (yet) another thread about the pros and cons of
> needing to declare things before use, then you could do that. But it
> would be easier just to acknowledge:
>
> 1. You think it is important to be able to use identifiers before
> declaring them - thus you see your language has a big win over C in this
> aspect.
>
> 2. I don't think it is important - I see it as having some benefits, but
> also some disadvantages. Thus I am quite happy with C's requirements of
> definition before use. But equally, it does not bother me that in C++
> you /can/ use identifiers before declarations (like fields in a class
> that refer to each other - thus letting you write public methods before
> private members, if you prefer).
>
> 3. No one will convince you that this is /not/ important. Equally, you
> will convince no one (who does not already agree with you) that it /is/
> important.
>
> As long as you are happy to recognize that my opinion is based on
> technical grounds and personal preferences, not some sort of conspiracy
> to reject everything you say, then I hope we can simply agree to
> disagree and skip that whole thread.
I think the point is not 100% to get them to listen to him. The point is likely to piss Alan Baker off for trolling outside groups he knows I frequent.
It's trivial to pick by focusing on a few exceptions clashing from what is something more common like Debian. What a better tactic from an honest advocates way of thinking are the ordinary events.
Why do you keep rephrasing Alan Baker? Another successful Linux Android test. That is if you count utter failure as a success.
David 'The Fool' Empson was once again a charlatan by having the pretense to not debate Alan Baker through vehemently blasting 'Into the bin with you!' and then bombarding him anyhow by means of a 3rd party. You guys can only appreciate things from the viewpoint of a sociopath.
David 'The Fool' Empson wants to punish the whole group: If David 'The Fool' Empson can't have dominate conversations here then no one will.
-
What Every Entrepreneur Must Know!!
http://www.5z8.info/michaelangelo-virus_t6v2vq_molotovcocktail
https://www.youtube.com/watch?v=OffkiSAsYo8
https://www.facebook.com/profile.php?id=100012978552519
Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-13 13:20 -0700 |
| Message-ID | <lnzi138fz3.fsf@kst-u.example.com> |
| In reply to | #130489 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> 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".
[...]
You are conflating "const" and "constant". They mean two *very*
different things in C. Defining an object with "const" never makes
its name a constant expression.
A *constant* in C is a lexical element, either an integer-constant, a
floating-constant, an enumeration-constant, or a character-constant.
A *constant expression* is an expression that can, and in
some contexts must, be evaluated at compile time. Neither of
these has anything to do with the "const" keyword, which means
"read-only". (Attempting to modify a const-qualified object after
its initialization is a constraint violation.)
As I've said before, I'd like to see a feature in C that permits
creating a name for a specified constant value of a specified type,
making that name a constant expression. I would prefer not to use
the "const" keyword for such a feature. (C++ already does so to
some extent, and consistency with C++ is generally a good thing,
all else being equal.)
--
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-14 10:47 +0200 |
| Message-ID | <pdbiet$oo$1@dont-email.me> |
| In reply to | #130511 |
On 13/05/18 22:20, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> 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". > [...] > > You are conflating "const" and "constant". They mean two *very* > different things in C. Defining an object with "const" never makes > its name a constant expression. Yes, I know. But have been a bit loose on the technical terms in posts in this thread. In particular, the term "constant" has been used by many people here for "something that is fixed at compile time and does not change" - rather than in the way the C standard uses it (which you neatly summarise below). > > A *constant* in C is a lexical element, either an integer-constant, a > floating-constant, an enumeration-constant, or a character-constant. (6.4.4, for anyone wanting to look up the details.) > A *constant expression* is an expression that can, and in > some contexts must, be evaluated at compile time. Note that many expressions that can be evaluated at compile time, are not "constant expressions". In particular, compilers are free to evaluate all sorts of things at compile time if they are smart enough. Constant expressions are things that the compiler /must/ be able to evaluate at compile time. (Details in 6.6.) > Neither of > these has anything to do with the "const" keyword, which means > "read-only". (Attempting to modify a const-qualified object after > its initialization is a constraint violation.) Agreed. But the topic here is about ways of making "something with a value fixed at compile time, and an identifying name" - /colloquially/ called "constants". "const" is one way of making such objects - even though they are not a standard C "constant" or "constant expression". (They may, in many cases, be constant expressions in C++.) > > As I've said before, I'd like to see a feature in C that permits > creating a name for a specified constant value of a specified type, > making that name a constant expression. I would prefer not to use > the "const" keyword for such a feature. (C++ already does so to > some extent, and consistency with C++ is generally a good thing, > all else being equal.) > I'd be happy to see C copy most of "const" from C++ - that would cover most of my desires for improving constants in C. In particular, I want to be able to write: static const int width = 10; static const int height = 20; static const int area = width * height; static int colours[area]; I appreciate that some features of C++ const might not be appropriate for C. For example, "const int x = 123;" in C++ makes "x" static by default, but in C it is extern by default - I doubt if that could be changed.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-14 10:35 -0700 |
| Message-ID | <lnfu2u87jp.fsf@kst-u.example.com> |
| In reply to | #130530 |
David Brown <david.brown@hesbynett.no> writes:
> On 13/05/18 22:20, Keith Thompson wrote:
[...]
>> You are conflating "const" and "constant". They mean two *very*
>> different things in C. Defining an object with "const" never makes
>> its name a constant expression.
>
> Yes, I know. But have been a bit loose on the technical terms in posts
> in this thread.
[...]
Please don't. The distinction between "const" and "constant" is
both widely misunderstood and central to the current discussion.
Please don't add to the 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-15 09:10 +0200 |
| Message-ID | <pde14g$te3$1@dont-email.me> |
| In reply to | #130561 |
On 14/05/18 19:35, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 13/05/18 22:20, Keith Thompson wrote: > [...] >>> You are conflating "const" and "constant". They mean two *very* >>> different things in C. Defining an object with "const" never makes >>> its name a constant expression. >> >> Yes, I know. But have been a bit loose on the technical terms in posts >> in this thread. > [...] > > Please don't. The distinction between "const" and "constant" is > both widely misunderstood and central to the current discussion. > Please don't add to the confusion. > Mostly, I do try to be accurate on things like this (and I value corrections when I am not precise). However, in this thread the term "constant" was used from the start as a more general description rather than the C (or C++) standards term. I think it is perhaps a little unfortunate that the C standards use the term "constant" as a defined term, when it is such a useful word in general discussions - confusions are bound to occur. But we don't get to change the wording of the standard. Would it make sense to refer to "C constants" when talking about the things defined in 6.4.4 of the C standards? Or is there an alternative general word for "values that are fixed in the source code and cannot change"?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-15 08:53 -0700 |
| Message-ID | <lnvabo7w4y.fsf@kst-u.example.com> |
| In reply to | #130586 |
David Brown <david.brown@hesbynett.no> writes:
> On 14/05/18 19:35, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 13/05/18 22:20, Keith Thompson wrote:
>> [...]
>>>> You are conflating "const" and "constant". They mean two *very*
>>>> different things in C. Defining an object with "const" never makes
>>>> its name a constant expression.
>>>
>>> Yes, I know. But have been a bit loose on the technical terms in posts
>>> in this thread.
>> [...]
>>
>> Please don't. The distinction between "const" and "constant" is
>> both widely misunderstood and central to the current discussion.
>> Please don't add to the confusion.
>
> Mostly, I do try to be accurate on things like this (and I value
> corrections when I am not precise). However, in this thread the term
> "constant" was used from the start as a more general description rather
> than the C (or C++) standards term. I think it is perhaps a little
> unfortunate that the C standards use the term "constant" as a defined
> term, when it is such a useful word in general discussions - confusions
> are bound to occur. But we don't get to change the wording of the standard.
Parts of this thread have been vague, but I don't think the word
"constant" has been redefined. The main thing being discussed is
proposals to add new forms of constants.
> Would it make sense to refer to "C constants" when talking about the
> things defined in 6.4.4 of the C standards? Or is there an alternative
> general word for "values that are fixed in the source code and cannot
> change"?
6.4.4 defines constants (integer-constants, floating-constants,
enumeration-constants, character-constants). It makes sense to
refer to them as "constants".
For example, given:
const int answer = 42;
`answer` is not a constant, nor is it a constant expression.
It's a read-only object. (There have been suggestions to make
`answer` a constant expression in the future, as it is in C++.)
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-05-13 08:19 +1200 |
| Message-ID | <flp0j6Fua2iU3@mid.individual.net> |
| In reply to | #130443 |
On 05/12/2018 10:53 PM, bartc wrote:
>
> I've discussed this a few times in this group, and it appears that most
> people here just don't get it.
People do "get it", they just don't see the need for 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.
What C++ has (and has had since its inception) is good enough. Yes you
can write perverse code that attempts to modify a const value, but this
will simply crash so most accept that it is perverse and don't do it.
There are case where you do need the address of a const value, such as
when it it is used as a function parameter.
My original post should have simple said "const used a constant
expression". Not being able to use bufferSize from
const size_t bufferSize = 42;
as an array bound is a hole that need to be fixed.
In C++ constexpr is no different form const in this regard, it simply
provides the additional guarantee that the value is evaluated at compile
time as well as expanding what can be a constant expression such as
simple functions.
Incidentally C++ has always had an equivalent to your notion of a named
constant or literal: an inline initialised static class member:
struct X
{
static const int n = 42;
};
If you try and use the address of X::n, the program won't link.
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-05-13 17:44 +0000 |
| Message-ID | <mQ_JC.69659$7H4.62985@fx12.iad> |
| In reply to | #130467 |
Ian Collins <ian-news@hotmail.com> writes:
> Thunderbird/52.7.0
>In-Reply-To: <kIzJC.117349$9t.42512@fx26.am4>
>Content-Language: en-US
>X-Received-Bytes: 2489
>X-Received-Body-CRC: 2386019514
>
>On 05/12/2018 10:53 PM, bartc wrote:
>>
>> I've discussed this a few times in this group, and it appears that most
>> people here just don't get it.
>
>People do "get it", they just don't see the need for 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.
>
>What C++ has (and has had since its inception) is good enough. Yes you
>can write perverse code that attempts to modify a const value, but this
>will simply crash so most accept that it is perverse and don't do it.
>There are case where you do need the address of a const value, such as
>when it it is used as a function parameter.
>
>My original post should have simple said "const used a constant
>expression". Not being able to use bufferSize from
>
>const size_t bufferSize = 42;
>
>as an array bound is a hole that need to be fixed.
>
>In C++ constexpr is no different form const in this regard, it simply
>provides the additional guarantee that the value is evaluated at compile
>time as well as expanding what can be a constant expression such as
>simple functions.
>
>Incidentally C++ has always had an equivalent to your notion of a named
>constant or literal: an inline initialised static class member:
>
>struct X
>{
> static const int n = 42;
>};
>
>If you try and use the address of X::n, the program won't link.
>
If you compile with GCC and don't use -O, it may not link. You still
must allocate storage for it.
const int X::n;
If you compile with -O3, generally, the storage won't be needed and
you can get away with not allocating it. But that may bite you
if you try to build without -O.
[toc] | [prev] | [next] | [standalone]
Page 5 of 12 — ← Prev page 1 … 3 4 [5] 6 7 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web