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 9 of 12 — ← Prev page 1 … 7 8 [9] 10 11 12 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-05-15 12:23 +0100 |
| Message-ID | <87po1xi2n1.fsf@bsb.me.uk> |
| In reply to | #130591 |
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.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-15 13:27 +0100 |
| Message-ID | <enAKC.256815$CH6.230683@fx01.am4> |
| In reply to | #130595 |
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
That it is odd is because you normally expect evaluating '&something' to
involve one level of indirection less (or fewer if you like) than just
'something':
static int abc;
...
&abc;
abc;
leads to:
mov D0, abc # (64-bit pointer load)
mov A0, [abc] # (32-bit int value load)
That &"abc" and "abc" may result in different types is not relevant
here. (My compiler tells me the first is 'unsigned char**' and the
second is 'unsigned char*'.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-05-15 16:19 +0100 |
| Message-ID | <87k1s5hror.fsf@bsb.me.uk> |
| 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";
Output? That's a metaphor, but not one I find helpful. They are
expressions with different meanings. They can't even be validly
compared ("abc" == &"abc" must generate a diagnostic).
For more practical examples of the differences, put them into various
expressions:
&"abc" + 1 vs. "abc" + 1
sizeof &"abc" vs. sizeof "abc"
*&"abc" vs. *"abc"
and so on.
> That &"abc" and "abc" may result in different types is not relevant
> here.
That's partly what I was getting at. It does matter, because what
matters in most programming languages is what a construct means, not
what it "does" (whatever that might refer to -- I'm not entirely sure).
> (My compiler tells me the first is 'unsigned char**' and the second is
> 'unsigned char*'.)
There is no "may" here -- they are of expressions of different types.
The first type has type char (*)[4], not unsigned char **, and the
second has type char *. I'm not sure where the unsigned comes from in
your case.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-15 08:29 -0700 |
| Message-ID | <4d34b7c9-8c9b-48ed-9207-750ddfae352c@googlegroups.com> |
| In reply to | #130607 |
On Tuesday, May 15, 2018 at 8:19:58 AM UTC-7, Ben Bacarisse 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";
>
> Output? That's a metaphor, but not one I find helpful. They are
> expressions with different meanings. They can't even be validly
> compared ("abc" == &"abc" must generate a diagnostic).
>
> For more practical examples of the differences, put them into various
> expressions:
>
> &"abc" + 1 vs. "abc" + 1
> sizeof &"abc" vs. sizeof "abc"
> *&"abc" vs. *"abc"
>
> and so on.
>
> > That &"abc" and "abc" may result in different types is not relevant
> > here.
>
> That's partly what I was getting at. It does matter, because what
> matters in most programming languages is what a construct means, not
> what it "does" (whatever that might refer to -- I'm not entirely sure).
>
> > (My compiler tells me the first is 'unsigned char**' and the second is
> > 'unsigned char*'.)
>
> There is no "may" here -- they are of expressions of different types.
> The first type has type char (*)[4], not unsigned char **, and the
> second has type char *. I'm not sure where the unsigned comes from in
> your case.
>
> --
> Ben.
Jerry 'The Flooder' Stuckle is often seen posting "CANNOT BE FOUND" when it comes to info on the Internet where it is written with other words... but Jerry 'The Flooder' Stuckle is just too daft or lazy to interpret any instruction he sees.
Too much glue for you, Gluehead.
HA!
Why does Jerry 'The Flooder' Stuckle focus on his own ego so much? Jerry 'The Flooder' Stuckle was once again a phony by pretending to not engage JF Mezei by means of emphatically shouting 'Into the bin with you!' and then berating him anyhow by means of a 3rd party.
You won't go into a social event, knock back all the hard stuff, sexually assault all the herd animals, take the decorations, and vomit in the john without being observed.
It was Jerry 'The Flooder' Stuckle who stated that he and his college buddies used to copy others all the time and it was no big deal. These posts are clearly NOT automated, they are made by a glue sniffing stalker with a personal vendetta who has way too much time on his hands.
--
This Trick Gets Women Hot For You
http://www.5z8.info/-php-deactivate_phishing_filter-48-_e3m8dt_malicious-cookie
Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-15 17:18 +0100 |
| Message-ID | <uLDKC.281101$nr7.194216@fx31.am4> |
| In reply to | #130607 |
On 15/05/2018 16:19, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: >> (My compiler tells me the first is 'unsigned char**' and the second is >> 'unsigned char*'.) > > There is no "may" here -- they are of expressions of different types. > The first type has type char (*)[4], not unsigned char **, and the > second has type char *. I'm not sure where the unsigned comes from in > your case. The special exception for & was not being applied to "...", as it is for sizeof, so it just wrapped an extra pointer level around "...". The unsigned char is because I deliberately don't support plain char; it must be either signed or unsigned rather than unspecified, and I chose to make it unsigned. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-15 10:23 -0700 |
| Message-ID | <lnefic7rys.fsf@kst-u.example.com> |
| In reply to | #130614 |
bartc <bc@freeuk.com> writes:
> On 15/05/2018 16:19, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>>> (My compiler tells me the first is 'unsigned char**' and the second is
>>> 'unsigned char*'.)
>>
>> There is no "may" here -- they are of expressions of different types.
>> The first type has type char (*)[4], not unsigned char **, and the
>> second has type char *. I'm not sure where the unsigned comes from in
>> your case.
>
> The special exception for & was not being applied to "...", as it is for
> sizeof, so it just wrapped an extra pointer level around "...".
>
> The unsigned char is because I deliberately don't support plain char; it
> must be either signed or unsigned rather than unspecified, and I chose
> to make it unsigned.
Please make it clear when you're talking about a language than C.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-15 19:23 +0100 |
| Message-ID | <NAFKC.18766$463.5198@fx21.am4> |
| In reply to | #130616 |
On 15/05/2018 18:23, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: >> On 15/05/2018 16:19, Ben Bacarisse wrote: >>> bartc <bc@freeuk.com> writes: >>>> (My compiler tells me the first is 'unsigned char**' and the second is >>>> 'unsigned char*'.) >>> >>> There is no "may" here -- they are of expressions of different types. >>> The first type has type char (*)[4], not unsigned char **, and the >>> second has type char *. I'm not sure where the unsigned comes from in >>> your case. >> >> The special exception for & was not being applied to "...", as it is for >> sizeof, so it just wrapped an extra pointer level around "...". >> >> The unsigned char is because I deliberately don't support plain char; it >> must be either signed or unsigned rather than unspecified, and I chose >> to make it unsigned. > > Please make it clear when you're talking about a language than C. Why isn't it C? You make it sound like having a third character type is a really big deal. Give me an example where it really matters (ie. having 'char' mapped to 'unsigned char' or 'signed char', instead of it being an incompatible type). And I don't mean just coercing a compiler into giving a warning or error. Actually, have the compilers I tried don't really care. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-15 11:59 -0700 |
| Message-ID | <ln603o7niu.fsf@kst-u.example.com> |
| In reply to | #130620 |
bartc <bc@freeuk.com> writes:
> On 15/05/2018 18:23, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>>> On 15/05/2018 16:19, Ben Bacarisse wrote:
>>>> bartc <bc@freeuk.com> writes:
>>>>> (My compiler tells me the first is 'unsigned char**' and the second is
>>>>> 'unsigned char*'.)
>>>>
>>>> There is no "may" here -- they are of expressions of different types.
>>>> The first type has type char (*)[4], not unsigned char **, and the
>>>> second has type char *. I'm not sure where the unsigned comes from in
>>>> your case.
>>>
>>> The special exception for & was not being applied to "...", as it is for
>>> sizeof, so it just wrapped an extra pointer level around "...".
>>>
>>> The unsigned char is because I deliberately don't support plain char; it
>>> must be either signed or unsigned rather than unspecified, and I chose
>>> to make it unsigned.
>>
>> Please make it clear when you're talking about a language than C.
>
> 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.
> Give me an example where it really matters (ie. having 'char' mapped to
> 'unsigned char' or 'signed char', instead of it being an incompatible
> type). And I don't mean just coercing a compiler into giving a warning
> or error.
>
> Actually, have the compilers I tried don't really care.
This:
unsigned char *p = "abc";
is a constraint violation. C compilers that don't at least warn
about it are non-conforming. (gcc by default is far more lax than
I would prefer, but as you know by now it's possible to invoke
it in a mode that causes to to at least try to be conforming.
You also know by now that diagnosing a constraint violation with
a non-fatal warning is permitted by the standard.)
I'm not asking you to care about these facts, just to stop pretending
you don't know them.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-15 20:20 +0100 |
| Message-ID | <rqGKC.218814$EL2.160567@fx37.am4> |
| In reply to | #130622 |
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. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-15 12:56 -0700 |
| Message-ID | <ln1sec7kvw.fsf@kst-u.example.com> |
| In reply to | #130623 |
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"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-15 21:01 +0100 |
| Message-ID | <V0HKC.130194$Ze.66364@fx39.am4> |
| In reply to | #130624 |
On 15/05/2018 20:56, 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. What are the practical implications of not having a distinct third character type? What programs will I not be able to write? Which ones will I not be able to compile?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-15 13:15 -0700 |
| Message-ID | <lnwow465fx.fsf@kst-u.example.com> |
| In reply to | #130625 |
bartc <bc@freeuk.com> writes:
> On 15/05/2018 20:56, 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.
>
> What are the practical implications of not having a distinct third
> character type?
>
> What programs will I not be able to write? Which ones will I not be able
> to compile?
Ok, let's assume an otherwise conforming C compiler which treates `char`
and `unsigned char` as the same type.
This conforming program would fail to compile:
#include <stdio.h>
int main(void) {
printf("\"abc\"[0] is of type %s\n",
_Generic("abc"[0],
char: "char",
unsigned char: "unsigned char",
signed char: "signed char"));
}
I admit that's a bit contrived, but I can imagine similar constructs
being useful.
A more likely problem is that someone using such a compiler would write
code that would compile and run, and later find that it's rejected by
some other compiler. For example:
unsigned char *data = "abcd";
which is a constraint violation in standard C.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-15 22:36 +0100 |
| Message-ID | <MpIKC.149973$eg.73445@fx43.am4> |
| In reply to | #130626 |
On 15/05/2018 21:15, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
>> What are the practical implications of not having a distinct third
>> character type?
>>
>> What programs will I not be able to write? Which ones will I not be able
>> to compile?
>
> Ok, let's assume an otherwise conforming C compiler which treates `char`
> and `unsigned char` as the same type.
>
> This conforming program would fail to compile:
>
> #include <stdio.h>
> int main(void) {
> printf("\"abc\"[0] is of type %s\n",
> _Generic("abc"[0],
> char: "char",
> unsigned char: "unsigned char",
> signed char: "signed char"));
> }
>
> I admit that's a bit contrived, but I can imagine similar constructs
> being useful.
I had to tweak my compiler so as not to widen the expression used in
Generic (otherwise it would fail to find a match for 'unsigned int'),
and then it worked (matching 'char').
Presumably the error you're looking for is that the list of Generic
cases includes two compatible types (char and unsigned char).
I don't get that because I don't bother checking if there is more than
one match. (It's only a 40-line implementation of Generic created to
compile one posted example. But I can get that error with 3 extra lines.)
However, you will likely find the same problem when using types such as
int and int32_t, or unsigned char and int8_t, because a lot of the types
in stdint.h are typedefs of standard ones, so the whole thing is a bit
of a mess anyway.
And actually, of my other 6 compilers, 3 failed to compile it because
they don't support Generic, including MSVC.
> A more likely problem is that someone using such a compiler would write
> code that would compile and run, and later find that it's rejected by
> some other compiler.
Yes, I get that quite often, on code that has been passed by gcc, but
fails with mine because it's stricter.
For example:
>
> unsigned char *data = "abcd";
>
> which is a constraint violation in standard C.
>
Warning with Pelles C, gcc (-Wall etc)
Error with DMC
Nothing with MSVC, lccwin, tcc, gcc (default)
Error with mine, when I change it to signed (because "abcd" already has
unsigned chars).
So it doesn't really look like many compilers take it that seriously.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-15 14:59 -0700 |
| Message-ID | <lnpo1w60mx.fsf@kst-u.example.com> |
| In reply to | #130629 |
bartc <bc@freeuk.com> writes:
> On 15/05/2018 21:15, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>
>>> What are the practical implications of not having a distinct third
>>> character type?
>>>
>>> What programs will I not be able to write? Which ones will I not be able
>>> to compile?
>>
>> Ok, let's assume an otherwise conforming C compiler which treates `char`
>> and `unsigned char` as the same type.
>>
>> This conforming program would fail to compile:
>>
>> #include <stdio.h>
>> int main(void) {
>> printf("\"abc\"[0] is of type %s\n",
>> _Generic("abc"[0],
>> char: "char",
>> unsigned char: "unsigned char",
>> signed char: "signed char"));
>> }
>>
>> I admit that's a bit contrived, but I can imagine similar constructs
>> being useful.
>
> I had to tweak my compiler so as not to widen the expression used in
> Generic (otherwise it would fail to find a match for 'unsigned int'),
> and then it worked (matching 'char').
>
> Presumably the error you're looking for is that the list of Generic
> cases includes two compatible types (char and unsigned char).
>
> I don't get that because I don't bother checking if there is more than
> one match. (It's only a 40-line implementation of Generic created to
> compile one posted example. But I can get that error with 3 extra lines.)
So two non-conforming features in your compiler cancelled out in this
case. But if you swapped the "char" and "unsigned char" lines,
presumably it would print "unsigned char" with your compiler, which is
incorrect behavior.
> However, you will likely find the same problem when using types such as
> int and int32_t, or unsigned char and int8_t, because a lot of the types
> in stdint.h are typedefs of standard ones, so the whole thing is a bit
> of a mess anyway.
Yes, it would be nice to be able to use, for example, both int and
int32_t in a generic selection. There would have to be a rule to
resolve which one is recognized. I haven't used _Generic much, but if I
wanted to use it on an integer expression I suppose I'd just specify
either the predefined types or the intN_t types, not both.
> And actually, of my other 6 compilers, 3 failed to compile it because
> they don't support Generic, including MSVC.
_Generic was introduced in C11.
>> A more likely problem is that someone using such a compiler would write
>> code that would compile and run, and later find that it's rejected by
>> some other compiler.
>
> Yes, I get that quite often, on code that has been passed by gcc, but
> fails with mine because it's stricter.
>
> For example:
>>
>> unsigned char *data = "abcd";
>>
>> which is a constraint violation in standard C.
>>
>
> Warning with Pelles C, gcc (-Wall etc)
>
> Error with DMC
>
> Nothing with MSVC, lccwin, tcc, gcc (default)
>
> Error with mine, when I change it to signed (because "abcd" already has
> unsigned chars).
>
> So it doesn't really look like many compilers take it that seriously.
At least gcc and clang take it seriously enough to flag it as a fatal
error if you use "-std=c11 -pedantic-errors". But of course you're only
pretending not to know that.
--
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 23:54 +0100 |
| Message-ID | <fyJKC.89335$jb7.15580@fx34.am4> |
| In reply to | #130632 |
On 15/05/2018 22:59, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
>> So it doesn't really look like many compilers take it that seriously.
>
> At least gcc and clang take it seriously enough to flag it as a fatal
> error if you use "-std=c11 -pedantic-errors". But of course you're only
> pretending not to know that.
According to your very statement, no they don't.
They will only make it a fatal error, if you tell them to make it a
fatal error! That and whatever other insignificant things come up that
are otherwise merely considered pedantic, so it's possible you may not
be able to compile some real programs because they would fail.
(I tried on Tiny C sources, and it failed to compile.)
That you even have to use a switch called "pedantic-errors" shows how
seriously they would take it otherwise!
Of course I only did my tests using:
-Wall -Wextra -Wpedantic -std=c11
But forget about what the standard says, and how compilers can be
coerced into failing programs that they would rather not, and go back to
your example:
unsigned char *data = "abcd";
Why are we wasting time bothering about whether the individual
characters of the string are signed, unsigned, or indeterminate?
It's JUST A STRING. If you can consider the signedness of the characters
at all, they will be just a sequence of unsigned bytes each with a value
0 to 255.
This was a big mistake in C, and it's bad enough having two possible
versions of char, without having THREE!
At least I'm doing my bit to try and get that figure down. What are
/you/ doing except perpetuating all this stuff?
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-15 16:18 -0700 |
| Message-ID | <ln603o5wzq.fsf@kst-u.example.com> |
| In reply to | #130634 |
bartc <bc@freeuk.com> writes:
> On 15/05/2018 22:59, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>
>>> So it doesn't really look like many compilers take it that seriously.
>>
>> At least gcc and clang take it seriously enough to flag it as a fatal
>> error if you use "-std=c11 -pedantic-errors". But of course you're only
>> pretending not to know that.
>
> According to your very statement, no they don't.
Wrong.
[...]
> At least I'm doing my bit to try and get that figure down. What are
> /you/ doing except perpetuating all this stuff?
At this point, giving up on trying to explain this stuff to you.
--
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-16 00:40 +0100 |
| Message-ID | <GdKKC.76924$ga6.2688@fx24.am4> |
| In reply to | #130638 |
On 16/05/2018 00:18, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: >> On 15/05/2018 22:59, Keith Thompson wrote: >>> bartc <bc@freeuk.com> writes: >> >>>> So it doesn't really look like many compilers take it that seriously. >>> >>> At least gcc and clang take it seriously enough to flag it as a fatal >>> error if you use "-std=c11 -pedantic-errors". But of course you're only >>> pretending not to know that. >> >> According to your very statement, no they don't. > > Wrong. Why? Are you disputing that the error is considered 'pedantic', and that you specifically need to tell the compiler to treat such errors seriously by using that "-pedantic-errors" option?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-15 17:25 -0700 |
| Message-ID | <lny3gk4fby.fsf@kst-u.example.com> |
| In reply to | #130639 |
bartc <bc@freeuk.com> writes:
> On 16/05/2018 00:18, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>>> On 15/05/2018 22:59, Keith Thompson wrote:
>>>> bartc <bc@freeuk.com> writes:
>>>
>>>>> So it doesn't really look like many compilers take it that seriously.
>>>>
>>>> At least gcc and clang take it seriously enough to flag it as a fatal
>>>> error if you use "-std=c11 -pedantic-errors". But of course you're only
>>>> pretending not to know that.
>>>
>>> According to your very statement, no they don't.
>>
>> Wrong.
>
> Why?
>
> Are you disputing that the error is considered 'pedantic', and that you
> specifically need to tell the compiler to treat such errors seriously by
> using that "-pedantic-errors" option?
Would there be any point in my trying to explain this to you yet again?
(That was a rhetorical question.)
--
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-16 01:32 +0100 |
| Message-ID | <l_KKC.150194$tw.131731@fx42.am4> |
| In reply to | #130641 |
On 16/05/2018 01:25, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: >> On 16/05/2018 00:18, Keith Thompson wrote: >>> bartc <bc@freeuk.com> writes: >>>> On 15/05/2018 22:59, Keith Thompson wrote: >>>>> bartc <bc@freeuk.com> writes: >>>> >>>>>> So it doesn't really look like many compilers take it that seriously. >>>>> >>>>> At least gcc and clang take it seriously enough to flag it as a fatal >>>>> error if you use "-std=c11 -pedantic-errors". But of course you're only >>>>> pretending not to know that. >>>> >>>> According to your very statement, no they don't. >>> >>> Wrong. >> >> Why? >> >> Are you disputing that the error is considered 'pedantic', and that you >> specifically need to tell the compiler to treat such errors seriously by >> using that "-pedantic-errors" option? > > Would there be any point in my trying to explain this to you yet again? > > (That was a rhetorical question.) I assume I am right then and you're wrong. I don't need to explain it further because others can see what you wrote and can draw their own conclusions.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-05-16 14:32 +0000 |
| Message-ID | <giXKC.85247$np1.33156@fx06.iad> |
| In reply to | #130642 |
bartc <bc@freeuk.com> writes: >On 16/05/2018 01:25, Keith Thompson wrote: >> Would there be any point in my trying to explain this to you yet again? >> >> (That was a rhetorical question.) > >I assume I am right then and you're wrong. What are you, five years old?
[toc] | [prev] | [next] | [standalone]
Page 9 of 12 — ← Prev page 1 … 7 8 [9] 10 11 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web