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 10 of 12 — ← Prev page 1 … 8 9 [10] 11 12 Next page →
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-16 07:41 -0700 |
| Message-ID | <b1631ca9-6ea1-4c69-a1a9-71b84df435b3@googlegroups.com> |
| In reply to | #130648 |
On Wednesday, May 16, 2018 at 7:32:58 AM UTC-7, Scott Lurndal wrote: > 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? It's a long, long story, and Steve Carroll is simultaneously an expert bullshiter of trolling remarks, while posting with nyms that speak just like him. The person you are attacking is in my KF. After blocking all the trolling from Steve Carroll, it's basically just two flooders making the vast majority of the bombardment. Yes. And both downright unhinged maniacs. -- Eight things to never feed your cat! https://youtu.be/HHT9SJgYsH4 Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-15 21:13 -0700 |
| Message-ID | <76428bf0-eecd-4fb6-939f-48baedd6eeb2@googlegroups.com> |
| In reply to | #130641 |
On Tuesday, May 15, 2018 at 5:25:14 PM UTC-7, 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.) > > -- > 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" Andre G. Isaak is far too unintelligent to write a good script. The only scripting he's ever shown he can do is click, click, drool, drool. What do you get out of lying? And in retaliation you have nothing but a crack to start more flooding. -- Eight things to never feed your cat http://www.5z8.info/open.exe_f2s2ea_nazi http://www.5z8.info/mydick_x6g9hr_nakedgrandmas.jpg Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-16 07:51 -0700 |
| Message-ID | <1ef99710-2374-4cea-9aa0-646312b5040f@googlegroups.com> |
| In reply to | #130639 |
On Tuesday, May 15, 2018 at 6:40:30 PM UTC-5, Bart wrote: > 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? GCC is more than 20 years old. At one time, the authors acknowledged that the Standard didn't fully specify everything useful that compilers could and should do, and that a compiler which fully enforced all of the constraints listed in the Standard would be less useful than one which implemented sensible behaviors when practical. Had the name of the flag been chosen by the present authors of gcc, rather than inherited from 20+ years ago, I doubt they would have described it as "pedantic" mode.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-16 18:09 +0100 |
| Message-ID | <qBZKC.251065$Cd3.135695@fx33.am4> |
| In reply to | #130650 |
On 16/05/2018 15:51, supercat@casperkitty.com wrote: > On Tuesday, May 15, 2018 at 6:40:30 PM UTC-5, Bart wrote: >> 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? > > GCC is more than 20 years old. At one time, the authors acknowledged > that the Standard didn't fully specify everything useful that compilers > could and should do, and that a compiler which fully enforced all of the > constraints listed in the Standard would be less useful than one which > implemented sensible behaviors when practical. > > Had the name of the flag been chosen by the present authors of gcc, rather > than inherited from 20+ years ago, I doubt they would have described it > as "pedantic" mode. I'm sure gcc is quite capable of adding a more aptly named option to do the same thing. But it still very much seems like you have to really twist its arm to take certain things seriously, and then only because you say they are serious and it just goes along with that. And in that example: unsigned char s = "abc", what exactly can go wrong when s is initialised with a set of possibly signed characters rather than unsigned ones? Or vice versa. Perhaps in such a case the literal can adapt itself to the needs of the thing being initialised, in the same way that it can provide the bounds of an initialised unbounded array. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-16 13:22 -0700 |
| Message-ID | <f3f649d5-fb24-4f68-93c6-1ac5e83e1ef1@googlegroups.com> |
| In reply to | #130658 |
On Wednesday, May 16, 2018 at 12:09:52 PM UTC-5, Bart wrote: > And in that example: unsigned char s = "abc", what exactly can go wrong > when s is initialised with a set of possibly signed characters rather > than unsigned ones? Or vice versa. When the Standard was written, there were compilers that did not regard such pointer types as compatible. The value of requiring that all compilers accept such conversions was insufficient to compel those compilers to change. Conversely, the cost of requiring that all compilers that don't issue a diagnostic for such code must document their acceptance of it as an extension was seen as minimal. I don't think the authors of the Standard did any in-depth examination of the advantages and disadvantages of allowing char* to be implicitly converted to "signed char*" or "unsigned char*" and/or vice versa. The rationale makes no mention of such a thing, and if compilers weren't going to be ordered to accept such conversions, treating the types as incompatible was simpler than doing anything else.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-16 09:15 +0200 |
| Message-ID | <pdglq2$ejk$1@dont-email.me> |
| In reply to | #130632 |
On 15/05/18 23:59, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: >> 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. > Yes, it is usually best to stick to one style or the other. The intN_t types are extremely useful (at least for my type of work - I use them all the time), but they are also slightly odd in combination with the fundamental types. On most targets, they are simple typedefs for one of the fundamental types - but it is not always clear which. "int32_t" is a typedef for "int" on 32-bit x86 gcc, but "long" on 32-bit ARM gcc. And for the 8-bit AVR (with 16-bit int) on gcc, it is a typedef for a gcc extension type "int" with 32-bit size. I have no idea why. But it means that an int* and an int32_t* can alias on some targets and not others, even if int is 32-bit. It means _Generic can distinguish between them in some cases and not others. It means "%d" is an acceptable printf specifier on some targets, while others will work correctly but warn you unless you have "%ld". Portable code has to use the PRId32 macro - and you have to be a far bigger C fanboy than I to think /that/ is a neat solution!
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-16 00:39 -0700 |
| Message-ID | <3ab6cc2e-b72a-47dc-b88b-77a8bc75c56f@googlegroups.com> |
| In reply to | #130645 |
On Wednesday, May 16, 2018 at 12:15:22 AM UTC-7, David Brown wrote: > On 15/05/18 23:59, Keith Thompson wrote: > > bartc <bc@freeuk.com> writes: > > >> 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. > > > > Yes, it is usually best to stick to one style or the other. The intN_t > types are extremely useful (at least for my type of work - I use them > all the time), but they are also slightly odd in combination with the > fundamental types. On most targets, they are simple typedefs for one of > the fundamental types - but it is not always clear which. "int32_t" is > a typedef for "int" on 32-bit x86 gcc, but "long" on 32-bit ARM gcc. > And for the 8-bit AVR (with 16-bit int) on gcc, it is a typedef for a > gcc extension type "int" with 32-bit size. I have no idea why. > > But it means that an int* and an int32_t* can alias on some targets and > not others, even if int is 32-bit. It means _Generic can distinguish > between them in some cases and not others. It means "%d" is an > acceptable printf specifier on some targets, while others will work > correctly but warn you unless you have "%ld". Portable code has to use > the PRId32 macro - and you have to be a far bigger C fanboy than I to > think /that/ is a neat solution! -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dude, you know Snit's an idiot, right? I was watching this nature show earlier where all the frogs were leaving the area where the female did her thing save for this one lone male. The lone male is tasked with watching over the tadpoles and a number of them got isolated in a small puddle because the sun was quickly drying things up. With not much more than an hour to act, the male dug a trench between the drying puddle and the larger water area so that the tadpoles could escape their fate. In other words, all the frogs that left, the lone male and the tadpoles are *all* smarter than Snit ;) -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVRvszAAoJEC03b6bOr/+dgh8P/1bqYz0WtOQ0cCL5NKI2S/ht xGAgCESCEDe1Fm06Woz0/HdJk91NnhCw7a0dZ1Jsb1lkj6CWoSjlKrcGkNMq8AtL MfGWAP7Sl8fFY+E1wm0VraMrePSA4DOT2OrDFL2IkqsfdL8BWG3o5NQ0dUPL10t0 f/FSIGOlbHEp/04/+YXb6AccBEHLvNd8xs18WGQQ49T5Budmcvzk/DYwlAS/A/Zw 3w+KquMDWNMFl9/LXFW4b9y8Ezb1iJ7sBidfjdSSYxgmCpT5JGYhZOgkMXBb4Sll ih/HGiD5fgqgNGsE1bYNwr8/I/nLIZSx/BS/kQBe0M6qE1EfE8hUQKPFVr+mZioB yj05BWTLdP3qd4fHALfY0YKdnnAIvLU+bk2CxxP4avBaNI1Ecsqu38OMX+kUoumQ wZkhT5oLSo8QYykMhU4/pJTis1nYuYWIwqLutYOLA0pbPClXEKHYv/xxtfZID9oy ZypDy4qXQrwkwjeUwqBu4aet6nU6Jusn6MAlTXBTuSfFqaaoInWuj/9bwq66lbhv aoZCy2s3sDVlV6jsRc45g8Xwq+hBXWEMmDH0J/HEggHGHdEY+zBM8GzzQOcetmNf poJkkDcxX4J/ii5LIdWVMoGTqzgTvbBh6wTJGwNzs5nvmlxYsB0nVJpInzXh8UUR XpLoRbLwvv7N0La3E0GB =Co5j -----END PGP SIGNATURE----- -- Top 15 Ways Bill Cunningham Trolls! http://www.5z8.info/add-worm_z4r9qk_fakelogin Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-16 08:31 -0700 |
| Message-ID | <d6cee670-9304-45a3-a6f9-b8c23e40e5b0@googlegroups.com> |
| In reply to | #130645 |
On Wednesday, May 16, 2018 at 2:15:22 AM UTC-5, David Brown wrote:
> But it means that an int* and an int32_t* can alias on some targets and
> not others, even if int is 32-bit. It means _Generic can distinguish
> between them in some cases and not others. It means "%d" is an
> acceptable printf specifier on some targets, while others will work
> correctly but warn you unless you have "%ld". Portable code has to use
> the PRId32 macro - and you have to be a far bigger C fanboy than I to
> think /that/ is a neat solution!
It seems to me that a far more elegant solution would be to have a means
by which a prototype can specify promotions for a "...". While this may
cause trouble if a va_list created using one prototype is passed to a
function that expects a different kind of va_list, it would have made it
possible for implementations to offer different levels of portability,
speed, or (for some cases) accuracy.
For example, given something like [with an implementation selecting this
version of printf based upon command-line or #define options prior to
the #include <stdio.h>]
#define printf __printf_double_long
void printf(char const * restrict format, ... (double,long));
a compiler would convert all integer arguments to "printf" to "long" that
could fit in "long" and "unsigned long" to those types and squawk if any
integer arguments that couldn't fit were passed without being explicitly
wrapped. All floating-point arguments, including "long double", would be
converted to "double" unless wrapped. Type modifiers would be ignored
unless combined with another character to indicate "wrapped".
Other variations would be:
// For use in programs that aren't otherwise going to use "double"
#define printf __printf_float_long
void printf(char const * restrict format, ... (float, long));
// For maximum compatibility at the expense of performance
#define printf __printf_longdouble_longlong
void printf(char const * restrict format, ... (long double, long long));
When C was invented, the type of integer passed to a function would not
depend upon the exact integer type used in the argument, and the same was
true for floating-point types. Unfortunately, the way other types were
added to the language threw that principle out the window.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-17 15:00 +0200 |
| Message-ID | <pdjuck$9cc$1@dont-email.me> |
| In reply to | #130652 |
On 16/05/18 17:31, supercat@casperkitty.com wrote: > On Wednesday, May 16, 2018 at 2:15:22 AM UTC-5, David Brown wrote: >> But it means that an int* and an int32_t* can alias on some targets and >> not others, even if int is 32-bit. It means _Generic can distinguish >> between them in some cases and not others. It means "%d" is an >> acceptable printf specifier on some targets, while others will work >> correctly but warn you unless you have "%ld". Portable code has to use >> the PRId32 macro - and you have to be a far bigger C fanboy than I to >> think /that/ is a neat solution! > > It seems to me that a far more elegant solution would be to have a means > by which a prototype can specify promotions for a "...". That would seem to me to be a far more complicated solution. A simpler idea would be for implementations to be happy with types that are logically distinct and incompatible types as far as C is concerned, but which have the same size and representation on the given target - and guarantee that they will be accepted correctly in standard printf-style functions. At the moment, if you have a target with 32-bit "int" and 32-bit "long", then technically you should not pass a long to printf when an int is expected - and gcc with -Wformat will complain about it. An implementation could easily guarantee that it would be happy with that combination, and a compiler with warnings like gcc's -Wformat could have a less restrictive warning that allows it through. This is merely a matter of an implementation being a touch more helpful here - no language change is needed. Secondly, it would be possible to put together a more sophisticated arrangement using variadic macros, generic macros, and individual printf_int, printf_long, etc., functions. Again, no language change would be needed.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-17 08:07 -0700 |
| Message-ID | <be94d750-6d5c-49b6-8b50-7cc00e44aa9b@googlegroups.com> |
| In reply to | #130703 |
On Thursday, May 17, 2018 at 8:00:13 AM UTC-5, David Brown wrote: > A simpler idea would be for implementations to be happy with types that > are logically distinct and incompatible types as far as C is concerned, > but which have the same size and representation on the given target - > and guarantee that they will be accepted correctly in standard > printf-style functions. At the moment, if you have a target with 32-bit > "int" and 32-bit "long", then technically you should not pass a long to > printf when an int is expected - and gcc with -Wformat will complain > about it. An implementation could easily guarantee that it would be > happy with that combination, and a compiler with warnings like gcc's > -Wformat could have a less restrictive warning that allows it through. > This is merely a matter of an implementation being a touch more helpful > here - no language change is needed. There are oodles of cases where implementations are "usually" helpful, and should have no reason to be unhelpful, but some implementation writers insist that any apparent support for something which is neither mandated by the Standard nor explicitly documented should be regarded as illusory. Further, while that approach worked well for most of the combinations of data types used in the classic 8/16/32-bit era, excluding 80-bit "long double" which was handled horribly from the get-go, it makes code written to be universal among smaller machines where an int32_t might or might not require %ld, fail under the LP64 model. > Secondly, it would be possible to put together a more sophisticated > arrangement using variadic macros, generic macros, and individual > printf_int, printf_long, etc., functions. Again, no language change > would be needed. The approach I describe would result in existing code working if run on implementations configured to be "universal", and in compilation squawks if an implementation's configuration doesn't match the code's requirements. I don't think the C99 variadic macros support everything needed to be really useful here.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-18 05:04 -0700 |
| Message-ID | <9bf6d5f2-eed3-486a-9654-6dbd543c3883@googlegroups.com> |
| In reply to | #130710 |
On Thursday, May 17, 2018 at 8:07:54 AM UTC-7, supe...@casperkitty.com wrote: > On Thursday, May 17, 2018 at 8:00:13 AM UTC-5, David Brown wrote: > > A simpler idea would be for implementations to be happy with types that > > are logically distinct and incompatible types as far as C is concerned, > > but which have the same size and representation on the given target - > > and guarantee that they will be accepted correctly in standard > > printf-style functions. At the moment, if you have a target with 32-bit > > "int" and 32-bit "long", then technically you should not pass a long to > > printf when an int is expected - and gcc with -Wformat will complain > > about it. An implementation could easily guarantee that it would be > > happy with that combination, and a compiler with warnings like gcc's > > -Wformat could have a less restrictive warning that allows it through. > > This is merely a matter of an implementation being a touch more helpful > > here - no language change is needed. > > There are oodles of cases where implementations are "usually" helpful, > and should have no reason to be unhelpful, but some implementation writers > insist that any apparent support for something which is neither mandated > by the Standard nor explicitly documented should be regarded as illusory. > > Further, while that approach worked well for most of the combinations of > data types used in the classic 8/16/32-bit era, excluding 80-bit "long > double" which was handled horribly from the get-go, it makes code written > to be universal among smaller machines where an int32_t might or might not > require %ld, fail under the LP64 model. > > > Secondly, it would be possible to put together a more sophisticated > > arrangement using variadic macros, generic macros, and individual > > printf_int, printf_long, etc., functions. Again, no language change > > would be needed. > > The approach I describe would result in existing code working if run on > implementations configured to be "universal", and in compilation squawks > if an implementation's configuration doesn't match the code's requirements. > I don't think the C99 variadic macros support everything needed to be > really useful here. I'm not angry, to the contrary, I'm busting a gut because Allah's trolling is so obvious. He actively did not introduce all the criteria that he would quickly poo poo... and we all know why, Allah is such a moron. At least he has morons in his corner ;) Melzzzzz and the advocates imply searching for a recommendation for a FOSS application is attacking. And you do realize that it isn't impossible for Allah to be doing this, or paying others to do so. Over and over, the demand is he wants to "talk tech", but the guy spends most of his time whining about "C++". You hacked it and took it for a test drive and your "intuitions" lead you to that verdict, so what? Usenet is an uncontrollable concordat based on the belief in good character. - One Smart Penny https://redd.it/6sfhq6 Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-17 09:07 -0700 |
| Message-ID | <ln1sea4669.fsf@kst-u.example.com> |
| In reply to | #130703 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> A simpler idea would be for implementations to be happy with types that
> are logically distinct and incompatible types as far as C is concerned,
> but which have the same size and representation on the given target -
> and guarantee that they will be accepted correctly in standard
> printf-style functions. At the moment, if you have a target with 32-bit
> "int" and 32-bit "long", then technically you should not pass a long to
> printf when an int is expected - and gcc with -Wformat will complain
> about it. An implementation could easily guarantee that it would be
> happy with that combination, and a compiler with warnings like gcc's
> -Wformat could have a less restrictive warning that allows it through.
> This is merely a matter of an implementation being a touch more helpful
> here - no language change is needed.
And then you could write:
long x = 42;
printf("%x = %d\n", x);
and never know that there's a potential problem until you port the code
to another system.
(Strictly speaking that's already the case, since no warning is required
even on systems where int and long have different sizes.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-17 10:33 -0700 |
| Message-ID | <726d9572-f3c9-4f44-846d-eb49d6750d64@googlegroups.com> |
| In reply to | #130715 |
On Thursday, May 17, 2018 at 11:07:34 AM UTC-5, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
> > A simpler idea would be for implementations to be happy with types that
> > are logically distinct and incompatible types as far as C is concerned,
> > but which have the same size and representation on the given target -
> > and guarantee that they will be accepted correctly in standard
> > printf-style functions. At the moment, if you have a target with 32-bit
> > "int" and 32-bit "long", then technically you should not pass a long to
> > printf when an int is expected - and gcc with -Wformat will complain
> > about it. An implementation could easily guarantee that it would be
> > happy with that combination, and a compiler with warnings like gcc's
> > -Wformat could have a less restrictive warning that allows it through.
> > This is merely a matter of an implementation being a touch more helpful
> > here - no language change is needed.
>
> And then you could write:
>
> long x = 42;
> printf("%x = %d\n", x);
>
> and never know that there's a potential problem until you port the code
> to another system.
>
> (Strictly speaking that's already the case, since no warning is required
> even on systems where int and long have different sizes.)
If the other system uses the enhanced prototype, and opts to use a default
type which is smaller than "long", the problem would be revealed by a build
error, which would be an improvement over the present situation where:
int32_t x = 5;
printf("%ld",x);
would build on all platforms, but fail at runtime on some of them.
The Standard does not in general make it practical to guarantee that
code won't work on any platform unless it will work on every other. An
implementation which is designed for the purpose of validating
portability will be able to do a much better job than one which is
designed to efficiently process code which is suitable for the
intended target.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-05-17 18:04 +0000 |
| Message-ID | <2vjLC.94102$JJ3.94015@fx23.iad> |
| In reply to | #130718 |
supercat@casperkitty.com writes:
>On Thursday, May 17, 2018 at 11:07:34 AM UTC-5, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>> > A simpler idea would be for implementations to be happy with types that
>> > are logically distinct and incompatible types as far as C is concerned,
>> > but which have the same size and representation on the given target -
>> > and guarantee that they will be accepted correctly in standard
>> > printf-style functions. At the moment, if you have a target with 32-bit
>> > "int" and 32-bit "long", then technically you should not pass a long to
>> > printf when an int is expected - and gcc with -Wformat will complain
>> > about it. An implementation could easily guarantee that it would be
>> > happy with that combination, and a compiler with warnings like gcc's
>> > -Wformat could have a less restrictive warning that allows it through.
>> > This is merely a matter of an implementation being a touch more helpful
>> > here - no language change is needed.
>>
>> And then you could write:
>>
>> long x = 42;
>> printf("%x = %d\n", x);
>>
>> and never know that there's a potential problem until you port the code
>> to another system.
>>
>> (Strictly speaking that's already the case, since no warning is required
>> even on systems where int and long have different sizes.)
>
>If the other system uses the enhanced prototype, and opts to use a default
>type which is smaller than "long", the problem would be revealed by a build
>error, which would be an improvement over the present situation where:
>
> int32_t x = 5;
> printf("%ld",x);
#include <inttypes.h>
Why would you not use
printf(PRIu32, x);
?
Likesize, for uint64_t x=6;
printf("The value is " PRIu64 "\n", x);
?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-17 13:15 -0700 |
| Message-ID | <437a888c-00fc-4c72-a009-8ee019f6b76c@googlegroups.com> |
| In reply to | #130719 |
On Thursday, May 17, 2018 at 1:04:55 PM UTC-5, Scott Lurndal wrote:
> Why would you not use
>
> printf(PRIu32, x);
>
> ?
>
> Likesize, for uint64_t x=6;
>
> printf("The value is " PRIu64 "\n", x);
> ?
I find something like "(%08X,%08X)" more readable than something like
"(08" PRIX32 ",08" PRIX32 ")". Perhaps you don't.
How common are platforms where "%ld" couldn't be a usable specifier for
a 32-bit integer? Most of the platforms I've seen where "long" is greater
than 32 bits seem to promote all variadic integer arguments to that type,
and would thus be able to support use of "%ld" for a 32-bit int.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-17 14:07 -0700 |
| Message-ID | <lno9he2dp6.fsf@kst-u.example.com> |
| In reply to | #130728 |
supercat@casperkitty.com writes:
> On Thursday, May 17, 2018 at 1:04:55 PM UTC-5, Scott Lurndal wrote:
>> Why would you not use
>>
>> printf(PRIu32, x);
>>
>> ?
>>
>> Likesize, for uint64_t x=6;
>>
>> printf("The value is " PRIu64 "\n", x);
>> ?
>
> I find something like "(%08X,%08X)" more readable than something like
> "(08" PRIX32 ",08" PRIX32 ")". Perhaps you don't.
>
> How common are platforms where "%ld" couldn't be a usable specifier for
> a 32-bit integer? Most of the platforms I've seen where "long" is greater
> than 32 bits seem to promote all variadic integer arguments to that type,
> and would thus be able to support use of "%ld" for a 32-bit int.
No platforms promote integer arguments to that *type*. They might
extend them to that *size*.
Using "%ld" with an int argument produces the "correct" results on
the the systems I have access to at the moment. But using correct
format strings is a far better use of my time than figuring out,
based on the behavior of the compilers and target systems I happen
to be concerned with today, how I can subvert the rules and get
away with it (and deciding I can ignore the warnings that gcc and
clang both give by default).
I don't often use the formats defined in <inttypes.h>, mostly
because I find them difficult to remember (of course that's
self-reinforcing). Instead I generally convert to a predefined
type than I know to be wide enough.
int32_t x = 10;
int64_t y = 20;
printf("x = %ld, y = %lld\n", (long)x, (long long)y);
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-17 15:40 -0700 |
| Message-ID | <2e5df1b2-c837-4fc6-8055-61bfb22b9356@googlegroups.com> |
| In reply to | #130734 |
On Thursday, May 17, 2018 at 4:07:57 PM UTC-5, Keith Thompson wrote:
> supercat@casperkitty.com writes:
> > How common are platforms where "%ld" couldn't be a usable specifier for
> > a 32-bit integer? Most of the platforms I've seen where "long" is greater
> > than 32 bits seem to promote all variadic integer arguments to that type,
> > and would thus be able to support use of "%ld" for a 32-bit int.
>
> No platforms promote integer arguments to that *type*. They might
> extend them to that *size*.
I should have said "representation".
> Using "%ld" with an int argument produces the "correct" results on
> the the systems I have access to at the moment. But using correct
> format strings is a far better use of my time than figuring out,
> based on the behavior of the compilers and target systems I happen
> to be concerned with today, how I can subvert the rules and get
> away with it (and deciding I can ignore the warnings that gcc and
> clang both give by default).
The only practical reason that %x, %lx, and %llx cannot portably be used
to output uint16_t, uint32_t, and uint64_t is that the Standard never
officially recognized that the vast majority of compilers that supported
those types could support such usage, and required that any compilers that
don't support such usage must indicate such non-support in some fashion.
The authors of the C Standard state in the rationale an intention
to let the marketplace determine how quality implementations should
behave in cases where the Standard imposes no requirements. I don't
think they intended programmers to expend significant effort to work
around the limitations of platforms upon which nobody would want to
run their code. Unless code would need to run on an obscure platform
that was able to support uint32_t but couldn't support the use of %lu
to format it, I see no reason that
printf("%04" PRIX16 ".%08" PRIX32 ":%08X" PRIX32 "\n", block, head, dat);
should have been particularly preferred over putting
#if defined(__STDC_UNUSUAL_PRINTF)
#error Sorry--This program requires common printf formatting conventions.
#endif
in a program's common header section and then saying:
printf("%04X.%08lX:%08lX", block, head, dat);
in the code itself.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-17 16:28 -0700 |
| Message-ID | <lnfu2p3lrg.fsf@kst-u.example.com> |
| In reply to | #130736 |
supercat@casperkitty.com writes:
[....]
> The only practical reason that %x, %lx, and %llx cannot portably be used
> to output uint16_t, uint32_t, and uint64_t is that the Standard never
> officially recognized that the vast majority of compilers that supported
> those types could support such usage, and required that any compilers that
> don't support such usage must indicate such non-support in some fashion.
The reason %x, %lx, and %llx cannot portably be used to output uint16_t,
uint32_t, and uint64_t is that uint16_t, uint32_t, and uint64_t are not
unsigned int, unsigned long, and unsigned long long, respectively.
> The authors of the C Standard state in the rationale an intention
> to let the marketplace determine how quality implementations should
> behave in cases where the Standard imposes no requirements. I don't
> think they intended programmers to expend significant effort to work
> around the limitations of platforms upon which nobody would want to
> run their code. Unless code would need to run on an obscure platform
> that was able to support uint32_t but couldn't support the use of %lu
> to format it, I see no reason that
>
> printf("%04" PRIX16 ".%08" PRIX32 ":%08X" PRIX32 "\n", block, head, dat);
>
> should have been particularly preferred over putting
>
> #if defined(__STDC_UNUSUAL_PRINTF)
> #error Sorry--This program requires common printf formatting conventions.
> #endif
>
> in a program's common header section and then saying:
>
> printf("%04X.%08lX:%08lX", block, head, dat);
>
> in the code itself.
You had an extra "X" in your first line.
No doubt you've worked out exactly what __STDC_UNUSUAL_PRINTF means, and
can rigorously state its requirements in standardese (along with all the
other feature test macros you want to add to the standard).
I would just write:
printf("%04X.%08lX.%08lX\n",
(unsigned)block, (unsigned long)head, (unsigned long)dat);
which is both portable and obvious, and only slightly more verbose than
your preferred version. I didn't have to make any assumptions about the
sizes of the predefined types or how they're represented in memory when
passed as arguments to a variadic function. I didn't have to assume
that all the world's an x86_64.
Or I might use PRIX16 and PRIX32, but I personally find them less
convenient.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-18 09:17 -0700 |
| Message-ID | <e6af0a89-8b60-4879-a38d-be963459dc62@googlegroups.com> |
| In reply to | #130738 |
On Thursday, May 17, 2018 at 6:28:30 PM UTC-5, Keith Thompson wrote:
> supercat@casperkitty.com writes:
> [....]
> > The only practical reason that %x, %lx, and %llx cannot portably be used
> > to output uint16_t, uint32_t, and uint64_t is that the Standard never
> > officially recognized that the vast majority of compilers that supported
> > those types could support such usage, and required that any compilers that
> > don't support such usage must indicate such non-support in some fashion.
>
> The reason %x, %lx, and %llx cannot portably be used to output uint16_t,
> uint32_t, and uint64_t is that uint16_t, uint32_t, and uint64_t are not
> unsigned int, unsigned long, and unsigned long long, respectively.
True, but on nearly all platforms that include those types, the types
uint16_t, uint32_t, and uint64_t will be promoted to types with the same
representations as int, long, and long long, respectively. A requirement
that implementations supporting those types must behave that way would
probably impact fewer implementations than the requirement that the types
have no padding bits, which made the types unsupportable on 36-bit
platforms (absent that requirement, such platforms would have been able to
support code that uses type uint32_t by storing them as a 36-bit word with
four padding bits).
> > The authors of the C Standard state in the rationale an intention
> > to let the marketplace determine how quality implementations should
> > behave in cases where the Standard imposes no requirements. I don't
> > think they intended programmers to expend significant effort to work
> > around the limitations of platforms upon which nobody would want to
> > run their code. Unless code would need to run on an obscure platform
> > that was able to support uint32_t but couldn't support the use of %lu
> > to format it, I see no reason that
> >
> > printf("%04" PRIX16 ".%08" PRIX32 ":%08X" PRIX32 "\n", block, head, dat);
> >
> > should have been particularly preferred over putting
> >
> > #if defined(__STDC_UNUSUAL_PRINTF)
> > #error Sorry--This program requires common printf formatting conventions.
> > #endif
> >
> > in a program's common header section and then saying:
> >
> > printf("%04X.%08lX:%08lX", block, head, dat);
> >
> > in the code itself.
>
> You had an extra "X" in your first line.
So I did.
> No doubt you've worked out exactly what __STDC_UNUSUAL_PRINTF means, and
> can rigorously state its requirements in standardese (along with all the
> other feature test macros you want to add to the standard).
That's probably not the best name--perhaps __STDC_ACCEPT_UNUSUAL_VARIADIC
would be better, but the requirements would be very simple:
Unless a program waives one of the following guarantees by defining an
appropriate symbol before including stdint.h, any intN_t and uintN_t
types would be required to uphold the following:
Unless code defines __STDC_ACCEPT_UNUSUAL_VARIADIC:
- An intN_t passed as a variadic argument may be retrieved using the
smallest standard signed type in which it is guaranteed to fit, and
if non-negative may be retrieved using the smallest such unsigned type.
- An uintN_t passed as a variadic argument may be retrieved using the
smallest standard unsigned type in which it is guaranteed to fit, and
if within range of intN_t, may be retrieved using the smallest signed
type.
- Printf format specifiers will behave as though retrieved using va_arg.
Unless code defines __STDC_ACCEPT_UNUSUAL_UNSIGNED_COERCING_OVERFLOW
- If the result of an integer additive, multiplicative, bitwise, or
left-shift operators is cast or coerced to a particular unsigned
type and the operands are at least as large as that type, the
operands will behave as though coerced to that type. Note that
this will not affect any program whose behavior would otherwise be
defined, but would ensure that the stated expectations of the
authors of the Standard are not needlessly violated in some corner
cases [e.g. u16_a = u16_b * u16_c].
Unless code defines __STDC_ACCEPT_UNUSUAL_SMALL_INTEGER_STORE
- Storing a value to a signed type smaller than "int" will truncate
it in two's-complement fashion.
Personally, I'd just as soon say that those types must *always* uphold
the first two guarantees, and would prefer to have types similar to
intN_t and uintN_t that waive truncation in cases where it isn't needed,
but if there would be a need to use fixed-sized types on code targeting
implementations where the first two guarantees are impractical, the
above approach would allow them to be supported.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-18 10:36 -0700 |
| Message-ID | <lnbmdc3lyz.fsf@kst-u.example.com> |
| In reply to | #130754 |
supercat@casperkitty.com writes:
> On Thursday, May 17, 2018 at 6:28:30 PM UTC-5, Keith Thompson wrote:
>> supercat@casperkitty.com writes:
>> [....]
>> > The only practical reason that %x, %lx, and %llx cannot portably be used
>> > to output uint16_t, uint32_t, and uint64_t is that the Standard never
>> > officially recognized that the vast majority of compilers that supported
>> > those types could support such usage, and required that any compilers that
>> > don't support such usage must indicate such non-support in some fashion.
>>
>> The reason %x, %lx, and %llx cannot portably be used to output uint16_t,
>> uint32_t, and uint64_t is that uint16_t, uint32_t, and uint64_t are not
>> unsigned int, unsigned long, and unsigned long long, respectively.
>
> True, but on nearly all platforms that include those types, the types
> uint16_t, uint32_t, and uint64_t will be promoted to types
Again, they are not promoted to *types*. Variadic arguments of types
narrower than int are promoted to int or to unsigned int. Other types
might be stored in a way that occupies more space than the type itself
(say, a 32-bit value stored in a 64-bit register or occupying 64 bits on
the stack).
> with the same
> representations as int, long, and long long, respectively. A requirement
> that implementations supporting those types must behave that way would
> probably impact fewer implementations than the requirement that the types
> have no padding bits, which made the types unsupportable on 36-bit
> platforms (absent that requirement, such platforms would have been able to
> support code that uses type uint32_t by storing them as a 36-bit word with
> four padding bits).
The standard is careful to allow for a wide variety of target platforms,
and to avoid specifying things it doesn't need to.
You propose to fragment the standard, so that *most* implementations
behave in a certain specified way but others do not, with a macro so
you can tell which. This would make it more difficult to write 100%
portable code, code that needs to be portable not just to current
implementations but future ones as well. You want to nail down
the characteristics of current systems and impose them on future
implementations.
All this because you'd rather write
printf("x = %d\n", x);
and have it work on 99% of current systems (and perhaps failing
silently), than write
printf("x = %ld\n", (long)x);
and have it just work.
You propose a complex solution for a trivial problem.
No thanks.
[...]
--
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]
Page 10 of 12 — ← Prev page 1 … 8 9 [10] 11 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web