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 2 of 12 — ← Prev page 1 [2] 3 4 … 12 Next page →
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-06-15 10:25 -0400 |
| Message-ID | <U%PUC.222045$p05.57412@fx28.iad> |
| In reply to | #131640 |
On 6/14/18 7:27 AM, Tim Rentsch wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 5/18/18 11:48 PM, Tim Rentsch wrote:
>>
>>> Richard Damon <Richard@Damon-Family.org> writes:
>>>
>>>> On 5/11/18 1:47 PM, supercat@casperkitty.com wrote:
>>>>
>>>>> On Friday, May 11, 2018 at 12:14:00 PM UTC-5, Thiago Adams wrote:
>>>>>
>>>>>> Features I would like in C:
>>>>>>
>>>>>> * Removing trigraphs
>>>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4086.html
>>>>>
>>>>> A syntax could be provided to enable them if really needed, with the caveat
>>>>> that it couldn't use "#".
>>>>
>>>> I've thought that it might work to define that a file could begin with a
>>>> line something like (i.e. for the very first character of a file,
>>>> process with trigraphs, otherwise only if the appropriate pragma has
>>>> been turned on)
>>>>
>>>> ??=pragma STDC TRIGRAPHS ON
>>>>
>>>> with the new pragma notation, you could also do something like
>>>>
>>>> _Pramga("STDC TRIGRAPHS ON")
>>>>
>>>> which doesn't even need the special processing for the first character.
>>>
>>> The engineering economics of something like this are awful.
>>> Seriously, trigraphs almost never cause problems in ordinary
>>> C code, and eliminating the problems is as easy as a grep or
>>> sed step in the build process. I see no reason to sacrifice
>>> backwards compatibility for so minor a concern.
>>
>> The one spot trigraphs can easily cause problems is in string literals.
>> If you remember about them, you can easily fix them by breaking up the
>> ?? sequence by using the string concatenation feature.
>
> An easier way is just to put a \ in between any two consecutive
> question marks. No reason to fool around with string joining.
>
>> Some compilers have disabled trigraphs by default (yes, making them
>> non-conformant by default) with an option to enable or by default will
>> generate a warning if a trigraph is seen in the source code. Most allow
>> them to be disable, so letting a pragma do this would not add
>> significant complexity.
>
> The impact on compilers is of no concern in this. It's the
> impact on programs that matters.
>
>> Trigraphs were include in the C90 standard because some national bodies
>> insisted that something needed to be done to handle that fact that their
>> versions of basic character sets (variations of iso646, which are mostly
>> compatible with ASCII except for possibly 9 characters, which are used
>> by the C language).
>
> That is my understanding as well.
>
>> The fact that C95 added digraphs to solve the exact same problem is a
>> good indication that they felt trigraphs didn't do the job well enough.
>
> Except that digraphs do not solve exactly the same problem. Only
> some of the "magic 9" characters are representable using
> digraphs. I suspect digraphs solve the problem for a large
> percentage of non-ASCII character sets, and that's why digraphs
> were introduced. But they don't solve it for all.
Digraphs, and iso646.h together provide a solution of 8 of the 9
trigraph symbols. The one character you can't get is \, which is fairly
important, but I am not sure how many character sets don't have it or
something that can be used for it. (I know one common Japanesse
character encoding uses that code point for the Yen symbol, but users of
that character encoding don't seem to horribly mind using it as the
equivalent of a \ when needed.) Perhaps to other solution would be to
invent a digraph for \ (but since digraphs don't apply in strings, it
might not be quite as helpful). One other comment is that (as just
mentioned) the lack of digraphs being used in strings is a likely
indication that (the few) programmers working in these character sets
missing some of these characters are likely writing programs for
machines that similarly don't readily support these characters, so their
lack in strings isn't that important, and in strings you have other
methods of inserting arbitrary character codes (at least one you define
a way to get the \ character).
>
>> C++ as of C++17 has removed trigraphs from the language.
>
> C++ has basically given up on maintaining backwards
> compatibility. One of C's great strengths is being extremely
> conservative with regard to backwards compatibility. Yes,
> trigraphs are an ugly wart. But that reaction must not be
> allowed to break the far more important value of backwards
> compatibility.
>
C also has made several backwards incompatible changes. It has dropped
implicit int, it has dropped implied function declaration, it has
dropped mandatory support for Variable Length Arrays. Dropping default
implementation of trigraphs is in my mind of a similar level.
Allowing trigraphs to be enabled with a line like
$:pragma STDC TRIGRAPH ON
would provide a better backwards support than was provided for the other
changes I mentioned.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-06-17 12:59 -0700 |
| Message-ID | <kfnbmc9b2vi.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #131707 |
Richard Damon <Richard@Damon-Family.org> writes: > On 6/14/18 7:27 AM, Tim Rentsch wrote: > >> Richard Damon <Richard@Damon-Family.org> writes: >> >>> [...trigraphs...] >>> >>> The fact that C95 added digraphs to solve the exact same problem is a >>> good indication that they felt trigraphs didn't do the job well enough. >> >> Except that digraphs do not solve exactly the same problem. Only >> some of the "magic 9" characters are representable using >> digraphs. I suspect digraphs solve the problem for a large >> percentage of non-ASCII character sets, and that's why digraphs >> were introduced. But they don't solve it for all. > > Digraphs, and iso646.h together provide a solution of 8 of the 9 > trigraph symbols. After thinking a bit more it's clear that digraphs were meant as a convenience supplement to trigraphs, not as a replacement. I suspect iso646.h similarly. Also, using the iso646.h names implies a style choice that some will find either distasteful or invasive, or both. Neither digraphs nor iso646.h names work for character constants, and iso646.h names work for string literals only by jumping through some preprocessor hoops; digraphs don't work for string literals at all. I think it's a bit presumptuous to say what people who have used and needed trigraphs will think is an acceptable replacement, since AFAIK neither one of us falls into that category, or even deals regularly with anyone who does. > The one character you can't get is \, which is fairly important, > but I am not sure how many character sets don't have it or > something that can be used for it. (I know one common Japanesse > character encoding uses that code point for the Yen symbol, but > users of that character encoding don't seem to horribly mind using > it as the equivalent of a \ when needed.) Perhaps to other > solution would be to invent a digraph for \ (but since digraphs > don't apply in strings, it might not be quite as helpful). One > other comment is that (as just mentioned) the lack of digraphs > being used in strings is a likely indication that (the few) > programmers working in these character sets missing some of these > characters are likely writing programs for machines that similarly > don't readily support these characters, so their lack in strings > isn't that important, I don't see the point of this. People don't use digraphs in strings because they don't work - digraphs are tokens, not character substitutions. They don't work in character constants either. > and in strings you have other methods of inserting arbitrary > character codes [after there is a way to get a \]. Use system-dependent numeric values in place of portable symbolic ones? Surely that is not meant as a serious suggestion. >>> C++ as of C++17 has removed trigraphs from the language. >> >> C++ has basically given up on maintaining backwards >> compatibility. One of C's great strengths is being extremely >> conservative with regard to backwards compatibility. Yes, >> trigraphs are an ugly wart. But that reaction must not be >> allowed to break the far more important value of backwards >> compatibility. > > C also has made several backwards incompatible changes. It has > dropped implicit int, it has dropped implied function declaration, > it has dropped mandatory support for Variable Length Arrays. Implicit int and implicit function declaration were inherited for historical reasons. They don't add anything essential, they aren't easy to check for outside a compilation context, and it's easy for either to creep into a program unintendedly and cause problems. All of those are reversed for trigraphs: they are essential in certain cases, they are very easy to find (eg, with grep) if not wanted, they hardly ever crop up unintendedly and even if they do the consequences are likely very minor. VLAs are a different animal. They were introduced in a later version of the Standard which did not get a lot of early adoption, and require significant effort to implement. Also it's pretty easy to get along without VLAs, especially since people were used to doing that for 30ish years before VLAs were available. Furthermore they weren't removed, they were made conditionally supported - in practical terms if a given compiler implemented C99 it would still support VLAs under C11. Programs that worked before would very likely continue to work without change. A change to trigraphs along the lines of what has been proposed does not have that property. > Dropping default implementation of trigraphs is in my mind of a > similar level. They are different in an important way in that keeping trigraphs has almost no downside. That's not true for the other changes mentioned. > Allowing trigraphs to be enabled with a line like > > $:pragma STDC TRIGRAPH ON > > would provide a better backwards support than was provided for the > other changes I mentioned. For implicit int and implicit function declaration, it's an apples-and-oranges comparision. These features were not supported via some alternate mechanism, they were simply REMOVED because it was believed they cause more harm than good. For VLAs, I don't even think it's right necessarily. Programs that use VLAs and compiled before will very likely continue to compile in the future, because compilers won't just throw away VLA support that they implemented before. And VLAs are not in same category in the sense that what they provide is essential. (Also I will register my vote that I would like to see VLAs be restored to required, unconditionally, even if just for hosted implementations.) In any case this consideration is of minor importance - trigraphs should be retained because there is almost no downside to keeping them. Indeed it isn't obvious but that making a change might be more costly than simply leaving them as is, even not counting the upgrade cost for programs that would need to be changed under some new scheme.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-06-17 23:44 -0700 |
| Message-ID | <6c70fc2d-0aba-4717-b9a3-d823b4c76873@googlegroups.com> |
| In reply to | #131769 |
On Sunday, June 17, 2018 at 2:59:58 PM UTC-5, Tim Rentsch wrote: > I don't see the point of this. People don't use digraphs in > strings because they don't work - digraphs are tokens, not > character substitutions. They don't work in character constants > either. Any character constant can be specified using a number. > Use system-dependent numeric values in place of portable symbolic > ones? Surely that is not meant as a serious suggestion. Hosted implementations which lack things like braces in the source character set will probably *also* lack them in the execution character set. Conversely, while some implementations may make it excessively awkward to type within source code certain characters that are within the destination character set, that's probably just as true of things that aren't in the C source code character set as things that are, so there's no need to treat the former specially within string literals. In most cases where characters exist in the destination character set that can't be typed within source code, the programmer will know more about what those characters are than the compiler will. I therefore see nothing absurd about the idea that programmers should specify such characters according to their representation in the execution character set. > For implicit int and implicit function declaration, it's an > apples-and-oranges comparision. These features were not > supported via some alternate mechanism, they were simply REMOVED > because it was believed they cause more harm than good. What do you mean? They were supported by the mechanism of allowing programmers to declare the identifiers they're using.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-12 12:48 -0700 |
| Message-ID | <lnlgcoac4r.fsf@kst-u.example.com> |
| In reply to | #130418 |
supercat@casperkitty.com writes:
> On Friday, May 11, 2018 at 12:14:00 PM UTC-5, Thiago Adams wrote:
>> Features I would like in C:
>>
>> * Removing trigraphs
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4086.html
>
> A syntax could be provided to enable them if really needed, with the caveat
> that it couldn't use "#".
If trigraphs are going to be dropped, I don't really see the point
of having a language-defined way to enable them. Such a feature
can always be provided as a compiler-specific extension for the
increasingly narrow set of systems where trigraphs are actually
useful. gcc, for example, already has a "-trigraphs" option;
it would merely have to change the way "-std=..." affects it.
Introducing trigraphs to the language marginally increased the
language's complexity. At the time, their utility was thought to
be worth that cost. Disabling them by default but adding a new
feature to re-enable them would just add more complexity.
With this new syntax, if I have existing code that uses trigraphs,
I have to modify it to make it conform to the new standard, and
if I write new code that uses trigraphs, C11 and earlier compilers
won't recognize the new enabling syntax.
I'd like to see trigraphs go away. We have an opportunity to
improve and simplify the language.
[...]
--
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-12 13:07 -0700 |
| Message-ID | <cf708319-9915-420b-a0ae-fce2e5ea4712@googlegroups.com> |
| In reply to | #130464 |
On Saturday, May 12, 2018 at 2:48:46 PM UTC-5, Keith Thompson wrote: > Introducing trigraphs to the language marginally increased the > language's complexity. At the time, their utility was thought to > be worth that cost. Disabling them by default but adding a new > feature to re-enable them would just add more complexity. Trigraphs are harmless outside string and character literals, but can create trouble there. I don't see particular value in requiring that compilers support trigraphs, but would see value in requiring that they must by default treat "Are you crazy??" // " as a string literal which ends with two question marks. As a matter of principle, I think that if a construct is defined by any version of the Standard, it should be easy to write code that needs that construct in a way that implementations would, at minimum, be allowed to process it in the old fashion.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-12 13:59 -0700 |
| Message-ID | <lnh8nca8va.fsf@kst-u.example.com> |
| In reply to | #130466 |
supercat@casperkitty.com writes:
> On Saturday, May 12, 2018 at 2:48:46 PM UTC-5, Keith Thompson wrote:
>> Introducing trigraphs to the language marginally increased the
>> language's complexity. At the time, their utility was thought to
>> be worth that cost. Disabling them by default but adding a new
>> feature to re-enable them would just add more complexity.
>
> Trigraphs are harmless outside string and character literals, but can
> create trouble there. I don't see particular value in requiring that
> compilers support trigraphs, but would see value in requiring that they
> must by default treat
>
> "Are you crazy??" // "
>
> as a string literal which ends with two question marks. As a matter
> of principle, I think that if a construct is defined by any version
> of the Standard, it should be easy to write code that needs that
> construct in a way that implementations would, at minimum, be allowed
> to process it in the old fashion.
Compilers *are* permitted to process programs in the old fashion,
by operating in a non-conforming mode. As I mentioned, gcc already
has a "-trigraphs" option, as well as "-std=cNN" (NN=90,99,11).
I don't expect any of those options to go away if a new standard
drops trigraphs. (I use gcc as an example; other compilers can do
something similar.)
And if nothing else, a filter that translates trigraphs would be nearly
trivial to write and could be invoked as part of a build process if
necessary.
None of this requires keeping trigraph support in a future standard.
--
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-11 18:50 +0100 |
| Message-ID | <MJkJC.125763$Hc3.116805@fx30.am4> |
| In reply to | #130416 |
On 11/05/2018 18:13, Thiago Adams wrote: > Features I would like in C: > * Removing operator++ for bool > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0002r1.html I only discovered yesterday that C allows ++ or -- to be applied to floats and doubles. It doesn't seem quite right to me, as ++ will not step a value to the next different value of its type, as happens with ints and pointers. It also seems bad style. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-05-11 11:22 -0700 |
| Message-ID | <6cbb08ec-295d-4937-9f20-3403c44cbed2@googlegroups.com> |
| In reply to | #130419 |
On Friday, May 11, 2018 at 2:50:46 PM UTC-3, Bart wrote:
> On 11/05/2018 18:13, Thiago Adams wrote:
>
> > Features I would like in C:
>
> > * Removing operator++ for bool
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0002r1.html
>
> I only discovered yesterday that C allows ++ or -- to be applied to
> floats and doubles.
>
> It doesn't seem quite right to me, as ++ will not step a value to the
> next different value of its type, as happens with ints and pointers.
>
> It also seems bad style.
>
Yes, at least warnings.
---
This is old feature but I think C should make
the struct tag a type, like C++ and not require
'struct'.
Like this:
struct X
{
X* pNext;
};
X x;
The justification is that typedef names already needs
lookup.
Ignoring symbol table lookup for struct enum and union
doesn't make sense if we don't do the same for other types.
(
See New keyword _Type for C ?
https://groups.google.com/d/topic/comp.lang.c/_p5Nl3j3CQQ/discussion
)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-05-18 02:45 -0700 |
| Message-ID | <b508cea9-8163-451c-bef6-07363ed9b7dd@googlegroups.com> |
| In reply to | #130419 |
On Friday, May 11, 2018 at 6:50:46 PM UTC+1, Bart wrote: > On 11/05/2018 18:13, Thiago Adams wrote: > > > Features I would like in C: > > > * Removing operator++ for bool > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0002r1.html > > I only discovered yesterday that C allows ++ or -- to be applied to > floats and doubles. > > It doesn't seem quite right to me, as ++ will not step a value to the > next different value of its type, as happens with ints and pointers. > > It also seems bad style. > Yes, it's poor form to use ++ on a real type. Incrementing and adding a constant that happens to be one are two different things. For example in football you get one point for a draw, three points for a win. That should be coded as if(draw) points += 1;
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-05-11 11:28 -0700 |
| Message-ID | <35364a7c-6216-4955-94b1-d3fb6803d74c@googlegroups.com> |
| In reply to | #130416 |
On Friday, May 11, 2018 at 2:14:00 PM UTC-3, Thiago Adams wrote: > I have a list of features from C++ I would like to > see in C. Obs: This would not be my priority list, but considering that these features are already implemented in C++ then I think they also make sense in C. The languages can benefit each other keeping compatibility.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-05-11 21:49 +0200 |
| Message-ID | <pd4s42$rnm$1@solani.org> |
| In reply to | #130416 |
Am 11.05.2018 um 19:13 schrieb Thiago Adams: > > I have a list of features from C++ I would like to > see in C. > > Most of these features can be experimented today in C++. > > One C++ feature list very easy to read is available together > with Visual C++ compiler updates. > > https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/ > > Features I would like in C: There is a bit of coordination between WG14 and WG21, and indeed many from your list are also being considered by WG14 (see SD3, http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2232.htm for the plans for C2X as of end of March). > > * Removing trigraphs > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4086.html It is on the SD3 list; I do not know what WG14 thinks of it, but I would guess that this could go in. It is in SD3, so there could be some decision in Pittsburg later this year. > > * u8 character literals > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4267.html There are still some details to be worked out (such as the type of the literal), but it might well make it. It is in SD3, so there could be some decision in Pittsburg later this year. > > * Terse static_assert > www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3928.pdf I'd consider this one very likely to make it. In fact, so likely, that I already implemented it for SDCC with --std-c2x. It is in SD3, so there could be some decision in Pittsburg later this year. > > * Removing operator++ for bool > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0002r1.html > I am not aware of any concrete efforts on this, but that is just me, and there is plenty of time left. Some people have been talking about wanting to revise the bool stuff, but there also seems to be some opposition. > * __has_include > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0061r1.html There has been an effort to put this into C even back before the C++ standard introducing it was published. I haven't heard of it lately, though. It is in SD3, so there could be some decision in Pittsburg later this year. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-05-11 16:44 -0700 |
| Message-ID | <47c91616-531c-4c64-85d8-4a717a35c222@googlegroups.com> |
| In reply to | #130425 |
On Friday, May 11, 2018 at 4:49:32 PM UTC-3, Philipp Klaus Krause wrote: ... > There has been an effort to put this into C even back before the C++ > standard introducing it was published. I haven't heard of it lately, > though. It is in SD3, so there could be some decision in Pittsburg later > this year. More items from this list includes: * type used to represent an enum. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2008.pdf * attributes http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2165.pdf
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-05-12 05:51 +0000 |
| Subject | Terse static_assert (was Re: C++ features for C) |
| Message-ID | <slrnpfd074.31ka.grahn+nntp@frailea.sa.invalid> |
| In reply to | #130425 |
On Fri, 2018-05-11, Philipp Klaus Krause wrote: > Am 11.05.2018 um 19:13 schrieb Thiago Adams: ... >> * Terse static_assert >> www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3928.pdf > > I'd consider this one very likely to make it. In fact, so likely, that I > already implemented it for SDCC with --std-c2x. It is in SD3, so there > could be some decision in Pittsburg later this year. Good. I remember being very surprised when I discovered that I had to invent a message for static_assert, unlike for assert(). I find that message hard to write: should it describe the condition I assert (claim) holds, or its negation? _Static_assert(sizeof(foo) > 10, "foo is long enough"); _Static_assert(sizeof(foo) > 10, "foo is too short"); /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-05-18 22:20 -0700 |
| Subject | Re: Terse static_assert (was Re: C++ features for C) |
| Message-ID | <kfnmuwwi5lj.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #130440 |
Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
> On Fri, 2018-05-11, Philipp Klaus Krause wrote:
>
>> Am 11.05.2018 um 19:13 schrieb Thiago Adams:
>
> ...
>
>>> * Terse static_assert
>>> www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3928.pdf
>>
>> I'd consider this one very likely to make it. In fact, so likely, that I
>> already implemented it for SDCC with --std-c2x. It is in SD3, so there
>> could be some decision in Pittsburg later this year.
>
> Good. I remember being very surprised when I discovered that I had to
> invent a message for static_assert, unlike for assert().
Bleah. It's trivial to get a terse static assertion without changing
the language:
#define ASSERT(e) _Static_assert( e, #e )
> I find that message hard to write: should it describe the condition I
> assert (claim) holds, or its negation?
>
> _Static_assert(sizeof(foo) > 10, "foo is long enough");
> _Static_assert(sizeof(foo) > 10, "foo is too short");
What message is appropriate depends on the nature of what is being
tested, ie, how one thinks of the condition:
#define REQUIRE(e) \
_Static_assert( e, "Implementation requirement not met: " #e )
REQUIRE( CHAR_BIT == 8 );
#define ASSUME(e) \
_Static_assert( e, "Assumption not satisfied: " #e )
ASSUME( FLT_ROUNDS >= 0 );
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-05-22 05:24 +0000 |
| Subject | Re: Terse static_assert (was Re: C++ features for C) |
| Message-ID | <slrnpg7abr.31ka.grahn+nntp@frailea.sa.invalid> |
| In reply to | #130795 |
On Sat, 2018-05-19, Tim Rentsch wrote: > Jorgen Grahn <grahn+nntp@snipabacken.se> writes: > >> On Fri, 2018-05-11, Philipp Klaus Krause wrote: >> >>> Am 11.05.2018 um 19:13 schrieb Thiago Adams: >> >> ... >> >>>> * Terse static_assert >>>> www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3928.pdf >>> >>> I'd consider this one very likely to make it. In fact, so likely, that I >>> already implemented it for SDCC with --std-c2x. It is in SD3, so there >>> could be some decision in Pittsburg later this year. >> >> Good. I remember being very surprised when I discovered that I had to >> invent a message for static_assert, unlike for assert(). > > Bleah. It's trivial to get a terse static assertion without changing > the language: > > #define ASSERT(e) _Static_assert( e, #e ) I guess I'm just disappointed this wasn't standardized. >> I find that message hard to write: should it describe the condition I >> assert (claim) holds, or its negation? >> >> _Static_assert(sizeof(foo) > 10, "foo is long enough"); >> _Static_assert(sizeof(foo) > 10, "foo is too short"); > > What message is appropriate depends on the nature of what is being > tested, ie, how one thinks of the condition: > > #define REQUIRE(e) \ > _Static_assert( e, "Implementation requirement not met: " #e ) > > REQUIRE( CHAR_BIT == 8 ); > > #define ASSUME(e) \ > _Static_assert( e, "Assumption not satisfied: " #e ) > > ASSUME( FLT_ROUNDS >= 0 ); Your examples add an abstraction layer on top of _Static_assert. Fine, but I'd prefer the language to have something, so that each team wouldn't have to come up with one (like we used to do with booleans). /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-22 00:47 -0700 |
| Subject | Re: Terse static_assert (was Re: C++ features for C) |
| Message-ID | <97a8d537-e39c-4c0c-9c59-200dbe59f46c@googlegroups.com> |
| In reply to | #130957 |
On Monday, May 21, 2018 at 10:24:23 PM UTC-7, Jorgen Grahn wrote: > On Sat, 2018-05-19, Tim Rentsch wrote: > > Jorgen Grahn <grahn+nntp@snipabacken.se> writes: > > > >> On Fri, 2018-05-11, Philipp Klaus Krause wrote: > >> > >>> Am 11.05.2018 um 19:13 schrieb Thiago Adams: > >> > >> ... > >> > >>>> * Terse static_assert > >>>> www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3928.pdf > >>> > >>> I'd consider this one very likely to make it. In fact, so likely, that I > >>> already implemented it for SDCC with --std-c2x. It is in SD3, so there > >>> could be some decision in Pittsburg later this year. > >> > >> Good. I remember being very surprised when I discovered that I had to > >> invent a message for static_assert, unlike for assert(). > > > > Bleah. It's trivial to get a terse static assertion without changing > > the language: > > > > #define ASSERT(e) _Static_assert( e, #e ) > > I guess I'm just disappointed this wasn't standardized. > > >> I find that message hard to write: should it describe the condition I > >> assert (claim) holds, or its negation? > >> > >> _Static_assert(sizeof(foo) > 10, "foo is long enough"); > >> _Static_assert(sizeof(foo) > 10, "foo is too short"); > > > > What message is appropriate depends on the nature of what is being > > tested, ie, how one thinks of the condition: > > > > #define REQUIRE(e) \ > > _Static_assert( e, "Implementation requirement not met: " #e ) > > > > REQUIRE( CHAR_BIT == 8 ); > > > > #define ASSUME(e) \ > > _Static_assert( e, "Assumption not satisfied: " #e ) > > > > ASSUME( FLT_ROUNDS >= 0 ); > > Your examples add an abstraction layer on top of _Static_assert. Fine, > but I'd prefer the language to have something, so that each team > wouldn't have to come up with one (like we used to do with booleans). > > /Jorgen > > -- > // Jorgen Grahn <grahn@ Oo o. . . > \X/ snipabacken.se> O o . For the record, taking effort likely researching a problem is never a waste. Thinking you know everything and working to 'prove' owl that it is true? That is a waste ;) How is barely used random neuron firings tied to love of Steven Petruzzellis in any way going to lead to reasoned group posting? No more! -- My Snoring Solution http://jeff-relf.me/Cola_Regs.HTM Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-06-14 03:22 -0700 |
| Subject | Re: Terse static_assert (was Re: C++ features for C) |
| Message-ID | <kfnwov1ekh5.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #130957 |
Jorgen Grahn <grahn+nntp@snipabacken.se> writes: > On Sat, 2018-05-19, Tim Rentsch wrote: > >> Jorgen Grahn <grahn+nntp@snipabacken.se> writes: >> >>> On Fri, 2018-05-11, Philipp Klaus Krause wrote: >>> >>>> Am 11.05.2018 um 19:13 schrieb Thiago Adams: >>> >>> ... >>> >>>>> * Terse static_assert >>>>> www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3928.pdf >>>> >>>> I'd consider this one very likely to make it. In fact, so likely, that I >>>> already implemented it for SDCC with --std-c2x. It is in SD3, so there >>>> could be some decision in Pittsburg later this year. >>> >>> Good. I remember being very surprised when I discovered that I had to >>> invent a message for static_assert, unlike for assert(). >> >> Bleah. It's trivial to get a terse static assertion without changing >> the language: >> >> #define ASSERT(e) _Static_assert( e, #e ) > > I guess I'm just disappointed this wasn't standardized. I see that but I'm not sure why. Building on top of the existing form of _Static_assert gives more control over what message appears and allows the assertion to be expressed more tersely. Both of those properties add value relative to what is being proposed for _Static_assert. >>> I find that message hard to write: should it describe the condition I >>> assert (claim) holds, or its negation? >>> >>> _Static_assert(sizeof(foo) > 10, "foo is long enough"); >>> _Static_assert(sizeof(foo) > 10, "foo is too short"); >> >> What message is appropriate depends on the nature of what is being >> tested, ie, how one thinks of the condition: >> >> #define REQUIRE(e) \ >> _Static_assert( e, "Implementation requirement not met: " #e ) >> >> REQUIRE( CHAR_BIT == 8 ); >> >> #define ASSUME(e) \ >> _Static_assert( e, "Assumption not satisfied: " #e ) >> >> ASSUME( FLT_ROUNDS >= 0 ); > > Your examples add an abstraction layer on top of _Static_assert. Fine, > but I'd prefer the language to have something, so that each team > wouldn't have to come up with one (like we used to do with booleans). The point of the examples was to illustrate different natures of what is being tested. I think it's useful to factor out the commonality by defining macros for the various cases, but that is incidental to the point I was trying to make about what sorts of messages are appropriate in different circumstances.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-05-12 07:59 +1200 |
| Message-ID | <flmb0sFua2iU1@mid.individual.net> |
| In reply to | #130416 |
On 05/12/2018 05:13 AM, Thiago Adams wrote: > > I have a list of features from C++ I would like to > see in C. > > Most of these features can be experimented today in C++. > > One C++ feature list very easy to read is available together > with Visual C++ compiler updates. > > https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/ > > Features I would like in C: You overlooked the potentially most useful feature: real constants and constant expressions. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-05-11 13:28 -0700 |
| Message-ID | <7b110d3e-ddb5-42a0-af99-aa5b0cb30832@googlegroups.com> |
| In reply to | #130427 |
On Friday, May 11, 2018 at 4:59:34 PM UTC-3, Ian Collins wrote:
> On 05/12/2018 05:13 AM, Thiago Adams wrote:
> >
> > I have a list of features from C++ I would like to
> > see in C.
> >
> > Most of these features can be experimented today in C++.
> >
> > One C++ feature list very easy to read is available together
> > with Visual C++ compiler updates.
> >
> > https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/
> >
> > Features I would like in C:
>
> You overlooked the potentially most useful feature: real constants and
> constant expressions.
>
Do you mean?
constexpr double PI2 = 3.141592653589793;
I don't like because of this:
int main() {
constexpr double PI2 = 3.141592653589793;
const double *PI = &PI2;
printf("%p\n", PI);
return 0;
}
Why it has address?
I prefer:
#define PI2 3.141592653589793
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-05-12 10:13 +1200 |
| Message-ID | <flmirtFua2iU2@mid.individual.net> |
| In reply to | #130428 |
On 05/12/2018 08:28 AM, Thiago Adams wrote:
> On Friday, May 11, 2018 at 4:59:34 PM UTC-3, Ian Collins wrote:
>> On 05/12/2018 05:13 AM, Thiago Adams wrote:
>>>
>>> I have a list of features from C++ I would like to
>>> see in C.
>>>
>>> Most of these features can be experimented today in C++.
>>>
>>> One C++ feature list very easy to read is available together
>>> with Visual C++ compiler updates.
>>>
>>> https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/
>>>
>>> Features I would like in C:
>>
>> You overlooked the potentially most useful feature: real constants and
>> constant expressions.
>>
>
> Do you mean?
>
> constexpr double PI2 = 3.141592653589793;
>
>
> I don't like because of this:
>
> int main() {
> constexpr double PI2 = 3.141592653589793;
> const double *PI = &PI2;
>
> printf("%p\n", PI);
> return 0;
> }
>
> Why it has address?
Because you asked for one...
--
Ian.
[toc] | [prev] | [next] | [standalone]
Page 2 of 12 — ← Prev page 1 [2] 3 4 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web