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 11 of 12 — ← Prev page 1 … 9 10 [11] 12 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-18 11:41 -0700 |
| Message-ID | <7d8313cc-735d-4783-a75f-d8914eb37fc3@googlegroups.com> |
| In reply to | #130757 |
On Friday, May 18, 2018 at 12:36:12 PM UTC-5, Keith Thompson wrote:
> 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.
Which would a better goal:
1. Writing code which is 100% portable when it's remotely possible, even
at the expense of performance, legibility, etc.
2. Writing code which is 95%+ portable when practical, but without making
undue sacrifices to accommodate for platforms upon which nobody would
likely ever want to run the code.
Given the vast number of cases where 95% portability should be much more
practical than 100% portability, I'd say the latter goal is much more useful.
> 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.
Writing (long) isn't too bad, but (unsigned long long) is quite a bit more
verbose than "(uint64_t)". More importantly, there exists a lot of code
which makes such assumptions and would work in defined fashion on any
implementation whose behavior is defined as described. In the absence
of a demonstrable cost for doing so, I'd say that recognizing the meaning
of such code would be more useful than declaring it "broken".
> You propose a complex solution for a trivial problem.
>
> No thanks.
There exists a substantial corpus of code which relies upon behaviors which
are common to the vast majority of implementations which would be able to
build it (in many cases, likely 100% of such implementations at the time
the code was written). Which of the following seems like the most useful
way to deal with such code:
1. Require that all such code be revisited and changed to use only
behaviors mandated by the Standard for all implementations.
2. Have such code behave unpredictably if it is ever run on an
implementation that doesn't uphold its requirements.
3. Ensure that such code will refuse to compile if unexpectedly fed
to an implementation that doesn't uphold its requirements.
I'd say #3 sounds awfully good to me.
Whether it's better to say that implementations whose intN_t and uintN_t
don't share all the common behaviors of those on other systems should be
unconditionally forbidden from defining those types, or instead have a
means by which programs can waive certain guarantees, is a fair matter of
judgment. Requiring programmers to expend *any* amount of extra effort
to allow for implementations that would have no reason to exist on any
target platforms of interest, however, will make the language less useful
to them than it would be without such an imposition.
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-19 14:16 -0700 |
| Message-ID | <0fe4fd38-09f5-4a59-818f-e4cd69deb9b7@googlegroups.com> |
| In reply to | #130757 |
On Friday, May 18, 2018 at 10:36:12 AM UTC-7, Keith Thompson wrote:
> 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"
I bet he thinks his wife's life was fun.
What I do is certainly better. Please show an example of a large business that has gained its fortune by not giving a hoot about its clients or wares.
--
Eight things to never feed your dog!
https://youtu.be/Z5wo5aE7MUk
https://www.facebook.com/jenny.eklund
http://tinyurl.com/proof-about-ebot
Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-05-18 19:54 -0400 |
| Message-ID | <7JJLC.164485$PE5.67759@fx37.iad> |
| In reply to | #130754 |
On 5/18/18 12:17 PM, supercat@casperkitty.com wrote: > 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). > Most standard desktop today would map something like int16_t -> short (not int) int32_t -> int (or possibly long) int64_t -> probably long long some would like int to be 64 bits, but that causes problems with leaving out a 32 bit type. (I have heard some jokingly say that type could be a long short int, or let the 16 bit type be short short and short be the 32 bit type but lots of code assumes short is 16 bits).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-17 20:39 +0200 |
| Message-ID | <pdki8a$gfn$3@dont-email.me> |
| In reply to | #130715 |
On 17/05/18 18:07, 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.
Correct. That is perfectly fine for most of my code.
For code where that is /not/ fine, I'd still want the full "-Wformat"
gcc warning as it stands today. I'd like an extra option, not a
replacement. (Not that I am greedy at all...)
>
> (Strictly speaking that's already the case, since no warning is required
> even on systems where int and long have different sizes.)
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-17 12:37 -0700 |
| Message-ID | <lnwow22hwi.fsf@kst-u.example.com> |
| In reply to | #130723 |
David Brown <david.brown@hesbynett.no> writes:
> On 17/05/18 18:07, Keith Thompson wrote:
[...]
>> 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.
>
> Correct. That is perfectly fine for most of my code.
It's perfectly fine to have code whose behavior is undefined but that
happens to work on your system, that could be made completely portable
by using "%ld" rather than "%d"?
I don't mind making non-portable assumptions now and then, but printf
formats are so easy to get right that I take the (small) extra effort to
do so.
> For code where that is /not/ fine, I'd still want the full "-Wformat"
> gcc warning as it stands today. I'd like an extra option, not a
> replacement. (Not that I am greedy at all...)
As long as we're being greedy, I'd like to have a type-safe replacement
for printf. That's not currently possible in C.
(C++'s `std::cout << ...` comes close, but the fact that manipulators,
such as specifying the base or precision for a number, change the state
of the stream is massively annoying.)
--
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 | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2018-05-17 19:54 +0000 |
| Message-ID | <slrn3hvkpfrneo.cmg.ike@iceland.freeshell.org> |
| In reply to | #130726 |
On 2018-05-17, Keith Thompson <kst-u@mib.org> wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 17/05/18 18:07, Keith Thompson wrote:
> [...]
>>> 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.
What exactly is the point of the unmatched %d format specifier?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-17 13:39 -0700 |
| Message-ID | <lnsh6q2f00.fsf@kst-u.example.com> |
| In reply to | #130727 |
Ike Naar <ike@iceland.freeshell.org> writes:
> On 2018-05-17, Keith Thompson <kst-u@mib.org> wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 17/05/18 18:07, Keith Thompson wrote:
>> [...]
>>>> 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.
>
> What exactly is the point of the unmatched %d format specifier?
None whatsoever; it was a typo.
I meant to write:
long x = 42;
printf("x = %d\n", x);
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-17 22:48 +0200 |
| Message-ID | <pdkprc$8to$2@dont-email.me> |
| In reply to | #130727 |
On 17/05/18 21:54, Ike Naar wrote:
> On 2018-05-17, Keith Thompson <kst-u@mib.org> wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 17/05/18 18:07, Keith Thompson wrote:
>> [...]
>>>> 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.
>
> What exactly is the point of the unmatched %d format specifier?
>
It was a typo, I assume - I took it to mean "printf("x = %d\n", x);".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-17 22:47 +0200 |
| Message-ID | <pdkpom$8to$1@dont-email.me> |
| In reply to | #130726 |
On 17/05/18 21:37, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 17/05/18 18:07, Keith Thompson wrote:
> [...]
>>> 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.
>>
>> Correct. That is perfectly fine for most of my code.
>
> It's perfectly fine to have code whose behavior is undefined but that
> happens to work on your system, that could be made completely portable
> by using "%ld" rather than "%d"?
>
> I don't mind making non-portable assumptions now and then, but printf
> formats are so easy to get right that I take the (small) extra effort to
> do so.
In a case where you have a type like "long" or "int" it is easy to get
it right - it's rare you need a warning there.
The discussion was on types like "int32_t" which might be "int" and
might be "long" on a platform with 32-bit int /and/ 32-bit long. That
is when I would be happier writing "printf("%x = %d\n", x);" /or/
"printf(%x = %ld\n", x);" regardless if int32_t happened to be "int" or
"long". That would mean that I would not get a warning in cases where I
had specifically picked "x" to be "long" and used it with "%d". That is
the price you have to pay for less strict warnings. (Usually I am a fan
of lots of strict warnings, but sometimes they get in the way.)
>
>> For code where that is /not/ fine, I'd still want the full "-Wformat"
>> gcc warning as it stands today. I'd like an extra option, not a
>> replacement. (Not that I am greedy at all...)
>
> As long as we're being greedy, I'd like to have a type-safe replacement
> for printf.
I'd be happy there too :-)
> That's not currently possible in C.
>
> (C++'s `std::cout << ...` comes close, but the fact that manipulators,
> such as specifying the base or precision for a number, change the state
> of the stream is massively annoying.)
>
Agreed about C++ std::cout.
I think actually you could get quite close in C with variadic macros and
generics. Like C++ std::cout, it would be hard to get something that
worked well with translation strings.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-17 14:13 -0700 |
| Message-ID | <lnk1s22df6.fsf@kst-u.example.com> |
| In reply to | #130730 |
David Brown <david.brown@hesbynett.no> writes:
> On 17/05/18 21:37, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 17/05/18 18:07, Keith Thompson wrote:
>> [...]
>>>> And then you could write:
>>>>
>>>> long x = 42;
>>>> printf("x = %d\n", x);
[typo corrected]
>>>>
>>>> and never know that there's a potential problem until you port the code
>>>> to another system.
>>>
>>> Correct. That is perfectly fine for most of my code.
>>
>> It's perfectly fine to have code whose behavior is undefined but that
>> happens to work on your system, that could be made completely portable
>> by using "%ld" rather than "%d"?
>>
>> I don't mind making non-portable assumptions now and then, but printf
>> formats are so easy to get right that I take the (small) extra effort to
>> do so.
>
> In a case where you have a type like "long" or "int" it is easy to get
> it right - it's rare you need a warning there.
>
> The discussion was on types like "int32_t" which might be "int" and
> might be "long" on a platform with 32-bit int /and/ 32-bit long. That
> is when I would be happier writing "printf("%x = %d\n", x);" /or/
> "printf(%x = %ld\n", x);" regardless if int32_t happened to be "int" or
> "long". That would mean that I would not get a warning in cases where I
> had specifically picked "x" to be "long" and used it with "%d". That is
> the price you have to pay for less strict warnings. (Usually I am a fan
> of lots of strict warnings, but sometimes they get in the way.)
gcc warns about format strings by default. You'd have to disable that
warning explicitly.
My solution:
printf("x = %ld\n", (long)x);
I know that long is wide enough to hold any value of type int32_t,
and I know that "%ld" is the correct format for a long argument.
(I *might* be lazy and use "%d" and (int) if I happen to know that
int on the current system is at least 32 bits and/or that the value
of x is small enough.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-18 10:10 +0200 |
| Message-ID | <pdm1p7$p9c$1@dont-email.me> |
| In reply to | #130735 |
On 17/05/18 23:13, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 17/05/18 21:37, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 17/05/18 18:07, Keith Thompson wrote:
>>> [...]
>>>>> And then you could write:
>>>>>
>>>>> long x = 42;
>>>>> printf("x = %d\n", x);
> [typo corrected]
>>>>>
>>>>> and never know that there's a potential problem until you port the code
>>>>> to another system.
>>>>
>>>> Correct. That is perfectly fine for most of my code.
>>>
>>> It's perfectly fine to have code whose behavior is undefined but that
>>> happens to work on your system, that could be made completely portable
>>> by using "%ld" rather than "%d"?
>>>
>>> I don't mind making non-portable assumptions now and then, but printf
>>> formats are so easy to get right that I take the (small) extra effort to
>>> do so.
>>
>> In a case where you have a type like "long" or "int" it is easy to get
>> it right - it's rare you need a warning there.
>>
>> The discussion was on types like "int32_t" which might be "int" and
>> might be "long" on a platform with 32-bit int /and/ 32-bit long. That
>> is when I would be happier writing "printf("%x = %d\n", x);" /or/
>> "printf(%x = %ld\n", x);" regardless if int32_t happened to be "int" or
>> "long". That would mean that I would not get a warning in cases where I
>> had specifically picked "x" to be "long" and used it with "%d". That is
>> the price you have to pay for less strict warnings. (Usually I am a fan
>> of lots of strict warnings, but sometimes they get in the way.)
>
> gcc warns about format strings by default. You'd have to disable that
> warning explicitly.
>
> My solution:
>
> printf("x = %ld\n", (long)x);
>
> I know that long is wide enough to hold any value of type int32_t,
> and I know that "%ld" is the correct format for a long argument.
> (I *might* be lazy and use "%d" and (int) if I happen to know that
> int on the current system is at least 32 bits and/or that the value
> of x is small enough.)
>
That is also my solution in cases where portability might be relevant.
For much of my code, portability is not a big point and a large
proportion of my printf's are for early debugging only (and are
therefore only temporary), so "printf("x = %ld\n", x);" is good enough
for int32_t x.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-18 17:55 +0200 |
| Message-ID | <pdmt26$7be$1@dont-email.me> |
| In reply to | #130730 |
On 17/05/18 22:47, David Brown wrote:
> I think actually you could get quite close in C with variadic macros and
> generics. Like C++ std::cout, it would be hard to get something that
> worked well with translation strings.
>
OK, here is a rough try.
#include <stdio.h>
#define DEC_PRINT_EX(type, name, fs) \
static inline void print_##name##_ex(type x, const char* format) \
{ printf(format ? format : fs, x); }
DEC_PRINT_EX(unsigned int, uint, "%u")
DEC_PRINT_EX(int, int, "%i")
DEC_PRINT_EX(short int, short, "%i")
DEC_PRINT_EX(const char*, char_p, "%s")
#define PRINT_F(x, format, ...) \
_Generic((x), \
int : print_int_ex, \
unsigned int : print_uint_ex, \
short : print_short_ex, \
char * : print_char_p_ex \
)(x, format)
#define print_f(...) PRINT_F(__VA_ARGS__, 0, 0)
#define PRINT_S1(x) PRINT_F(x, 0, 0)
#define PRINT_S2(x, ...) PRINT_S1(x); PRINT_S1(__VA_ARGS__)
#define PRINT_S3(x, ...) PRINT_S1(x); PRINT_S2(__VA_ARGS__)
#define PRINT_S4(x, ...) PRINT_S1(x); PRINT_S3(__VA_ARGS__)
#define PRINT_S5(x, ...) PRINT_S1(x); PRINT_S4(__VA_ARGS__)
#define PRINT_S6(x, ...) PRINT_S1(x); PRINT_S5(__VA_ARGS__)
#define PRINT_S7(x, ...) PRINT_S1(x); PRINT_S6(__VA_ARGS__)
#define PRINT_S8(x, ...) PRINT_S1(x); PRINT_S7(__VA_ARGS__)
#define PRINT_S9(x, ...) PRINT_S1(x); PRINT_S8(__VA_ARGS__)
#define PRINT_S10(x, ...) PRINT_S1(x); PRINT_S9(__VA_ARGS__)
#define PRINT_SZ(a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, number, ...)\
PRINT_S##number
#define print_s(...) PRINT_SZ(__VA_ARGS__, 10, 9, 8, 7, 6, 5, 4, 3, 2,\
1)(__VA_ARGS__)
void test1(int x) {
print_f(x, "%04x");
// printf("%04x", x);
}
void test2(int x) {
print_f(2 * x);
// printf("%i, 2 * x);
}
void test3(int x) {
short y = x;
print_f(y);
// printf("%i", y);
}
void test4(void) {
short s = 123;
unsigned int t = 567;
print_s(s, t);
// printf("%i", s); printf("%i", t);
}
void test6(int x, short y, unsigned int z) {
print_s("x = ", x, "y = ", y, "z = ", z, "\n");
// printf("%s", "x = ");
// printf("%i", x);
// printf("%s", "y = ");
// printf("%i", y);
// printf("%s", "z = ");
// printf("%u", z);
// printf("%s", "\n");
}
It has the usual risk of complications from macros when evaluating
parameters twice, and so on.
Use of X-macros for combining the declarations of the static inline
functions and the _Generic is left as an exercise for the reader :-)
It would be possible to use the same system for types int32_t, uint16_t,
etc., rather than the fundamental types (pick one or the other).
(Note - I am not suggesting this is all a good idea. In fact, it makes
C++ variadic templates, function overloads, etc., look very appealing!)
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-18 08:59 -0700 |
| Message-ID | <1a1cceef-267f-49ec-8e40-8951bf425bcd@googlegroups.com> |
| In reply to | #130751 |
On Friday, May 18, 2018 at 8:55:58 AM UTC-7, David Brown wrote:
> On 17/05/18 22:47, David Brown wrote:
>
> > I think actually you could get quite close in C with variadic macros and
> > generics. Like C++ std::cout, it would be hard to get something that
> > worked well with translation strings.
> >
>
> OK, here is a rough try.
>
>
> #include <stdio.h>
>
> #define DEC_PRINT_EX(type, name, fs) \
> static inline void print_##name##_ex(type x, const char* format) \
> { printf(format ? format : fs, x); }
>
> DEC_PRINT_EX(unsigned int, uint, "%u")
> DEC_PRINT_EX(int, int, "%i")
> DEC_PRINT_EX(short int, short, "%i")
> DEC_PRINT_EX(const char*, char_p, "%s")
>
>
> #define PRINT_F(x, format, ...) \
> _Generic((x), \
> int : print_int_ex, \
> unsigned int : print_uint_ex, \
> short : print_short_ex, \
> char * : print_char_p_ex \
> )(x, format)
> #define print_f(...) PRINT_F(__VA_ARGS__, 0, 0)
>
> #define PRINT_S1(x) PRINT_F(x, 0, 0)
> #define PRINT_S2(x, ...) PRINT_S1(x); PRINT_S1(__VA_ARGS__)
> #define PRINT_S3(x, ...) PRINT_S1(x); PRINT_S2(__VA_ARGS__)
> #define PRINT_S4(x, ...) PRINT_S1(x); PRINT_S3(__VA_ARGS__)
> #define PRINT_S5(x, ...) PRINT_S1(x); PRINT_S4(__VA_ARGS__)
> #define PRINT_S6(x, ...) PRINT_S1(x); PRINT_S5(__VA_ARGS__)
> #define PRINT_S7(x, ...) PRINT_S1(x); PRINT_S6(__VA_ARGS__)
> #define PRINT_S8(x, ...) PRINT_S1(x); PRINT_S7(__VA_ARGS__)
> #define PRINT_S9(x, ...) PRINT_S1(x); PRINT_S8(__VA_ARGS__)
> #define PRINT_S10(x, ...) PRINT_S1(x); PRINT_S9(__VA_ARGS__)
> #define PRINT_SZ(a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, number, ...)\
> PRINT_S##number
> #define print_s(...) PRINT_SZ(__VA_ARGS__, 10, 9, 8, 7, 6, 5, 4, 3, 2,\
> 1)(__VA_ARGS__)
>
>
> void test1(int x) {
> print_f(x, "%04x");
> // printf("%04x", x);
> }
>
> void test2(int x) {
> print_f(2 * x);
> // printf("%i, 2 * x);
> }
> void test3(int x) {
> short y = x;
> print_f(y);
> // printf("%i", y);
> }
>
> void test4(void) {
> short s = 123;
> unsigned int t = 567;
> print_s(s, t);
> // printf("%i", s); printf("%i", t);
> }
>
> void test6(int x, short y, unsigned int z) {
> print_s("x = ", x, "y = ", y, "z = ", z, "\n");
> // printf("%s", "x = ");
> // printf("%i", x);
> // printf("%s", "y = ");
> // printf("%i", y);
> // printf("%s", "z = ");
> // printf("%u", z);
> // printf("%s", "\n");
> }
>
> It has the usual risk of complications from macros when evaluating
> parameters twice, and so on.
>
> Use of X-macros for combining the declarations of the static inline
> functions and the _Generic is left as an exercise for the reader :-)
>
> It would be possible to use the same system for types int32_t, uint16_t,
> etc., rather than the fundamental types (pick one or the other).
>
>
> (Note - I am not suggesting this is all a good idea. In fact, it makes
> C++ variadic templates, function overloads, etc., look very appealing!)
Steve Carroll is a false advocate's only reason for living.
Despite all the gloating owl's done on this topic, the 'UX Designer' doesn't understand how to do this. It only takes a couple seconds to click and drag across text and 'capitalize' it.
Playing with KDE... still a rookie... Lines of text containing tells. Virtually everything owl says about what Steve Carroll has done is dishonest. Who isn't aware of this by now? Once Steve Carroll understood how convincing owl is at playing 'fall guy' he realizes this is not quite as bizarre as it appeared.
A flaming bush that never burns, magnified by the reciprocal of an infinite twin prime, demonstrating the vast nothingness of owl's so-called thought process.
--
Puppy Videos
https://redd.it/6sfhq6
https://www.facebook.com/JonasEklundh
Jonas Eklundh Communication AB
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-18 10:17 -0700 |
| Message-ID | <c46c1d67-6a52-4cd7-aded-88c959593fa5@googlegroups.com> |
| In reply to | #130751 |
On Friday, May 18, 2018 at 10:55:58 AM UTC-5, David Brown wrote:
> #define print_f(...) PRINT_F(__VA_ARGS__, 0, 0)
>
> #define PRINT_S1(x) PRINT_F(x, 0, 0)
> #define PRINT_S2(x, ...) PRINT_S1(x); PRINT_S1(__VA_ARGS__)
> #define PRINT_S3(x, ...) PRINT_S1(x); PRINT_S2(__VA_ARGS__)
> #define PRINT_S4(x, ...) PRINT_S1(x); PRINT_S3(__VA_ARGS__)
> #define PRINT_S5(x, ...) PRINT_S1(x); PRINT_S4(__VA_ARGS__)
> #define PRINT_S6(x, ...) PRINT_S1(x); PRINT_S5(__VA_ARGS__)
> #define PRINT_S7(x, ...) PRINT_S1(x); PRINT_S6(__VA_ARGS__)
> #define PRINT_S8(x, ...) PRINT_S1(x); PRINT_S7(__VA_ARGS__)
> #define PRINT_S9(x, ...) PRINT_S1(x); PRINT_S8(__VA_ARGS__)
> #define PRINT_S10(x, ...) PRINT_S1(x); PRINT_S9(__VA_ARGS__)
> #define PRINT_SZ(a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, number, ...)\
> PRINT_S##number
> #define print_s(...) PRINT_SZ(__VA_ARGS__, 10, 9, 8, 7, 6, 5, 4, 3, 2,\
> 1)(__VA_ARGS__)
While that approach to variadic arguments will work if one can predict a
maximum number of arguments a function might need, it irks me that the
Standard didn't provide a means of specifying overloads, which could have
made things incredibly cleaner, e.g.
#define PRINT(x,y) doSomething(x,y)
#define +PRINT(x,y,...) PRINT(x,y) PRINT(x,__VA_ARGS)
where the "+" would mean "add overload", and where a macro invoked with
N arguments would be allowed to recursively invoke itself with any smaller
number of arguments (since the number of times any particular macro could
recursively invoke itself would be limited to the number of arguments).
I suppose that a construct which can be adjusted to accommodate the number
of parameters it needs isn't the worst thing in the world, but a general-
purpose utility really shouldn't need to impose such limitations.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> |
|---|---|
| Date | 2018-05-15 15:56 -0700 |
| Message-ID | <pdfoi2$718$1@dont-email.me> |
| In reply to | #130629 |
On 5/15/2018 2:36 PM, bartc wrote:
> 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').
[...]
Btw, thank you again bartc for tweaking your own compiler in order to
get my experimental generic c99 example to work on your end:
https://groups.google.com/d/topic/comp.lang.c/i31kS7cJ70w/discussion
wrt the specific post within the thread:
https://groups.google.com/d/msg/comp.lang.c/i31kS7cJ70w/cfkEVXjfAAAJ
:^)
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> |
|---|---|
| Date | 2018-05-15 15:59 -0700 |
| Message-ID | <pdfooe$718$2@dont-email.me> |
| In reply to | #130635 |
On 5/15/2018 3:56 PM, Chris M. Thomasson wrote:
> On 5/15/2018 2:36 PM, bartc wrote:
>> 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').
> [...]
>
> Btw, thank you again bartc for tweaking your own compiler in order to
> get my experimental generic c99 example to work on your end:
>
> https://groups.google.com/d/topic/comp.lang.c/i31kS7cJ70w/discussion
https://groups.google.com/d/msg/comp.lang.c/i31kS7cJ70w/cfkEVXjfAAAJ
>
> wrt the specific post within the thread:
>
> https://groups.google.com/d/msg/comp.lang.c/i31kS7cJ70w/cfkEVXjfAAAJ
>
> :^)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-05-15 15:15 -0700 |
| Message-ID | <4b9a164e-49c4-4815-a4fb-1506eb5fde50@googlegroups.com> |
| In reply to | #130626 |
On Tuesday, May 15, 2018 at 3:15:54 PM UTC-5, Keith Thompson wrote: > 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. While it may be useful to have a tool that can identify programs that are not Strictly Conforming, that does not mean that it is useful to expect implementations to do so any time they're asked to run programs, nor even to suggest that all quality implementations should be capable of doing so. If someone has six implementations, and one of them can do a really good job of validating that programs are Strictly Conforming, having the other five attempt to offer the same feature may not offer sufficient benefit to justify the costs.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-05-15 15:58 -0700 |
| Message-ID | <lnin7o5xwc.fsf@kst-u.example.com> |
| In reply to | #130633 |
supercat@casperkitty.com writes:
> On Tuesday, May 15, 2018 at 3:15:54 PM UTC-5, Keith Thompson wrote:
>> 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.
>
> While it may be useful to have a tool that can identify programs that are
> not Strictly Conforming,
Nobody was talking about strict conformance.
There is no requirement for any tool to identify programs that are not
strictly conforming, but all conforming C compilers are required to
diagnose constraint violations.
[SNIP]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Steve Carroll <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-05-15 16:48 -0700 |
| Message-ID | <753e92dc-df31-41f7-a52f-353311177678@googlegroups.com> |
| In reply to | #130633 |
On Tuesday, May 15, 2018 at 3:15:56 PM UTC-7, supe...@casperkitty.com wrote: > On Tuesday, May 15, 2018 at 3:15:54 PM UTC-5, Keith Thompson wrote: > > 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. > > While it may be useful to have a tool that can identify programs that are > not Strictly Conforming, that does not mean that it is useful to expect > implementations to do so any time they're asked to run programs, nor even > to suggest that all quality implementations should be capable of doing so. > If someone has six implementations, and one of them can do a really good > job of validating that programs are Strictly Conforming, having the other > five attempt to offer the same feature may not offer sufficient benefit to > justify the costs. It's simple to handpick by focusing on hardly any exceptions differing from what is the norm. What is more honest from an honest advocates way of thinking are the average operations. macOS's update system failed over and over again. BTW, I've already shown that his use of "cult-like" to describe true advocates is mud slinging, since he's likening them to hungry goats. The guy is as loved as a drunken karaoke singer -- and with good cause. - This broke the Internet http://www.5z8.info/michaelangelo-virus_t6v2vq_molotovcocktail http://bit.ly/2oNYRgv https://youtu.be/GPPqvw8iEBs Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2018-05-15 20:37 +0000 |
| Message-ID | <pdfge6$7l8$1@news.xmission.com> |
| In reply to | #130624 |
In article <ln1sec7kvw.fsf@kst-u.example.com>, Keith Thompson <kst-u@mib.org> wrote: ... >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. Do you ever listen to yourself? -- The people who tell us to be proud of the white race are the ones who make us the most embarrassed by it.
[toc] | [prev] | [next] | [standalone]
Page 11 of 12 — ← Prev page 1 … 9 10 [11] 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web