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 | 17 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 12 of 12 — ← Prev page 1 … 10 11 [12]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-15 13:46 -0700 |
| Message-ID | <ddfe0331-537c-4fb0-8b85-72d7c9c44c59@googlegroups.com> |
| In reply to | #130624 |
On Tuesday, May 15, 2018 at 2:57:00 PM UTC-5, Keith Thompson wrote: > Then you have implemented something similar to C. You have not > implemented C as defined by the standard. (And, as it happens, > you have not implemented anything that I care about.) The C Standard specifies that implementations may have extensions, provided that they do not alter the behavior of strictly conforming programs. It further specifies that all extensions must be documented. Because many implementations behave in useful fashion in cases where the Standard imposes no requirements, but almost none of them document all such cases, regarding such cases as "extensions" that implementations are required to document would make most implementations non-conforming. My reading of the Standard would suggest that compiler behaviors that must be documented as "extensions" are those which would not affect the behavior of strictly conforming programs, but would alter an implementation's behavior in some cases where the Standard would otherwise impose requirements. Since the Standard imposes no requirements on the behavior of an implementation which has issued a diagnostic for a constraint violation not involving the #error directive, nothing that an implementation does with code that causes it to produce such a diagnostic is an "extension". If the compiler unconditionally outputs some message during compilation, and the documentation describes that as a diagnostic meaning "By the way, your program might be using types 'char' and 'unsigned char' in incompatible fashion", that would satisfy the diagnostic requirement associated with that constraint violation. I think it would be more helpful, however, to say that if an implementation documents compatibility between "char" and "unsigned char" as an extension, that would serve the same purpose of letting people know that the compiler is not suitable for purposes of validating that a program does not use char and unsigned char in ways that other compilers would likely reject.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-15 14:43 -0700 |
| Message-ID | <1f01cbcb-b473-43dc-8164-5cb51d5eefc1@googlegroups.com> |
| In reply to | #130624 |
On Tuesday, May 15, 2018 at 12:57:00 PM UTC-7, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: > > On 15/05/2018 19:59, Keith Thompson wrote: > >> bartc <bc@freeuk.com> writes: > >>> Why isn't it C? You make it sound like having a third character type is > >>> a really big deal. > >> > >> It isn't C because C has three distinct character types. I never said > >> it was a "really big deal", just that it's how the language is defined. > > > >> I'm not asking you to care about these facts, just to stop pretending > >> you don't know them. > > > > I didn't know about the third kind of char until recently. I thought it > > was too silly an idea to implement. I also thought that a type called > > 'char' needs to be unsigned. > > > > So I implemented a C where a 'char' type is synonymous with 'unsigned char'. > > > > If that's non-conforming, then it's too bad. I believe this modification > > get rids of some baggage that no one really needs any more. > > Then you have implemented something similar to C. You have not > implemented C as defined by the standard. (And, as it happens, > you have not implemented anything that I care about.) > > You are, of course, free to do exactly that. But again, I'll ask > you, at least when posting to comp.lang.c, to make it clear when > you're talking about your personal almost-C language and when you're > talking about the actual C language as defined by the ISO C 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" Don't get too arrogant, Michael P., sometimes "advocates" are just that. Can you cease seeking for my attention? What did Michael P. have to say about this amazing support from new posters? Most of the time he would try to push the advocates to trust they're long time lurkers who just happened to have unexplained agreement with him. Not only did Doc O'Leary's request not allude to the "DE", it has nada to do with Linux. Michael P. should learn to read ;) -- What Every Entrepreneur Must Know https://www.youtube.com/playlist?list=PLU_evUKollmjeuJy5V5UMotPUs65Q7YM6 http://www.5z8.info/stalin-will-rise-again_j3h5uj_nakedgrandmas.jpg Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-15 09:17 -0700 |
| Message-ID | <lnin7o7v14.fsf@kst-u.example.com> |
| In reply to | #130596 |
bartc <bc@freeuk.com> writes:
> On 15/05/2018 12:23, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>
>> A lot of your objections to c might come down to the fact that you think
>> of programming language constructs as doing thing rather than meaning
>> things.
>
> Yes, in this case both generate the same output:
>
> &"abc";
> "abc";
>
> leads to this code (using my compiler):
>
> mov D0, KK1 # KK1/2 are labels of the string data
> mov D0, KK2 # both are 64-bit pointer loads
Assembly code does not define the semantics of C code.
C code ultimately specifies run-time behavior. The machine code output
of a compiler is an implementation detail meant to accomplish that
behavior.
char *p0 = "abc"; /* This is legal */
char *p1 = &"abc"; /* This is a constraint violation */
--
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-15 18:20 +0100 |
| Message-ID | <wFEKC.216799$jZ.154760@fx20.am4> |
| In reply to | #130613 |
On 15/05/2018 17:17, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
>> On 15/05/2018 12:23, Ben Bacarisse wrote:
>>> bartc <bc@freeuk.com> writes:
>>
>>> A lot of your objections to c might come down to the fact that you think
>>> of programming language constructs as doing thing rather than meaning
>>> things.
>>
>> Yes, in this case both generate the same output:
>>
>> &"abc";
>> "abc";
>>
>> leads to this code (using my compiler):
>>
>> mov D0, KK1 # KK1/2 are labels of the string data
>> mov D0, KK2 # both are 64-bit pointer loads
>
> Assembly code does not define the semantics of C code.
You never have any use for looking at the output of a compiler? OK.
But some of us do often find it useful to render a perhaps confusing bit
of source via a compiler that is simple enough to strip away the
irrelevancies while necessarily keeping the essentials, without removing
too much or adding extraneous detail.
And in this case it tells me that, despite the imbalance due to the &,
evaluating these involves essentially the same operations.
> C code ultimately specifies run-time behavior. The machine code output
> of a compiler is an implementation detail meant to accomplish that
> behavior.
>
> char *p0 = "abc"; /* This is legal */
> char *p1 = &"abc"; /* This is a constraint violation */
And the following is legal:
char (*p2)[] = &"abc";
But which one of p0 and p2, if any involves more fundamental operations?
I know, a good way might be to convert it to lower level code and see
what it gets up to.
If p0 and p1 are both static, there are no runtime operations, but the
initialisation data is identical. Non-static, they are also exactly the
same run-time operations.
Sometimes it is useful to view code with all the high level type info
stripped out and only the basic data operations left, so that you
dealing with values of 1, 2, 4 or 8 bytes, and with 0, 1, 2 etc levels
of indirection.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-05-15 17:38 +0000 |
| Message-ID | <hWEKC.170459$w94.165407@fx43.iad> |
| In reply to | #130615 |
bartc <bc@freeuk.com> writes: >On 15/05/2018 17:17, Keith Thompson wrote: >> bartc <bc@freeuk.com> writes: >>> On 15/05/2018 12:23, Ben Bacarisse wrote: >>>> bartc <bc@freeuk.com> writes: >>> >>>> A lot of your objections to c might come down to the fact that you think >>>> of programming language constructs as doing thing rather than meaning >>>> things. >>> >>> Yes, in this case both generate the same output: >>> >>> &"abc"; >>> "abc"; >>> >>> leads to this code (using my compiler): >>> >>> mov D0, KK1 # KK1/2 are labels of the string data >>> mov D0, KK2 # both are 64-bit pointer loads >> >> Assembly code does not define the semantics of C code. > >You never have any use for looking at the output of a compiler? OK. That's not what he said. [snip]
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-15 11:13 -0700 |
| Message-ID | <lna7t07po2.fsf@kst-u.example.com> |
| In reply to | #130615 |
bartc <bc@freeuk.com> writes:
> On 15/05/2018 17:17, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>>> On 15/05/2018 12:23, Ben Bacarisse wrote:
>>>> bartc <bc@freeuk.com> writes:
>>>> A lot of your objections to c might come down to the fact that you think
>>>> of programming language constructs as doing thing rather than meaning
>>>> things.
>>>
>>> Yes, in this case both generate the same output:
>>>
>>> &"abc";
>>> "abc";
>>>
>>> leads to this code (using my compiler):
>>>
>>> mov D0, KK1 # KK1/2 are labels of the string data
>>> mov D0, KK2 # both are 64-bit pointer loads
>>
>> Assembly code does not define the semantics of C code.
>
> You never have any use for looking at the output of a compiler? OK.
I didn't say or imply that. (As it happens I rarely do, just because
I'm not all that familiar with most assembly languages.)
Looking back upthread to your previous statement, you said that:
... &"abc" and "abc" do the same thing ...
It's true that *in some contexts* they can "do the same thing"
(if by that you mean that they have the same runtime behavior).
For example, if they both appear as expression statements, as in:
int main(void) {
&"abc";
"abc";
}
then they "do the same thing", namely nothing. More meaningfully, this:
#include <stdio.h>
int main(void) {
printf("%p\n", (void*)&"abc");
printf("%p\n", (void*)"abc");
}
will print the same line twice *if* the two string literals share the
same location.
In other contexts, such as:
int main(void) {
char *p;
p = &"abc";
p = "abc";
}
they do very different things; the first is a constraint violation.
It's odd that someone who's written a C compiler wouldn't care about
such things.
--
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 | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-15 06:40 -0700 |
| Message-ID | <4b330341-ad70-4244-8e72-4f1e49a2f2ec@googlegroups.com> |
| In reply to | #130595 |
On Tuesday, May 15, 2018 at 4:23:23 AM UTC-7, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: > > > On 15/05/2018 08:26, David Brown wrote: > <snip> > >> But what I really don't see is any benefit in /not/ being able to > >> evaluate &PI. > > > > The benefit is consistency with every other case where you can't use > > &: results of operations, results of functions, integer literals, > > float literals**, and enum names. In all cases where there no named > > storage location to which it can sensibly apply. > > C is, very largely, consistent here. You can take the address of > objects and not of values. There are some exceptions: you can take the > address of a function (not an object) and can't take the address of bit > fields and objects declared with register. > > To a large extent, what is consistent depends on understanding the > underlying model. One language often looks inconsistent in relation to > another if the concepts of one have been used to try to understand the > other. This may be particularly true of C's const. > > > (** There is an odd exception in being able to apply & to string > > literals, > > It looks odd unless you think of literals as being more general than you > seem to think. There is not reason why a literal can't designate an > object rather than a value. That's what compound literals are all > about, but C had literals that denote objects long before that with > string literals. > > > although &"abc" and "abc" do the same thing. > > No they don't, and I am pretty sure you know that by now. > > A lot of your objections to c might come down to the fact that you think > of programming language constructs as doing thing rather than meaning > things. > > -- > Ben. Here are some of the scripted posts from Jonas Eklundh... the script adds a nonsense or irrelevant insult or accusation after most sentences and adds numbers to the text so he can better track his trolling: <https://groups.google.com/d/msg/comp.os.linux.advocacy/RZtEyvJr8HI/VcEqOk2qCgAJ> or <https://goo.gl/67NLfr>. You can see a run of three scripted flood posts from his primary account. From: Sandman <mr@sandman.net> Message-ID: <sandman-b7df8761d3b6831e96d5976e9e67f379@individual.net> X-Trace: individual.net +MPBYFbnugFd2iPraU5I9ABV/5ZlNHtqj79Ij19mAYCfL5sHI= User-Agent: Sandmania 2.0 He also has them elsewhere, here are some examples: <https://groups.google.com/d/msg/comp.os.linux.advocacy/Xetqyi1T0F0/cvoqp3eqCgAJ> OR <https://goo.gl/jy0rsr>. <https://groups.google.com/d/msg/comp.os.linux.advocacy/10d0Emx_ABk/eN0r1_epCgAJ> OR <https://goo.gl/Rkz0PO>. On that one he has a run of two. And a longer and clearly scripted, content-free flood post: <https://groups.google.com/d/msg/comp.os.linux.advocacy/2WS3xlecnw8/lizfGLOnCgAJ> OR <https://goo.gl/t7cTHd>. And even more! <https://groups.google.com/d/msg/comp.os.linux.advocacy/cYutxNP1hWc/KZikieXECgAJ> OR <https://goo.gl/Z6G7Ic> <https://groups.google.com/d/msg/comp.os.linux.advocacy/RZtEyvJr8HI/6sJfxaDECgAJ> OR <https://goo.gl/mTXlFt> Lots more but that is enough to prove the point multiple times over. Sandman has been flooding not just with his Google accounts but with his standard account. ALL of those come from the same source I listed above and it is Sandman's standard account. Jonas Eklundh: busted. -- "You'll notice how quickly he loses interest when everything is about him. He clearly wants the attention" Steven Petruzzellis, making the dumbest comment ever uttered.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-15 09:12 -0700 |
| Message-ID | <lnmux07v9a.fsf@kst-u.example.com> |
| In reply to | #130591 |
bartc <bc@freeuk.com> writes:
[...]
> (** There is an odd exception in being able to apply & to string
> literals, although &"abc" and "abc" do the same thing. "abc" already
> results in the address of a location where "abc" is stored, an address
> which doesn't itself have any location, so that & of that address is
> meaningless. But it works because & is applied before that address is
> derived.)
No, &"abc" and "abc" are not equivalent.
&"abc" yields a pointer value of type char(*)[4]. "abc" is an
lvalue of type char[4]; when used in a context that invokes an
array-to-pointer conversion, it yields a pointer value of type char*.
Both pointer values refer to the same location, but they're of
different types.
Come one, bart, you know this stuff.
--
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 | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-15 03:33 -0700 |
| Message-ID | <f3641db4-6146-496f-bf45-d3cdf51f4041@googlegroups.com> |
| In reply to | #130589 |
On Tuesday, May 15, 2018 at 12:26:27 AM UTC-7, David Brown wrote: > On 14/05/18 22:46, Keith Thompson wrote: > > Thiago Adams <thiago.adams@gmail.com> writes: > > [...] > >> I don't see in this case, a usage to take the address of PI. > >> PI is not a variable. If I need a variable then I can declare > >> a variable, or something with storage and constant and set PI. > >> > >> A variable has type and some size. PI doesn't. > >> > >> #define PI 3.14 > >> const double DoublePiVar = PI; > >> const float FloatPiVar = PI; > >> > >> > >> > >> > >>>> Just to clarify, from my perceptive, the problem is not only > >>>> take the address but is not have a precise and explicit control > >>>> about storage. > >>> > >>> I'm not sure what you are trying to say here. > >> > >> I don't want to leave the storage decision > >> (if the constant use memory or not ) for the compiler > >> or affect by my colleague checkin. > >> I prefer to be sure that the value is not using memory. > >> Particularity I don't feel conformable with the idea. > > That is not something you have direct control over in C. A compiler can > put literals or #define'd values in memory - conversely, it can avoid > memory storage for const objects. All you get is that the object code > will act as though the compiler followed your source code slavishly, to > the extend that the behaviour is visible via defined behaviour in the > code. Exactly how this is achieved, and what is placed where, is up to > the implementation. > > If you want direct micro-management over such storage decisions, C is > not the language you want. (Or at least, C using common off-the-shelf > compilers is not what you want - an implementation /can/ give you more > control.) > > > > > PI (more precisely, the result of expanding the macro PI) does have a > > type and a size. Its type is double (like any unsuffixed floating-point > > constant), and its size is sizeof (double). > > > > `sizeof PI` and `sizeof 3.14` are both likely to yield 8 under typical > > implementations. > > > > That type and size information is discarded when the value is converted > > as it is in the initializations of DoublePiVar and FloatPiVar. > > > > I agree that there's no great benefit in being able to evaluate &PI. > > > > I also don't see a big benefit in being able to evaluate &PI - but there > might occasionally be use in passing such fixed values by reference. It > would make a bigger difference if the type were of bigger size, enough > to make pass-by-reference more efficient. > > But what I really don't see is any benefit in /not/ being able to > evaluate &PI. > > (I see a benefit in language or compiler protections against abusing > that &PI pointer.) What I do is certainly more productive. So, yeah, I buy into my own fancy, fully knowing it is not real, because it makes me reconsider my program, improving it. I am working on an idea which will show off how weak Unity is. From what I've seen it looks like the Unity ecosystem got more sophisticated. vallor must know everyone knows he is just lying. What Unity looks like is what it is and not worth obsessing over, especially if it's support is good. If you have 'b.pdf' open in a program such as vim and you want to change its name to 'd.pdf' via a hot key, RonB's method might be of value. Clearly there are too many "lowest common denominator is fine" Unity users and not enough power users with the skills to help the people with Macs. -- My Snoring Solution http://www.5z8.info/mydick_x6g9hr_nakedgrandmas.jpg https://groups.google.com/forum/#!topic/comp.sys.mac.advocacy/RSikBcWxBLo Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-15 09:09 -0700 |
| Message-ID | <lnr2mc7vew.fsf@kst-u.example.com> |
| In reply to | #130589 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> I also don't see a big benefit in being able to evaluate &PI - but there
> might occasionally be use in passing such fixed values by reference. It
> would make a bigger difference if the type were of bigger size, enough
> to make pass-by-reference more efficient.
>
> But what I really don't see is any benefit in /not/ being able to
> evaluate &PI.
>
> (I see a benefit in language or compiler protections against abusing
> that &PI pointer.)
Do you see any benefit in not being able to apply "&" to an
enumeration constant? Or an integer constant?
What some of us would like is a way to associate a name with a
constant expression of arbitrary scalar type, without defining
a macro. Constant expressions don't have addresses. Not being
able to apply "&" to such a name is more a matter of conceptual
elegance and consistency than of practical need.
One (perhaps rather inelegant) solution would be to allow specifying
a scalar type for an enum. Currently we can write
enum { answer = 42 };
and get exactly the behavior some of us are looking for (but only for
type int). If we could write something like:
enum : double { pi = 22.0/7.0 };
or even
enum : void* { NULL = 0 };
to make pi and NULL constant expressions (with no associated
storage, even in the abstract machine), that would provide just
the functionality some of us would like.
(Using 22.0/7.0 for pi was a joke, in case anyone was going to
complain about it.)
--
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 23:45 +0200 |
| Message-ID | <pdfkej$gm6$1@dont-email.me> |
| In reply to | #130610 |
On 15/05/18 18:09, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> I also don't see a big benefit in being able to evaluate &PI - but there
>> might occasionally be use in passing such fixed values by reference. It
>> would make a bigger difference if the type were of bigger size, enough
>> to make pass-by-reference more efficient.
>>
>> But what I really don't see is any benefit in /not/ being able to
>> evaluate &PI.
>>
>> (I see a benefit in language or compiler protections against abusing
>> that &PI pointer.)
>
> Do you see any benefit in not being able to apply "&" to an
> enumeration constant? Or an integer constant?
It don't see any /use/ of being able to apply "&" to a C constant.
Constants in C are small enough that you would pass them by value, so
taking an address or passing by reference is not going to give you any
benefit.
But I am not sure I see any harm if it /were/ possible, with semantics
approximately like:
extern foo(const int * p);
void bar(void) {
foo(&1234);
}
meaning:
void bar(void) {
const int temp = 1234;
foo(&temp);
}
Such a concept is legal in C++ with references, which are (at least
here) basically like pointers with different syntax.
And if there is no harm in being able to take the address of a constant,
what benefit is there in /not/ being able to do so?
For a more general non-variable thing that could replace C's current
non-variable things (constants, enums, #define'd constants, and const
objects), being able to take an address /would/ be useful. It would, in
particular, be useful for larger non-variables - just as it is useful
for larger const objects today.
>
> What some of us would like is a way to associate a name with a
> constant expression of arbitrary scalar type, without defining
> a macro.
Like const objects in C++, that can be used as constant expressions? I
would certainly like to import (at least most of) C++'s const
improvements to C.
> Constant expressions don't have addresses.
Saying something "has an address" implies a uniqueness to the address.
That is the case for const objects. But it is not the case for constant
expressions - nor is it necessarily the case in C++ when taking a
reference to a constant expression.
Being able to apply & to something does not necessarily mean that
something has an address as such - it is enough for the compiler to be
able to produce an appropriate and useful address when needed. In C++
when taking a reference to a constant expression, if there is not
already a "real" address (such as for a const object), then it creates a
temporary and gives the address of that. Equally, the compiler could
choose to allocate specific storage, perhaps in a read-only data
section, and give the address of that.
> Not being
> able to apply "&" to such a name is more a matter of conceptual
> elegance and consistency than of practical need.
It limits the use of a new non-variable concept. That means the new
concept would be /adding/ to the list of non-variable structures we have
in C, not simplifying it or replacing them.
>
> One (perhaps rather inelegant) solution would be to allow specifying
> a scalar type for an enum. Currently we can write
> enum { answer = 42 };
> and get exactly the behavior some of us are looking for (but only for
> type int). If we could write something like:
> enum : double { pi = 22.0/7.0 };
> or even
> enum : void* { NULL = 0 };
> to make pi and NULL constant expressions (with no associated
> storage, even in the abstract machine), that would provide just
> the functionality some of us would like.
>
That would be a possibility. But I think it would be easier and more
elegant to say that after "const double pi = 22.0 / 7.0;", "pi" is a
constant expression, and that "static int x[(int) pi];" should be
allowed (plus any other uses of constant expressions, of course).
> (Using 22.0/7.0 for pi was a joke, in case anyone was going to
> complain about it.)
>
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2018-05-17 18:49 +0000 |
| Message-ID | <slrn3suopfrjko.8pv.ike@iceland.freeshell.org> |
| In reply to | #130631 |
On 2018-05-15, David Brown <david.brown@hesbynett.no> wrote: > extern foo(const int * p); Implicit int is a wart from the past. Perhaps extern void foo(const int * p); would be more appropriate.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-17 22:49 +0200 |
| Message-ID | <pdkpta$8to$3@dont-email.me> |
| In reply to | #130724 |
On 17/05/18 20:49, Ike Naar wrote: > On 2018-05-15, David Brown <david.brown@hesbynett.no> wrote: >> extern foo(const int * p); > > Implicit int is a wart from the past. Perhaps > > extern void foo(const int * p); > > would be more appropriate. > I entirely agree - that was what I intended to write. Sorry for the slip.
[toc] | [prev] | [next] | [standalone]
| From | Chad <cdalten@gmail.com> |
|---|---|
| Date | 2018-05-11 15:46 -0700 |
| Message-ID | <4a583e3f-c6e1-4793-8a5a-efb94f8c4ec9@googlegroups.com> |
| In reply to | #130416 |
On Friday, May 11, 2018 at 10:14:00 AM UTC-7, 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: > > * Removing trigraphs > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4086.html > > * u8 character literals > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4267.html > > * Terse static_assert > www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3928.pdf > > * Removing operator++ for bool > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0002r1.html > > * __has_include > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0061r1.html > > * Selection statements with initializers > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r1.html > > from older list > > https://blogs.msdn.microsoft.com/vcblog/2014/11/17/c111417-features-in-vs-2015-preview/ > > > * Raw string literals > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm > > > > > * Binary literals > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf > > * Digit separators > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3781.pdf > > > Libraries (adapted to C) that I would like to see. > > * <filesystem> > > * Relative Paths For Filesystem > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0219r1.html > > I *think* having relative paths for Fileystem would probably do more harm in the long run.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-11 16:13 -0700 |
| Message-ID | <bcef2adb-f3ce-4735-b0ef-e604efc2fcad@googlegroups.com> |
| In reply to | #130433 |
On Friday, May 11, 2018 at 5:47:11 PM UTC-5, Chad wrote: > On Friday, May 11, 2018 at 10:14:00 AM UTC-7, 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: > > > > * Removing trigraphs > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4086.html > > > > * u8 character literals > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4267.html > > > > * Terse static_assert > > www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3928.pdf > > > > * Removing operator++ for bool > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0002r1.html > > > > * __has_include > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0061r1.html > > > > * Selection statements with initializers > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r1.html > > > > from older list > > > > https://blogs.msdn.microsoft.com/vcblog/2014/11/17/c111417-features-in-vs-2015-preview/ > > > > > > * Raw string literals > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm > > > > > > > > > > * Binary literals > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf > > > > * Digit separators > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3781.pdf > > > > > > Libraries (adapted to C) that I would like to see. > > > > * <filesystem> > > > > * Relative Paths For Filesystem > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0219r1.html > > > > > > I *think* having relative paths for Fileystem would probably do more harm in the long run. In what contexts does C have any concept of file paths as anything other than strings with implementation-defined meaning?
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2018-05-11 16:52 -0700 |
| Message-ID | <pd5aca$lro$1@dont-email.me> |
| In reply to | #130416 |
On 5/11/2018 10:13 AM, Thiago Adams wrote:
>
> * Selection statements with initializers
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r1.html
>
The main rationale for this feature in C++ is to ensure that the
lifetime of declared object is limited to that selection statement, i.e.
to make sure that the destructor of the declared object is implicitly
called at the end of that selection statement. The user will not have to
enclose the statement and the accompanying declaration into a
"superfluous" pair of `{ ... }` to enforce that lifetime and that
implicit destructor call.
In C this issue simply does not exist, since C does not support
implicitly-callable destructors. The feature might have some cosmetic
value for C code as well, but I don't think it is worth it for the
cosmetic value alone.
--
Best regards,
Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-05-11 16:56 -0700 |
| Message-ID | <1c9cd323-dc2d-4ad9-9d4a-0e7fd126de93@googlegroups.com> |
| In reply to | #130438 |
On Friday, May 11, 2018 at 8:52:50 PM UTC-3, Andrey Tarasevich wrote:
> On 5/11/2018 10:13 AM, Thiago Adams wrote:
> >
> > * Selection statements with initializers
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r1.html
> >
>
> The main rationale for this feature in C++ is to ensure that the
> lifetime of declared object is limited to that selection statement, i.e.
> to make sure that the destructor of the declared object is implicitly
> called at the end of that selection statement. The user will not have to
> enclose the statement and the accompanying declaration into a
> "superfluous" pair of `{ ... }` to enforce that lifetime and that
> implicit destructor call.
>
> In C this issue simply does not exist, since C does not support
> implicitly-callable destructors. The feature might have some cosmetic
> value for C code as well, but I don't think it is worth it for the
> cosmetic value alone.
>
I would use this feature in this way:
if (X* pX = malloc(sizeof * pX); pX)
{
free(pX);
}
//pX error
The scope of pX is reduced where pX != 0;
if (FILE* f = fopen("aa","r"); f)
{
close(f);
}
[toc] | [prev] | [standalone]
Page 12 of 12 — ← Prev page 1 … 10 11 [12]
Back to top | Article view | comp.lang.c
csiph-web