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 1 of 12 [1] 2 3 … 12 Next page →
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-05-11 10:13 -0700 |
| Subject | C++ features for C |
| Message-ID | <11edbfd7-461d-4579-8ac7-a9e84a6b7630@googlegroups.com> |
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 Features with some changes * lambdas without capture * Non-static data member initializers http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2756.htm
[toc] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-11 10:47 -0700 |
| Message-ID | <c31407ab-f45b-4297-ae20-60194ade6053@googlegroups.com> |
| In reply to | #130416 |
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 "#".
> * u8 character literals
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4267.html
For use with generics?
> * Raw string literals
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm
An addition I'd put in here would be an means of encoding an integer-type
expression as a string literal which could be concatenated into other string
literals (the range of values would depend upon whether the other literal was
narrow or wide).
> * Binary literals
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf
Should have been a no-brainer.
> Libraries (adapted to C) that I would like to see.
> * Relative Paths For Filesystem
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0219r1.html
I'd like to see the Standard specify that string concatenation works with
#include paths. As it is, it specifies that given:
#define MY_PATH "a/b/"
#include MY_PATH "hey"
will be processed as:
#include "a/b/" "hey"
but doesn't specify the effect of having multiple string literals following
the #include directive.
> Features with some changes
> * lambdas without capture
>
> * Non-static data member initializers
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2756.htm
How about allowing static const compound literals within expressions, e.g.
foo( &(static const struct woozle){1,2,3});
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-05-11 11:06 -0700 |
| Message-ID | <faaa6e82-f949-42b1-8984-793eeb54d695@googlegroups.com> |
| In reply to | #130418 |
On Friday, May 11, 2018 at 2:48:01 PM UTC-3, supe...@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 "#".
>
> > * u8 character literals
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4267.html
>
> For use with generics?
Just to create utf8 encoded literals.
const char *myutf8str = u8"maçã";
>
> > * Raw string literals
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm
>
> An addition I'd put in here would be an means of encoding an integer-type
> expression as a string literal which could be concatenated into other string
> literals (the range of values would depend upon whether the other literal was
> narrow or wide).
>
> > * Binary literals
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf
>
> Should have been a no-brainer.
>
> > Libraries (adapted to C) that I would like to see.
>
> > * Relative Paths For Filesystem
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0219r1.html
>
> I'd like to see the Standard specify that string concatenation works with
> #include paths. As it is, it specifies that given:
>
> #define MY_PATH "a/b/"
> #include MY_PATH "hey"
>
> will be processed as:
>
> #include "a/b/" "hey"
>
> but doesn't specify the effect of having multiple string literals following
> the #include directive.
>
> > Features with some changes
> > * lambdas without capture
> >
> > * Non-static data member initializers
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2756.htm
>
> How about allowing static const compound literals within expressions, e.g.
>
> foo( &(static const struct woozle){1,2,3});
Interesting.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-05-11 21:52 +0200 |
| Message-ID | <pd4s98$rnm$2@solani.org> |
| In reply to | #130420 |
Am 11.05.2018 um 20:06 schrieb Thiago Adams: > On Friday, May 11, 2018 at 2:48:01 PM UTC-3, supe...@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 "#". >> >>> * u8 character literals >>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4267.html >> >> For use with generics? > > Just to create utf8 encoded literals. > const char *myutf8str = u8"maçã"; > Your example is a string literal. Your example already works in C11. The proposed new feature for C2X would be character literals: char c = u8'a'; Would put an ASCII a into c even if char c = 'a'; uses EBCDIC. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2018-05-11 16:51 -0700 |
| Message-ID | <97829c93-8826-4569-9383-d2c94098f818@googlegroups.com> |
| In reply to | #130426 |
On Friday, May 11, 2018 at 4:52:16 PM UTC-3, Philipp Klaus Krause wrote: > Am 11.05.2018 um 20:06 schrieb Thiago Adams: > > On Friday, May 11, 2018 at 2:48:01 PM UTC-3, supe...@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 "#". > >> > >>> * u8 character literals > >>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4267.html > >> > >> For use with generics? > > > > Just to create utf8 encoded literals. > > const char *myutf8str = u8"maçã"; > > > > Your example is a string literal. Your example already works in C11. > > The proposed new feature for C2X would be character literals: > > char c = u8'a'; > > Would put an ASCII a into c even if > > char c = 'a'; > > uses EBCDIC. > > Philipp Maybe they want something like (?) char32_t c = u8'ç'; char16_t and char32_t http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2249.html
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-05-11 21:35 +0100 |
| Message-ID | <874ljend6q.fsf@bsb.me.uk> |
| In reply to | #130420 |
Thiago Adams <thiago.adams@gmail.com> writes: > On Friday, May 11, 2018 at 2:48:01 PM UTC-3, supe...@casperkitty.com wrote: >> On Friday, May 11, 2018 at 12:14:00 PM UTC-5, Thiago Adams wrote: >> > Features I would like in C: <snip> >> > * u8 character literals >> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4267.html >> >> For use with generics? > > Just to create utf8 encoded literals. > const char *myutf8str = u8"maçã"; C already has that. You talked about u8 *character* literals and linked to the C++ document about those. I can't see much point for u8 character literals as defined. They seem to be a way of saying "this is ASCII". Prior to looking, I expected u8'\xE2\x80\xA2' to be a char32_t with the value 0x2022, but u8'x' literals may have only one x in the range 0-127. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-11 23:39 -0700 |
| Message-ID | <6ea03b01-812e-47b3-b202-3e199c7888fe@googlegroups.com> |
| In reply to | #130420 |
On Friday, May 11, 2018 at 11:06:28 AM UTC-7, Thiago Adams wrote:
> On Friday, May 11, 2018 at 2:48:01 PM UTC-3, supe...@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 "#".
> >
> > > * u8 character literals
> > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4267.html
> >
> > For use with generics?
>
> Just to create utf8 encoded literals.
> const char *myutf8str = u8"maçã";
>
> >
> > > * Raw string literals
> > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2442.htm
> >
> > An addition I'd put in here would be an means of encoding an integer-type
> > expression as a string literal which could be concatenated into other string
> > literals (the range of values would depend upon whether the other literal was
> > narrow or wide).
> >
> > > * Binary literals
> > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf
> >
> > Should have been a no-brainer.
> >
> > > Libraries (adapted to C) that I would like to see.
> >
> > > * Relative Paths For Filesystem
> > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0219r1.html
> >
> > I'd like to see the Standard specify that string concatenation works with
> > #include paths. As it is, it specifies that given:
> >
> > #define MY_PATH "a/b/"
> > #include MY_PATH "hey"
> >
> > will be processed as:
> >
> > #include "a/b/" "hey"
> >
> > but doesn't specify the effect of having multiple string literals following
> > the #include directive.
> >
> > > Features with some changes
> > > * lambdas without capture
> > >
> > > * Non-static data member initializers
> > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2756.htm
> >
> > How about allowing static const compound literals within expressions, e.g.
> >
> > foo( &(static const struct woozle){1,2,3});
>
> Interesting.
At one point, he said a legitimate denizen was "obsessing" over him, which was nothing more than him using his flood script to "boost" his "mentions" count.
Having to put up with the use of Ubuntu is too much for William Poaster to deal with. Calls it "obsessing" over him, even though he proceeds to give rise to that selfsame criterium. He would have to be suffering from a form of insanity to be unsure of whether or not he "never had" purchased a program. Sound like anyone in here? When someone can't remember his past claims and applies dishonest, face saving tripe later, it's completely clear what his ploy is.
But when the stats were run, it turns out beyond any doubt, William Poaster was far more "obsessive" than Jeff Relf.
So, yeah, I buy into my own fancy, fully knowing William Poaster has been fooled, because it makes me reconsider my script, improving it.
--
Eight things to never feed your cat!
http://www.5z8.info/titstitstitstits_j7t4bl_stalin
http://www.5z8.info/hackwebcam_e9z2tw_friendster-of-sex
https://youtu.be/qwb1Ez0GWMA
Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-11 19:20 +0100 |
| Message-ID | <W9lJC.116165$%L2.66724@fx40.am4> |
| In reply to | #130418 |
On 11/05/2018 18:47, supercat@casperkitty.com wrote:
> How about allowing static const compound literals within expressions, e.g.
>
> foo( &(static const struct woozle){1,2,3});
>
If adding something new, then why would you need all this other stuff to
be specified?
foo() surely knows what parameter it takes, presumably a pointer to some
struct, so what is the point of the 'static', the 'const' (since you
can't really write to those 1, 2, 3 values), and the 'struct woozle'?
You can't have (1,2,3) (another handy feature, like a[i,j,k], which is a
victim of C's comma operator). So it has to be at least {1,2,3} which
also matches init-data.
Then it could look like this:
foo(&{1,2,3});
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-11 12:21 -0700 |
| Message-ID | <0be369d8-1808-43ef-b736-0c831ac5b120@googlegroups.com> |
| In reply to | #130421 |
On Friday, May 11, 2018 at 1:20:45 PM UTC-5, Bart wrote:
> On 11/05/2018 18:47, supercat@casperkitty.com wrote:
>
> > How about allowing static const compound literals within expressions, e.g.
> >
> > foo( &(static const struct woozle){1,2,3});
> >
>
> If adding something new, then why would you need all this other stuff to
> be specified?
C99 added compound literals, with the semantics that
struct woozle { int x,y,z; };
foo( &(struct woozle){1,2,3});
is equivalent to having previously declared:
struct woozle { int x,y,z; };
struct woozleWrap { struct woozle addr[1]; };
struct woozleWrap makeWoozle(int x, int y, int z)
{
woozleWrap result = {x,y,z};
return result;
}
and then calling
foo(woozleWrap(1,2,3).addr);
except that the address of the object passed to "foo" would extend until
the next enclosing block. Note that if the compiler doesn't know anything
about "foo", it must pass the address of an object of automatic duration.
What C99 lacked, and C11 still does, is the ability to create and pass
static objects. In most cases where all the members of the literal are
constants, it would be more efficient to have one static object whose
address is used any time a literal with those values is needed, than to
generate new automatic-duration objects all the time, but there's no way
to invite the compiler to do that.
> foo() surely knows what parameter it takes, presumably a pointer to some
> struct, so what is the point of the 'static', the 'const' (since you
> can't really write to those 1, 2, 3 values), and the 'struct woozle'?
What if foo() takes a void*?
> Then it could look like this:
>
> foo(&{1,2,3});
That might be nice for the case where foo() takes a parameter of pointer-
to-the-structure type. For other cases, however, it may be necessary to
specify the type. It would seem a little weird to say that:
foo(&(struct woozle const*){1,2,3});
should behave differently from
foo(&{1,2,3});
in cases where the parameter is of type "const*".
While I'll agree that writing "static const" is ugly, many usage cases could
hide such details within macros.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-05-12 11:09 -0400 |
| Message-ID | <OsDJC.46556$4M6.9195@fx27.iad> |
| In reply to | #130418 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-05-18 20:48 -0700 |
| Message-ID | <kfnzi0wi9vr.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #130449 |
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.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-19 12:59 -0700 |
| Message-ID | <8e62a20f-6617-4ed3-b51c-4749704a6193@googlegroups.com> |
| In reply to | #130792 |
On Friday, May 18, 2018 at 10:48:17 PM UTC-5, Tim Rentsch wrote:
> > 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)
>
> 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.
If nobody was opposed to removing trigraphs entirely, I wouldn't be
either. A lot of the cruft in the language, however, comes about
because of a perceived need to choose between, e.g.,
1. Compilers must remove support for support trigraphs, or
2. Compilers must process string literals like "Huh??" in silly fashion.
rather than seeing an alternative:
3. Provide means by which the marketplace can decide the contexts
where trigraph support is or is not useful, allowing implementations
to reject programs they don't support, but requiring that they
process in defined fashion those programs they don't reject.
One weakness with the present design of "pragma" is that it makes no
distinctions among three situations:
1. Processing the directive may allow a compiler to generate more
efficient code, but a compiler could still generate correct code.
2. A compiler that doesn't understand the directive would be unlikely
to generate correct code.
3. Processing all the directives in a group would allow a compiler to
generate more efficient code, and ignoring all would result in
its generating correct code, but processing some while ignoring
others could yield broken code.
If the standard were to say that a compiler may recognize the line:
??/
as a demand to turn on trigraphs even if they were off (rather than
treating the ??/ as a syntax error), existing compilers would correctly
handle that line by either rejecting code containing it (if they were
not configured to accept trigraphs) or silently ignoring it (if they
would already accept trigraphs). If any compiler writer thought it would
be useful to have compilers automatically enable trigraphs without
requiring manual configuration, they could have their compilers look for
the above line. If no compilers think it's worthwhile, however, that
would be fine to since existing compilers would properly accept or reject
the code as appropriate.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2018-05-22 06:50 +0000 |
| Message-ID | <slrn3sgkpg7fcn.d61.ike@iceland.freeshell.org> |
| In reply to | #130829 |
On 2018-05-19, supercat@casperkitty.com <supercat@casperkitty.com> wrote: > If nobody was opposed to removing trigraphs entirely, I wouldn't be > either. A lot of the cruft in the language, however, comes about > because of a perceived need to choose between, e.g., > > 1. Compilers must remove support for support trigraphs, or > > 2. Compilers must process string literals like "Huh??" in silly fashion. The string literal "Huh??" does not contain a trigraph sequence.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-22 07:39 -0700 |
| Message-ID | <f52412c7-0e85-41fb-bdd3-9e02ebd4d1a9@googlegroups.com> |
| In reply to | #130958 |
On Tuesday, May 22, 2018 at 1:50:14 AM UTC-5, Ike Naar wrote: > On 2018-05-19, supercat@casperkitty.com <supercat@casperkitty.com> wrote: > > If nobody was opposed to removing trigraphs entirely, I wouldn't be > > either. A lot of the cruft in the language, however, comes about > > because of a perceived need to choose between, e.g., > > > > 1. Compilers must remove support for support trigraphs, or > > > > 2. Compilers must process string literals like "Huh??" in silly fashion. > > The string literal "Huh??" does not contain a trigraph sequence. Oops. I think i forgot the exclamation mark. I mean what were they thinking??! Or maybe I got confused because C code for the Macintosh would routinely get tripped on the character literal '????' [which would, in the absence of trigraphs, represent 0x3F3F3F3F; file types, resource types, and many other things on the Macintosh use an unsigned 32-bit integer to encode four ASCII bytes, and being able to use character literals for that is very handy. Because of endian-ness issues, it would probably good to have a multi-byte-character-literal syntax which expressly specifies endianness in which case the construct could be portable.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-22 09:54 -0700 |
| Message-ID | <383d016a-f4eb-48a8-a836-38038449f0fb@googlegroups.com> |
| In reply to | #130967 |
On Tuesday, May 22, 2018 at 7:39:37 AM UTC-7, supe...@casperkitty.com wrote: > On Tuesday, May 22, 2018 at 1:50:14 AM UTC-5, Ike Naar wrote: > > On 2018-05-19, supercat@casperkitty.com <supercat@casperkitty.com> wrote: > > > If nobody was opposed to removing trigraphs entirely, I wouldn't be > > > either. A lot of the cruft in the language, however, comes about > > > because of a perceived need to choose between, e.g., > > > > > > 1. Compilers must remove support for support trigraphs, or > > > > > > 2. Compilers must process string literals like "Huh??" in silly fashion. > > > > The string literal "Huh??" does not contain a trigraph sequence. > > Oops. I think i forgot the exclamation mark. I mean what were they > thinking??! Or maybe I got confused because C code for the Macintosh would > routinely get tripped on the character literal '????' [which would, in the > absence of trigraphs, represent 0x3F3F3F3F; file types, resource types, and > many other things on the Macintosh use an unsigned 32-bit integer to encode > four ASCII bytes, and being able to use character literals for that is very > handy. Because of endian-ness issues, it would probably good to have a > multi-byte-character-literal syntax which expressly specifies endianness > in which case the construct could be portable. Absolute hot air by an ignorant, fabricating, conniving, tag-teaming buffoon who would not tell the truth no matter what his socks/shills say. Linux offers the least of everything to the average user. I'd counter Snit honestly but he's a blockhead who screws around to realize his desire to call everyone a liar. From how Snit posted - by showing ignorance of fundamentals of the Elementary OS and so forth - he's never understood a graphically complex program. Otherwise he would have understood the requirements! -- Live on Kickstarter https://youtu.be/BUjnZhKk1Bg http://www.macadvocacy.pw/2005/Nov/09/236626.html https://groups.google.com/forum/#!topic/comp.os.linux.advocacy/tzMH39QmAmU Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-05-19 16:18 -0400 |
| Message-ID | <GE%LC.74559$7H4.9168@fx12.iad> |
| In reply to | #130792 |
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.
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.
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).
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.
C++ as of C++17 has removed trigraphs from the language.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-19 13:54 -0700 |
| Message-ID | <7cf92e6b-9c0f-4cd3-9eb1-6fb2bd4f96cc@googlegroups.com> |
| In reply to | #130830 |
On Saturday, May 19, 2018 at 3:18:54 PM UTC-5, Richard Damon wrote: > 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). > > 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. Trigraphs wouldn't pose a problem if they weren't processed in string *or character* literals [some platforms routinely use 32-bit values to hold four-character identifiers, and having multi-character literals can be helpful for that, but the literal '????' gets sunk by trigraphs]. The only trigraph sequence that's actually useful in string or character literals is ??/ for backslash, and the need for an escape character could be handled in better ways, especially if the standard were to add a second concatenate-adjacent-literals step within the compiler itself. BTW, I'm curious what character code should be produced for e.g. '??<' on a platform whose execution character set doesn't include the character the trigraph is supposed to represent? Any idea?
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-05-19 18:05 -0400 |
| Message-ID | <ic1MC.93251$pg3.83492@fx29.iad> |
| In reply to | #130832 |
On 5/19/18 4:54 PM, supercat@casperkitty.com wrote:
> BTW, I'm curious what character code should be produced for e.g.
> '??<' on a platform whose execution character set doesn't include the
> character the trigraph is supposed to represent? Any idea?
My understanding of the standard (based on 5.2.1 p3) that a conforming
implementation MUST have a character assigned to every character in the
basic character set (source and execution). That character might not be
commonly thought of as that character though. This is the issue for
source character set, for the source file to be portable from one
environment to another the character used for { should stay being a {
when the file is moved from one machine to another, passing through
normal translation channels. To provide this character stability was a
reason to create tri-/di-graphs, these were codes using well defined
characters to represent these characters so the source was portable. The
implementation would have needed to defined some character to act like
it though. One example of this is that on many machines with a Japanese
character set would use the Yen sign for \. Code putting one of these
problematical characters would just end up with that substitute character.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-06-14 04:27 -0700 |
| Message-ID | <kfnfu1pehfs.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #130830 |
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.
> 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.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-06-14 07:35 -0700 |
| Message-ID | <3eb36798-51fb-4f0b-ab97-780aeff8ba20@googlegroups.com> |
| In reply to | #131640 |
On Thursday, June 14, 2018 at 6:28:01 AM UTC-5, Tim Rentsch wrote:
> 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.
Disabling processing of trigraphs within string or character literals would
cause problems in only one situation: cases where a backslash escape would
be required. Two better remedies for that than trigraphs would be:
1. Require that implementations designate some character as being
semantically equivalent to backslash. It is doubtful that any
implementation that lacks a backslash character would not have
some character outside the C character set it could designate as
a substitute.
2. Provide a #pragma which would allow a program to designate which
character should serve that purpose.
In practice, I suspect every implementation whose source character set does
not have a character that looks like a reverse slash has used approach #1,
and that using that character is nearly always going to be more convenient
than using the ??/ trigraph.
[toc] | [prev] | [next] | [standalone]
Page 1 of 12 [1] 2 3 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web