Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #109665 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2017-05-10 06:29 -0700 |
| Last post | 2017-06-05 13:50 -0700 |
| Articles | 20 on this page of 364 — 31 participants |
Back to article view | Back to comp.lang.c
If statement with initializer Thiago Adams <thiago.adams@gmail.com> - 2017-05-10 06:29 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-10 15:42 +0200
Re: If statement with initializer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-10 15:36 +0100
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-10 17:23 +0200
Re: If statement with initializer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-10 16:40 +0100
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-10 22:22 +0200
Re: If statement with initializer Manfred <noname@invalid.add> - 2017-05-13 17:15 +0200
Re: If statement with initializer "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-05-13 21:13 +0200
Re: If statement with initializer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-13 20:40 +0100
Re: If statement with initializer "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-05-13 22:30 +0200
Re: If statement with initializer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-13 22:01 +0100
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-14 16:20 +0200
Re: If statement with initializer "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-15 11:53 -0400
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-15 22:21 +0200
Re: If statement with initializer Manfred <noname@invalid.add> - 2017-05-13 17:24 +0200
Re: If statement with initializer Philip Lantz <prl@canterey.us> - 2017-05-14 16:10 -0700
Re: If statement with initializer Manfred <noname@invalid.add> - 2017-05-15 15:54 +0200
Re: If statement with initializer Thiago Adams <thiago.adams@gmail.com> - 2017-05-10 06:44 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-10 16:38 +0200
Re: If statement with initializer raltbos@xs4all.nl (Richard Bos) - 2017-05-15 12:49 +0000
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-15 15:39 +0200
Re: If statement with initializer Reinhardt Behm <rbehm@hushmail.com> - 2017-05-15 22:03 +0800
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-15 16:50 +0200
Re: If statement with initializer Keith Thompson <kst-u@mib.org> - 2017-05-15 10:02 -0700
Re: If statement with initializer Philip Lantz <prl@canterey.us> - 2017-05-18 19:05 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-19 08:57 +0200
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-15 07:14 -0700
Re: If statement with initializer joel.rees@gmail.com - 2017-05-16 23:11 -0700
Re: If statement with initializer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-17 14:26 +0100
Re: If statement with initializer supercat@casperkitty.com - 2017-05-17 08:40 -0700
Re: If statement with initializer David Kleinecke <dkleinecke@gmail.com> - 2017-05-18 18:59 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-19 09:04 +0200
Re: If statement with initializer supercat@casperkitty.com - 2017-05-19 07:33 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-19 18:17 +0200
Re: If statement with initializer supercat@casperkitty.com - 2017-05-19 09:53 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-19 19:20 +0200
Re: If statement with initializer supercat@casperkitty.com - 2017-05-19 10:45 -0700
Re: If statement with initializer supercat@casperkitty.com - 2017-05-19 11:27 -0700
Re: If statement with initializer Keith Thompson <kst-u@mib.org> - 2017-05-19 11:32 -0700
Re: If statement with initializer supercat@casperkitty.com - 2017-05-19 12:30 -0700
Re: If statement with initializer Keith Thompson <kst-u@mib.org> - 2017-05-19 13:45 -0700
Re: If statement with initializer GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-10 16:22 +0200
Re: If statement with initializer Thiago Adams <thiago.adams@gmail.com> - 2017-05-10 07:29 -0700
Re: If statement with initializer GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-10 17:40 +0200
Re: If statement with initializer supercat@casperkitty.com - 2017-05-10 08:48 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-10 22:24 +0200
Re: If statement with initializer supercat@casperkitty.com - 2017-05-10 13:29 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-10 23:27 +0200
Re: If statement with initializer Thiago Adams <thiago.adams@gmail.com> - 2017-05-10 09:40 -0700
Re: If statement with initializer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-10 19:15 +0100
Re: If statement with initializer Thiago Adams <thiago.adams@gmail.com> - 2017-05-10 11:22 -0700
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-10 18:06 +0100
Re: If statement with initializer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-10 19:19 +0100
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-10 20:19 +0100
Re: If statement with initializer Thiago Adams <thiago.adams@gmail.com> - 2017-05-10 13:21 -0700
Re: If statement with initializer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-10 22:16 +0100
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-10 23:31 +0200
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-10 22:50 +0100
Re: If statement with initializer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-11 01:15 +0100
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-11 14:15 +0100
Re: If statement with initializer supercat@casperkitty.com - 2017-05-11 08:17 -0700
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-11 19:00 +0100
Re: If statement with initializer supercat@casperkitty.com - 2017-05-11 11:49 -0700
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-11 20:51 +0100
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-12 20:02 +1200
Re: If statement with initializer Robert Wessel <robertwessel2@yahoo.com> - 2017-05-12 02:01 -0500
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-13 08:54 -0700
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-13 17:45 +0100
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 13:14 -0700
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-23 09:45 -0700
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-23 18:07 +0100
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-26 15:41 -0700
Re: If statement with initializer Robert Wessel <robertwessel2@yahoo.com> - 2017-05-14 16:20 -0500
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 19:14 -0700
Re: If statement with initializer Robert Wessel <robertwessel2@yahoo.com> - 2017-05-14 21:54 -0500
Re: If statement with initializer "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-05-15 07:01 +0200
Re: If statement with initializer Melzzzzz <Melzzzzz@zzzzz.com> - 2017-05-15 05:40 +0000
Re: If statement with initializer "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-05-15 19:59 +0200
Re: If statement with initializer Robert Wessel <robertwessel2@yahoo.com> - 2017-05-15 18:56 -0500
Re: If statement with initializer GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-15 09:31 +0200
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-15 06:55 -0700
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-15 10:33 -0700
Re: If statement with initializer supercat@casperkitty.com - 2017-05-15 10:54 -0700
Re: If statement with initializer Keith Thompson <kst-u@mib.org> - 2017-05-15 12:00 -0700
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-16 05:11 -0700
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-17 08:24 +1200
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-19 18:43 -0700
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-20 22:06 +1200
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-26 15:54 -0700
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-27 11:06 +1200
Re: If statement with initializer Robert Wessel <robertwessel2@yahoo.com> - 2017-05-15 19:15 -0500
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-16 12:54 -0700
Re: If statement with initializer Robert Wessel <robertwessel2@yahoo.com> - 2017-05-17 00:12 -0500
Re: If statement with initializer supercat@casperkitty.com - 2017-05-17 08:15 -0700
Re: If statement with initializer scott@slp53.sl.home (Scott Lurndal) - 2017-05-17 15:46 +0000
Re: If statement with initializer supercat@casperkitty.com - 2017-05-17 08:57 -0700
Re: If statement with initializer Keith Thompson <kst-u@mib.org> - 2017-05-17 09:45 -0700
Re: If statement with initializer supercat@casperkitty.com - 2017-05-17 10:09 -0700
Re: If statement with initializer Robert Wessel <robertwessel2@yahoo.com> - 2017-05-17 11:37 -0500
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-18 07:24 +1200
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-23 09:42 -0700
Re: If statement with initializer supercat@casperkitty.com - 2017-05-23 10:44 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-12 12:16 +0200
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-12 11:49 +0100
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-12 15:21 +0200
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-12 15:14 +0100
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-12 17:04 +0200
Re: If statement with initializer supercat@casperkitty.com - 2017-05-12 08:27 -0700
Re: If statement with initializer Thiago Adams <thiago.adams@gmail.com> - 2017-05-11 05:03 -0700
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-11 14:29 +0100
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-12 20:04 +1200
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 13:27 -0700
Re: If statement with initializer "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-05-11 21:56 +0200
Re: If statement with initializer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-11 23:27 +0100
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-12 00:26 +0100
Re: If statement with initializer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-12 01:16 +0100
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-12 01:35 +0100
Re: If statement with initializer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-12 01:58 +0100
Re: If statement with initializer "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-05-12 22:36 +0200
Re: If statement with initializer "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-05-12 22:19 +0200
Re: If statement with initializer "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-05-12 22:06 +0200
Re: If statement with initializer GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-12 02:09 +0200
Re: If statement with initializer "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-05-12 22:38 +0200
Re: If statement with initializer "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-12 17:15 -0400
Re: If statement with initializer supercat@casperkitty.com - 2017-05-12 15:10 -0700
Re: If statement with initializer Robert Wessel <robertwessel2@yahoo.com> - 2017-05-13 00:02 -0500
Re: If statement with initializer supercat@casperkitty.com - 2017-05-15 08:41 -0700
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-13 09:11 -0700
Re: If statement with initializer GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-13 00:59 +0200
Re: If statement with initializer Robert Wessel <robertwessel2@yahoo.com> - 2017-05-13 00:04 -0500
Re: If statement with initializer GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-13 13:17 +0200
Re: If statement with initializer jameskuyper@verizon.net - 2017-05-13 06:37 -0700
Re: If statement with initializer James Kuyper <jameskuyper@verizon.net> - 2017-05-13 10:29 -0400
Re: If statement with initializer GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-13 18:14 +0200
Re: If statement with initializer Keith Thompson <kst-u@mib.org> - 2017-05-13 14:04 -0700
Re: If statement with initializer GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-13 23:44 +0200
Re: If statement with initializer jameskuyper@verizon.net - 2017-05-13 18:22 -0700
Re: If statement with initializer GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-14 04:49 +0200
Re: If statement with initializer jameskuyper@verizon.net - 2017-05-13 20:23 -0700
Re: If statement with initializer GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-14 05:40 +0200
Re: If statement with initializer jameskuyper@verizon.net - 2017-05-14 06:42 -0700
Re: If statement with initializer GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-14 16:30 +0200
Re: If statement with initializer jameskuyper@verizon.net - 2017-05-16 08:19 -0700
Re: If statement with initializer "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-18 17:22 -0400
Re: If statement with initializer supercat@casperkitty.com - 2017-05-18 15:00 -0700
Re: If statement with initializer Keith Thompson <kst-u@mib.org> - 2017-05-18 16:20 -0700
Re: If statement with initializer supercat@casperkitty.com - 2017-05-18 16:33 -0700
Re: If statement with initializer luser droog <luser.droog@gmail.com> - 2017-05-18 15:58 -0700
Re: If statement with initializer supercat@casperkitty.com - 2017-05-18 16:24 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-19 09:13 +0200
Re: If statement with initializer raltbos@xs4all.nl (Richard Bos) - 2017-05-21 17:30 +0000
Re: If statement with initializer Keith Thompson <kst-u@mib.org> - 2017-05-14 12:40 -0700
Re: If statement with initializer Robert Wessel <robertwessel2@yahoo.com> - 2017-05-14 00:18 -0500
Re: If statement with initializer GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-14 14:45 +0200
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 00:08 -0700
Re: If statement with initializer "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-05-14 10:51 +0200
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 14:32 -0700
Re: If statement with initializer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-14 11:37 +0100
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-14 13:40 +0100
Re: If statement with initializer Manfred <invalid@invalid.add> - 2017-05-14 16:03 +0200
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-14 16:04 +0100
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-14 16:27 +0100
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 15:26 -0700
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-15 17:14 +1200
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-15 08:55 -0700
Re: If statement with initializer Gareth Owen <gwowen@gmail.com> - 2017-05-15 19:10 +0100
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-16 04:29 -0700
Re: If statement with initializer Gareth Owen <gwowen@gmail.com> - 2017-05-16 18:46 +0100
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-17 08:40 +1200
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-19 19:07 -0700
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-20 22:04 +1200
Re: If statement with initializer "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-05-14 11:09 +0200
Re: If statement with initializer GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-14 15:05 +0200
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-14 14:55 -0700
Re: If statement with initializer Alan Mackenzie <acm@muc.de> - 2017-05-12 16:25 +0000
Re: If statement with initializer joel.rees@gmail.com - 2017-05-10 16:45 -0700
Re: If statement with initializer Thiago Adams <thiago.adams@gmail.com> - 2017-05-11 05:07 -0700
Re: If statement with initializer Thiago Adams <thiago.adams@gmail.com> - 2017-05-11 05:10 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-11 14:29 +0200
Re: If statement with initializer raltbos@xs4all.nl (Richard Bos) - 2017-05-15 12:55 +0000
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-15 08:37 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-15 23:03 +0200
Re: If statement with initializer Richard Heathfield <rjh@cpax.org.uk> - 2017-05-15 22:12 +0100
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-15 23:29 +0200
Re: If statement with initializer Melzzzzz <Melzzzzz@zzzzz.com> - 2017-05-15 21:32 +0000
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-16 12:23 +0200
Re: If statement with initializer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-16 13:29 +0100
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-16 14:48 +0200
Re: If statement with initializer Manfred <invalid@invalid.add> - 2017-05-17 00:22 +0200
Re: If statement with initializer Manfred <invalid@invalid.add> - 2017-05-16 01:27 +0200
Re: If statement with initializer supercat@casperkitty.com - 2017-05-15 16:34 -0700
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-16 00:58 +0100
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-16 12:32 +0200
Re: If statement with initializer supercat@casperkitty.com - 2017-05-16 08:59 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-16 22:28 +0200
Re: If statement with initializer supercat@casperkitty.com - 2017-05-16 14:20 -0700
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-17 10:24 -0700
Re: If statement with initializer supercat@casperkitty.com - 2017-05-17 10:42 -0700
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-24 08:14 -0700
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-16 17:31 +1200
Re: If statement with initializer Melzzzzz <Melzzzzz@zzzzz.com> - 2017-05-15 21:31 +0000
Re: If statement with initializer Richard Heathfield <rjh@cpax.org.uk> - 2017-05-15 22:39 +0100
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-17 10:52 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-17 23:14 +0200
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-18 18:24 +1200
Re: If statement with initializer joel.rees@gmail.com - 2017-05-18 05:43 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-18 15:13 +0200
Re: If statement with initializer joel.rees@gmail.com - 2017-05-18 08:52 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-18 22:18 +0200
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-19 08:29 +1200
Re: If statement with initializer DFS <nospam@dfs.com> - 2017-05-18 21:59 -0400
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-19 19:30 +1200
Re: If statement with initializer scott@slp53.sl.home (Scott Lurndal) - 2017-05-19 12:34 +0000
Re: If statement with initializer Thiago Adams <thiago.adams@gmail.com> - 2017-05-19 06:37 -0700
Re: If statement with initializer Robert Wessel <robertwessel2@yahoo.com> - 2017-05-18 22:09 -0500
Re: If statement with initializer scott@slp53.sl.home (Scott Lurndal) - 2017-05-18 13:59 +0000
Re: If statement with initializer Keith Thompson <kst-u@mib.org> - 2017-05-18 09:21 -0700
Re: If statement with initializer "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-18 12:55 -0400
Re: If statement with initializer joel.rees@gmail.com - 2017-05-19 01:17 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-19 12:16 +0200
Re: If statement with initializer Richard Heathfield <rjh@cpax.org.uk> - 2017-05-19 11:58 +0100
Re: If statement with initializer joel.rees@gmail.com - 2017-05-20 03:20 -0700
Re: If statement with initializer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-20 15:18 +0100
Re: If statement with initializer James Kuyper <jameskuyper@verizon.net> - 2017-05-20 10:55 -0400
Re: If statement with initializer joel.rees@gmail.com - 2017-05-21 01:29 -0700
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-21 20:39 +1200
Re: If statement with initializer GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-21 14:15 +0200
Re: If statement with initializer James Kuyper <jameskuyper@verizon.net> - 2017-05-21 15:29 -0400
Re: If statement with initializer joel.rees@gmail.com - 2017-05-22 23:38 -0700
Re: If statement with initializer Keith Thompson <kst-u@mib.org> - 2017-05-23 00:16 -0700
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-23 19:26 +1200
Re: If statement with initializer joel.rees@gmail.com - 2017-05-23 16:25 -0700
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-24 20:38 +1200
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-23 09:33 +0200
Re: If statement with initializer James Kuyper <jameskuyper@verizon.net> - 2017-05-23 08:00 -0400
Re: If statement with initializer supercat@casperkitty.com - 2017-05-23 08:27 -0700
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-24 07:17 +1200
Re: If statement with initializer supercat@casperkitty.com - 2017-05-23 12:28 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-24 10:04 +0200
Re: If statement with initializer raltbos@xs4all.nl (Richard Bos) - 2017-05-24 16:30 +0000
Re: If statement with initializer "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-24 15:01 -0400
Re: If statement with initializer supercat@casperkitty.com - 2017-05-24 13:04 -0700
Re: If statement with initializer joel.rees@gmail.com - 2017-05-24 14:55 -0700
Re: If statement with initializer Keith Thompson <kst-u@mib.org> - 2017-05-24 16:23 -0700
Re: If statement with initializer raltbos@xs4all.nl (Richard Bos) - 2017-05-21 18:01 +0000
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-22 10:04 +0200
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-24 08:10 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-24 17:54 +0200
Re: If statement with initializer "James R. Kuyper" <jameskuyper@verizon.net> - 2017-05-19 12:39 -0400
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-24 07:55 -0700
Re: If statement with initializer Ike Naar <ike@iceland.freeshell.org> - 2017-05-17 21:14 +0000
Re: If statement with initializer raltbos@xs4all.nl (Richard Bos) - 2017-05-21 17:34 +0000
Re: If statement with initializer Richard Heathfield <rjh@cpax.org.uk> - 2017-05-21 19:40 +0100
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-22 10:13 +0200
Re: If statement with initializer Gareth Owen <gwowen@gmail.com> - 2017-05-15 22:16 +0100
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-17 11:44 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-17 23:30 +0200
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-18 18:30 +1200
Re: If statement with initializer joel.rees@gmail.com - 2017-05-18 06:04 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-18 17:29 +0200
Re: If statement with initializer GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-17 23:37 +0200
Re: If statement with initializer Robert Wessel <robertwessel2@yahoo.com> - 2017-05-15 18:41 -0500
Re: If statement with initializer "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-05-15 17:39 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-16 12:35 +0200
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-17 11:50 -0700
Re: If statement with initializer GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-15 19:17 +0200
Re: If statement with initializer scott@slp53.sl.home (Scott Lurndal) - 2017-05-15 17:57 +0000
Re: If statement with initializer Robert Wessel <robertwessel2@yahoo.com> - 2017-05-15 18:51 -0500
Re: If statement with initializer scott@slp53.sl.home (Scott Lurndal) - 2017-05-16 13:17 +0000
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-16 14:29 +0100
Re: If statement with initializer scott@slp53.sl.home (Scott Lurndal) - 2017-05-16 14:50 +0000
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-16 16:35 +0100
Re: If statement with initializer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-16 17:33 +0100
Re: If statement with initializer raltbos@xs4all.nl (Richard Bos) - 2017-05-21 18:05 +0000
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-16 17:29 +0200
Re: If statement with initializer Keith Thompson <kst-u@mib.org> - 2017-05-11 09:10 -0700
Re: If statement with initializer Thiago Adams <thiago.adams@gmail.com> - 2017-05-11 09:49 -0700
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-11 18:51 +0100
Re: If statement with initializer Thiago Adams <thiago.adams@gmail.com> - 2017-05-11 11:19 -0700
Re: If statement with initializer scott@slp53.sl.home (Scott Lurndal) - 2017-05-11 18:31 +0000
Re: If statement with initializer Keith Thompson <kst-u@mib.org> - 2017-05-11 11:59 -0700
Re: If statement with initializer David Kleinecke <dkleinecke@gmail.com> - 2017-05-11 12:58 -0700
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-11 21:18 +0100
Re: If statement with initializer Thiago Adams <thiago.adams@gmail.com> - 2017-05-11 13:45 -0700
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-12 20:08 +1200
Re: If statement with initializer Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-12 01:37 -0700
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-12 12:08 +0100
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-12 15:31 +0200
Re: If statement with initializer Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-12 07:03 -0700
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-12 15:21 +0100
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-12 17:06 +0200
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-12 16:36 +0100
Re: If statement with initializer David Kleinecke <dkleinecke@gmail.com> - 2017-05-12 11:58 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-14 17:03 +0200
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-14 16:15 +0100
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-14 23:25 +0200
Re: If statement with initializer Keith Thompson <kst-u@mib.org> - 2017-05-14 13:55 -0700
Re: If statement with initializer Gareth Owen <gwowen@gmail.com> - 2017-05-15 19:00 +0100
Re: If statement with initializer raltbos@xs4all.nl (Richard Bos) - 2017-05-14 13:38 +0000
Re: If statement with initializer GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-14 16:42 +0200
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-14 17:07 +0200
Re: If statement with initializer Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-14 08:12 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-14 23:27 +0200
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-15 16:59 +1200
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-15 11:33 +0200
Re: If statement with initializer raltbos@xs4all.nl (Richard Bos) - 2017-05-15 12:59 +0000
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-12 12:34 +0200
Re: If statement with initializer David Kleinecke <dkleinecke@gmail.com> - 2017-05-12 11:48 -0700
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-13 07:41 +1200
Re: If statement with initializer David Kleinecke <dkleinecke@gmail.com> - 2017-05-12 17:38 -0700
Re: If statement with initializer GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-13 01:23 +0200
Re: If statement with initializer "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-05-13 08:55 +0200
Re: If statement with initializer GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-13 13:24 +0200
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-13 14:53 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-14 17:10 +0200
Re: If statement with initializer raltbos@xs4all.nl (Richard Bos) - 2017-05-15 12:56 +0000
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-15 07:15 -0700
Re: If statement with initializer Robert Wessel <robertwessel2@yahoo.com> - 2017-05-11 13:49 -0500
Re: If statement with initializer "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-05-11 21:57 +0200
Re: If statement with initializer Keith Thompson <kst-u@mib.org> - 2017-05-11 13:11 -0700
Re: If statement with initializer "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-05-11 22:21 +0200
Re: If statement with initializer Thiago Adams <thiago.adams@gmail.com> - 2017-05-11 13:56 -0700
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-12 12:42 +0200
Re: If statement with initializer Robert Wessel <robertwessel2@yahoo.com> - 2017-05-11 15:44 -0500
Re: If statement with initializer Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-11 23:13 +0100
Re: If statement with initializer scott@slp53.sl.home (Scott Lurndal) - 2017-05-12 16:16 +0000
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-12 12:35 +0200
Re: If statement with initializer Richard Heathfield <rjh@cpax.org.uk> - 2017-05-12 11:41 +0100
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-12 17:27 +0200
Re: If statement with initializer Robert Wessel <robertwessel2@yahoo.com> - 2017-05-12 10:57 -0500
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-14 17:15 +0200
Re: If statement with initializer joel.rees@gmail.com - 2017-05-12 06:55 -0700
Re: If statement with initializer raltbos@xs4all.nl (Richard Bos) - 2017-05-15 12:35 +0000
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-16 07:41 +1200
Re: If statement with initializer GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-15 21:46 +0200
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-15 21:36 +0100
Re: If statement with initializer Thiago Adams <thiago.adams@gmail.com> - 2017-05-15 13:44 -0700
Re: If statement with initializer jameskuyper@verizon.net - 2017-05-15 14:23 -0700
Re: If statement with initializer supercat@casperkitty.com - 2017-05-15 14:36 -0700
Re: If statement with initializer jameskuyper@verizon.net - 2017-05-15 15:27 -0700
Re: If statement with initializer supercat@casperkitty.com - 2017-05-15 16:21 -0700
Re: If statement with initializer jameskuyper@verizon.net - 2017-05-16 07:47 -0700
Re: If statement with initializer GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-05-15 23:39 +0200
Re: If statement with initializer Keith Thompson <kst-u@mib.org> - 2017-05-15 15:42 -0700
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-16 00:03 +0100
Re: If statement with initializer Ian Collins <ian-news@hotmail.com> - 2017-05-16 17:33 +1200
Re: If statement with initializer Richard Heathfield <rjh@cpax.org.uk> - 2017-05-16 12:03 +0100
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-16 14:34 +0200
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-16 14:20 +0100
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-16 17:37 +0200
Re: If statement with initializer Keith Thompson <kst-u@mib.org> - 2017-05-16 09:10 -0700
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-16 17:26 +0100
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-16 19:28 +0100
Re: If statement with initializer scott@slp53.sl.home (Scott Lurndal) - 2017-05-16 18:53 +0000
Re: If statement with initializer bartc <bc@freeuk.com> - 2017-05-16 20:17 +0100
Re: If statement with initializer scott@slp53.sl.home (Scott Lurndal) - 2017-05-16 20:03 +0000
Re: If statement with initializer David Brown <david.brown@hesbynett.no> - 2017-05-16 22:34 +0200
Re: If statement with initializer supercat@casperkitty.com - 2017-05-15 14:24 -0700
Re: If statement with initializer raltbos@xs4all.nl (Richard Bos) - 2017-05-24 20:49 +0000
Re: If statement with initializer supercat@casperkitty.com - 2017-05-24 14:11 -0700
Re: If statement with initializer raltbos@xs4all.nl (Richard Bos) - 2017-05-24 21:37 +0000
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-26 15:52 -0700
Re: If statement with initializer raltbos@xs4all.nl (Richard Bos) - 2017-06-03 10:20 +0000
Re: If statement with initializer Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-05 13:50 -0700
Page 11 of 19 — ← Prev page 1 … 9 10 [11] 12 13 … 19 Next page →
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2017-05-15 21:31 +0000 |
| Message-ID | <ofd6n9$r1q$3@news.albasani.net> |
| In reply to | #110084 |
On 2017-05-15, Richard Heathfield <rjh@cpax.org.uk> wrote: > On 15/05/17 22:03, David Brown wrote: ><snip> >> >> So when picking a digit separator for C, I see four options: >> >> 1. Have no separator. That avoids any work at all, and has no >> conflicts, but gives no advantages. >> >> 2. Have underscores as a separator. That makes things as nice as >> possible for C, but introduces an inconsistency between the languages. >> This is a big disadvantage in the eyes of many - especially, perhaps, >> embedded programmers who regularly combine C and C++ code in the same >> program and who are likely to be amongst the heaviest users of the >> feature (especially for binary literals). >> >> 3. Have a single quote for a separator. That keeps consistency with >> C++, but does so by making C's choice as ugly as that of C++. >> >> 4. Allow both as separators in C. Developers can choose to write nice C >> code, or C code that is consistent with C++. But that also means they >> can write ugly C code, and C code that is /inconsistent/ with C++. > > 5. Use the comma, as God intended. > > I know what you're thinking. What about the existing comma operator and > separator? > > Well, any sensible person puts at least one whitespace character after > such commas, so we need only insist that the digit separator is preceded > and followed by a digit character. Thus: > > 1,234,567 /* one integer constant */ > > 1, 234, 567 /* three integer constants in something like an initialiser > or a function call */ > > This way, yes, we'd break some code, but only code that deserves to be > broken. > Hm, why does it deserve to be broken? -- press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-05-15 22:39 +0100 |
| Message-ID | <ofd6vj$v5n$1@dont-email.me> |
| In reply to | #110090 |
On 15/05/17 22:31, Melzzzzz wrote: > On 2017-05-15, Richard Heathfield <rjh@cpax.org.uk> wrote: >> On 15/05/17 22:03, David Brown wrote: >> <snip> >>> >>> So when picking a digit separator for C, I see four options: >>> >>> 1. Have no separator. That avoids any work at all, and has no >>> conflicts, but gives no advantages. >>> >>> 2. Have underscores as a separator. That makes things as nice as >>> possible for C, but introduces an inconsistency between the languages. >>> This is a big disadvantage in the eyes of many - especially, perhaps, >>> embedded programmers who regularly combine C and C++ code in the same >>> program and who are likely to be amongst the heaviest users of the >>> feature (especially for binary literals). >>> >>> 3. Have a single quote for a separator. That keeps consistency with >>> C++, but does so by making C's choice as ugly as that of C++. >>> >>> 4. Allow both as separators in C. Developers can choose to write nice C >>> code, or C code that is consistent with C++. But that also means they >>> can write ugly C code, and C code that is /inconsistent/ with C++. >> >> 5. Use the comma, as God intended. >> >> I know what you're thinking. What about the existing comma operator and >> separator? >> >> Well, any sensible person puts at least one whitespace character after >> such commas, so we need only insist that the digit separator is preceded >> and followed by a digit character. Thus: >> >> 1,234,567 /* one integer constant */ >> >> 1, 234, 567 /* three integer constants in something like an initialiser >> or a function call */ >> >> This way, yes, we'd break some code, but only code that deserves to be >> broken. >> > Hm, why does it deserve to be broken? ^^^^ You see? Comma separators are followed by white-space. People who don't do that need a good kicking. Excuse me. People who don't do that need to be moved to Marketing. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-17 10:52 -0700 |
| Message-ID | <kfnr2znl6a2.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #110084 |
Richard Heathfield <rjh@cpax.org.uk> writes: > On 15/05/17 22:03, David Brown wrote: > <snip> > >> So when picking a digit separator for C, I see four options: >> >> 1. Have no separator. That avoids any work at all, and has no >> conflicts, but gives no advantages. >> >> 2. Have underscores as a separator. That makes things as nice as >> possible for C, but introduces an inconsistency between the languages. >> This is a big disadvantage in the eyes of many - especially, perhaps, >> embedded programmers who regularly combine C and C++ code in the same >> program and who are likely to be amongst the heaviest users of the >> feature (especially for binary literals). >> >> 3. Have a single quote for a separator. That keeps consistency with >> C++, but does so by making C's choice as ugly as that of C++. >> >> 4. Allow both as separators in C. Developers can choose to write nice C >> code, or C code that is consistent with C++. But that also means they >> can write ugly C code, and C code that is /inconsistent/ with C++. > > 5. Use the comma, [...elaboration...] In C the only sensible choice is underscore (assuming of course option (1) has been ruled out). Using underscore is consistent with identifiers, consistent with what most other programming languages allow (disclaimer: I have only anecdotal data here, nothing systematic), and consistent with C's current rules for numeric pre-processing tokens. The other characters mentioned (comma, single quote) complicate the lexing process, not just for compilers but for all the other tools that look at C lexically. Using whitespace to differentiate two forms of comma gives rise to problems during pre-processing, where whitespace can be significant for other reasons. (Further comments on single quote in a separate posting.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-17 23:14 +0200 |
| Message-ID | <ofie9j$1rm$1@dont-email.me> |
| In reply to | #110226 |
On 17/05/17 19:52, Tim Rentsch wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> On 15/05/17 22:03, David Brown wrote:
>> <snip>
>>
>>> So when picking a digit separator for C, I see four options:
>>>
>>> 1. Have no separator. That avoids any work at all, and has no
>>> conflicts, but gives no advantages.
>>>
>>> 2. Have underscores as a separator. That makes things as nice as
>>> possible for C, but introduces an inconsistency between the languages.
>>> This is a big disadvantage in the eyes of many - especially, perhaps,
>>> embedded programmers who regularly combine C and C++ code in the same
>>> program and who are likely to be amongst the heaviest users of the
>>> feature (especially for binary literals).
>>>
>>> 3. Have a single quote for a separator. That keeps consistency with
>>> C++, but does so by making C's choice as ugly as that of C++.
>>>
>>> 4. Allow both as separators in C. Developers can choose to write nice C
>>> code, or C code that is consistent with C++. But that also means they
>>> can write ugly C code, and C code that is /inconsistent/ with C++.
>>
>> 5. Use the comma, [...elaboration...]
>
> In C the only sensible choice is underscore (assuming of course
> option (1) has been ruled out). Using underscore is consistent
> with identifiers, consistent with what most other programming
> languages allow (disclaimer: I have only anecdotal data here,
> nothing systematic),
Consistency with other programming languages is a useful trait. But far
and away the most relevant language for C to be consistent with, is C++.
How many C programmers use C++ at least some of the time? A sizeable
fraction, I think (no statistics or references). How many C programmers
use Ada, Java, D, Perl or Ruby? Relatively few - and when they do, they
are clearly programming in a different language and not a near-subset
language.
In particular, how many header files are written in a way that they are
directly useable as either C or C++ ? A hefty proportion of C headers,
especially for libraries or code designed for re-use, starts with:
#ifdef __cplusplus
extern "C" {
#endif
Do you /really/ think it is more important for C code to have a digit
separator that is consistent with Java, than to be consistent with C++?
Given a free choice, of course it would be best if C++ had been able to
use an underscore as their digit separator, consistent with several
other programming languages. But that bridge has been crossed and burned.
> and consistent with C's current rules for
> numeric pre-processing tokens. The other characters mentioned
> (comma, single quote) complicate the lexing process, not just
> for compilers but for all the other tools that look at C
> lexically.
How many serious C compilers and other C parsing tools do not also
support C++? The implementation of parsers that handle a single quote
mark for digit separators is already complete - making it work in C mode
as well as C++ mode is going to be a minor matter. And by the time a
hypothetical future C standard supports digit separators, it's a fair
bet that most of these tools will have been updated to C++14.
> Using whitespace to differentiate two forms of
> comma gives rise to problems during pre-processing, where
> whitespace can be significant for other reasons. (Further
> comments on single quote in a separate posting.)
>
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-05-18 18:24 +1200 |
| Message-ID | <eo4t1jFhtkdU3@mid.individual.net> |
| In reply to | #110234 |
On 05/18/17 09:14 AM, David Brown wrote: > On 17/05/17 19:52, Tim Rentsch wrote: > >> and consistent with C's current rules for >> numeric pre-processing tokens. The other characters mentioned >> (comma, single quote) complicate the lexing process, not just >> for compilers but for all the other tools that look at C >> lexically. > > How many serious C compilers and other C parsing tools do not also > support C++? The implementation of parsers that handle a single quote > mark for digit separators is already complete - making it work in C mode > as well as C++ mode is going to be a minor matter. And by the time a > hypothetical future C standard supports digit separators, it's a fair > bet that most of these tools will have been updated to C++14. Most already do and have done so for a while. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-18 05:43 -0700 |
| Message-ID | <cbc892a0-78da-4855-be53-1703e120b8a7@googlegroups.com> |
| In reply to | #110234 |
On Thursday, May 18, 2017 at 6:14:44 AM UTC+9, David Brown wrote:
> On 17/05/17 19:52, Tim Rentsch wrote:
> > Richard Heathfield <rjh@somewhere> writes:
> >
> >> On 15/05/17 22:03, David Brown wrote:
> >> <snip>
> >>
> >>> So when picking a digit separator for C, I see four options:
> >>>
> >>> 1. Have no separator. That avoids any work at all, and has no
> >>> conflicts, but gives no advantages.
> >>>
> >>> 2. Have underscores as a separator. That makes things as nice as
> >>> possible for C, but introduces an inconsistency between the languages.
> >>> This is a big disadvantage in the eyes of many - especially, perhaps,
> >>> embedded programmers who regularly combine C and C++ code in the same
> >>> program and who are likely to be amongst the heaviest users of the
> >>> feature (especially for binary literals).
> >>>
> >>> 3. Have a single quote for a separator. That keeps consistency with
> >>> C++, but does so by making C's choice as ugly as that of C++.
> >>>
> >>> 4. Allow both as separators in C. Developers can choose to write nice C
> >>> code, or C code that is consistent with C++. But that also means they
> >>> can write ugly C code, and C code that is /inconsistent/ with C++.
> >>
> >> 5. Use the comma, [...elaboration...]
> >
> > In C the only sensible choice is underscore (assuming of course
> > option (1) has been ruled out). Using underscore is consistent
> > with identifiers, consistent with what most other programming
> > languages allow (disclaimer: I have only anecdotal data here,
> > nothing systematic),
>
> Consistency with other programming languages is a useful trait.
Consistency is a hobgoblin.
> But far
> and away the most relevant language for C to be consistent with, is C++.
> How many C programmers use C++ at least some of the time? A sizeable
> fraction, I think (no statistics or references).
I don't use C++. I do use Ada, Java, Perl, Forth, and a few others.
I used to be something of an oddity. But more and more, the target
domains are diverging.
> How many C programmers
> use Ada, Java, D, Perl or Ruby? Relatively few - and when they do, they
> are clearly programming in a different language and not a near-subset
> language.
Near subsets cause far more problems than substantial differences.
Since C++ became something more than a preprocessor trick, it has
been wisest to just separate the lexers and parsers completely. Near
similarities provide the most opportunities for mistakes.
> In particular, how many header files are written in a way that they are
> directly useable as either C or C++ ?
Not without the compiler going through a mode change.
> A hefty proportion of C headers,
> especially for libraries or code designed for re-use, starts with:
>
> #ifdef __cplusplus
> extern "C" {
> #endif
As I said.
> Do you /really/ think it is more important for C code to have a digit
> separator that is consistent with Java, than to be consistent with C++?
I don't think a digit separator is a good thing unless it is space or
maybe underscore. There's only so much overloading syntax you can do
before things start interacting with each other in weird ways.
(Which is one of the reasons I don't even try to mess with C++ any more.)
> Given a free choice, of course it would be best if C++ had been able to
> use an underscore as their digit separator, consistent with several
> other programming languages. But that bridge has been crossed and burned.
Because the C++ community burns the wrong bridges, everyone should.
(And what is this with Java and Perl? They are pretty close to C, too.)
> > and consistent with C's current rules for
> > numeric pre-processing tokens. The other characters mentioned
> > (comma, single quote) complicate the lexing process, not just
> > for compilers but for all the other tools that look at C
> > lexically.
>
> How many serious C compilers and other C parsing tools do not also
> support C++?
In addition to Pascal, Fortran, Objective C, Ada, ....
> The implementation of parsers that handle a single quote
> mark for digit separators is already complete - making it work in C mode
> as well as C++ mode is going to be a minor matter. And by the time a
> hypothetical future C standard supports digit separators, it's a fair
> bet that most of these tools will have been updated to C++14.
Companies still trash resumes that claim C/C++ skills because they
assume that someone who really knows both won't group them that way.
The languages began diverging 30 years ago. They aren't really all
that close any more.
> > Using whitespace to differentiate two forms of
> > comma gives rise to problems during pre-processing, where
> > whitespace can be significant for other reasons. (Further
> > comments on single quote in a separate posting.)
> >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-18 15:13 +0200 |
| Message-ID | <ofk6fe$5tm$1@dont-email.me> |
| In reply to | #110267 |
On 18/05/17 14:43, joel.rees@gmail.com wrote:
> On Thursday, May 18, 2017 at 6:14:44 AM UTC+9, David Brown wrote:
>> On 17/05/17 19:52, Tim Rentsch wrote:
>>> Richard Heathfield <rjh@somewhere> writes:
>> Consistency with other programming languages is a useful trait.
>
> Consistency is a hobgoblin.
No - it is mostly a useful trait. It makes learning easier. (It also
makes it easier to implement tools such as editors for multiple languages.)
>
>> But far
>> and away the most relevant language for C to be consistent with, is C++.
>> How many C programmers use C++ at least some of the time? A sizeable
>> fraction, I think (no statistics or references).
>
> I don't use C++. I do use Ada, Java, Perl, Forth, and a few others.
As I say, I have no statistics - but I suspect you are an outlier here.
>
> I used to be something of an oddity. But more and more, the target
> domains are diverging.
It is certainly not uncommon to deal with more than one different
programming language. But I strongly suspect that if you ask C
programmers what other languages they use regularly, C++ will come up
more often than Perl or Java - and certainly more often than Ada or
Forth. (On the other hand, if you ask Ada or Forth programmers what
other languages they use, C will be common - it is not symmetrical.)
>
>> How many C programmers
>> use Ada, Java, D, Perl or Ruby? Relatively few - and when they do, they
>> are clearly programming in a different language and not a near-subset
>> language.
>
> Near subsets cause far more problems than substantial differences.
That would be the case if the differences were significant, occurred
often in normal coding, and were not caught be automated tools (such as
the compiler). For example, there is no issue with C++'s requirement
that void* pointers be explicitly cast - either you add a cast and then
C and C++ do the same thing, or you omit the cast and your C++ compiler
tells you of the problem. You have to use unusual code, such as relying
on the value of "sizeof 'a'", to get something that compiles cleaning as
C and as C++ but with different meaning.
>
> Since C++ became something more than a preprocessor trick, it has
> been wisest to just separate the lexers and parsers completely. Near
> similarities provide the most opportunities for mistakes.
>
>> In particular, how many header files are written in a way that they are
>> directly useable as either C or C++ ?
>
> Not without the compiler going through a mode change.
>
>> A hefty proportion of C headers,
>> especially for libraries or code designed for re-use, starts with:
>>
>> #ifdef __cplusplus
>> extern "C" {
>> #endif
>
> As I said.
That is not a "mode change". In C, the pre-processor skips that bit.
In C++, it applies the "extern "C" {" - but it does not change "modes"
between C and C++.
>
>> Do you /really/ think it is more important for C code to have a digit
>> separator that is consistent with Java, than to be consistent with C++?
>
> I don't think a digit separator is a good thing unless it is space or
> maybe underscore. There's only so much overloading syntax you can do
> before things start interacting with each other in weird ways.
>
> (Which is one of the reasons I don't even try to mess with C++ any more.)
If you don't like C++, that's fine - people have many good reasons for
avoiding it. But there are a lot of people who /do/ use it, and who
also use C.
>
>> Given a free choice, of course it would be best if C++ had been able to
>> use an underscore as their digit separator, consistent with several
>> other programming languages. But that bridge has been crossed and burned.
>
> Because the C++ community burns the wrong bridges, everyone should.
>
No, of course not. But when one community makes a decision, other
related communities may need to take it into consideration.
> (And what is this with Java and Perl? They are pretty close to C, too.)
Perl is not close to C, unless you mean they both use curly brackets.
Java is somewhat related to C, but more closely related to C++.
>
>>> and consistent with C's current rules for
>>> numeric pre-processing tokens. The other characters mentioned
>>> (comma, single quote) complicate the lexing process, not just
>>> for compilers but for all the other tools that look at C
>>> lexically.
>>
>> How many serious C compilers and other C parsing tools do not also
>> support C++?
>
> In addition to Pascal, Fortran, Objective C, Ada, ....
Some tools support such a wide range - many do not.
>
>> The implementation of parsers that handle a single quote
>> mark for digit separators is already complete - making it work in C mode
>> as well as C++ mode is going to be a minor matter. And by the time a
>> hypothetical future C standard supports digit separators, it's a fair
>> bet that most of these tools will have been updated to C++14.
>
> Companies still trash resumes that claim C/C++ skills because they
> assume that someone who really knows both won't group them that way.
I agree with that attitude. I am not suggesting that writing code in
the C/C++ common subset is a good idea in general, or will result in the
best C code or the best C++ code. It may be fairly close to good
quality C code, but is likely to be non-idiomatic in places and perhaps
miss out on some features. And it will be way off base for C++ code.
Still I maintain that it is an advantage to many developers if the
fraction of C that is in common with C++ is as large as reasonably
possible, and that this consistency is a good thing for programmers.
(As has been mentioned in other posts, the situation could be improved
by C++ adopting some of the features of C that it is missing.)
>
> The languages began diverging 30 years ago. They aren't really all
> that close any more.
>
>>> Using whitespace to differentiate two forms of
>>> comma gives rise to problems during pre-processing, where
>>> whitespace can be significant for other reasons. (Further
>>> comments on single quote in a separate posting.)
>>>
>
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-18 08:52 -0700 |
| Message-ID | <fd45aaa6-fcf2-41e8-81d1-4580fbd1329d@googlegroups.com> |
| In reply to | #110272 |
On Thursday, May 18, 2017 at 10:13:37 PM UTC+9, David Brown wrote:
> On 18/05/17 14:43, joel.rees@somewhere wrote:
> > On Thursday, May 18, 2017 at 6:14:44 AM UTC+9, David Brown wrote:
> >> On 17/05/17 19:52, Tim Rentsch wrote:
> >>> Richard Heathfield <rjh@somewhere> writes:
>
> >> Consistency with other programming languages is a useful trait.
> >
> > Consistency is a hobgoblin.
>
> No - it is mostly a useful trait. It makes learning easier. (It also
> makes it easier to implement tools such as editors for multiple languages.)
I've found trying to be consistent getting me in trouble often enough
to go with the other quote. (Scott.)
> >
> >> But far
> >> and away the most relevant language for C to be consistent with, is C++.
> >> How many C programmers use C++ at least some of the time? A sizeable
> >> fraction, I think (no statistics or references).
> >
> > I don't use C++. I do use Ada, Java, Perl, Forth, and a few others.
>
> As I say, I have no statistics - but I suspect you are an outlier here.
Not any more.
> > I used to be something of an oddity. But more and more, the target
> > domains are diverging.
>
> It is certainly not uncommon to deal with more than one different
> programming language. But I strongly suspect that if you ask C
> programmers what other languages they use regularly, C++ will come up
> more often than Perl or Java - and certainly more often than Ada or
> Forth. (On the other hand, if you ask Ada or Forth programmers what
> other languages they use, C will be common - it is not symmetrical.)
I strongly suspect that if you ask C++ programmers what other languages
they work with, they will say, Java, javascript, Python, Ruby, and C.
But they would likely be wrong about C.
> >> How many C programmers
> >> use Ada, Java, D, Perl or Ruby? Relatively few - and when they do, they
> >> are clearly programming in a different language and not a near-subset
> >> language.
> >
> > Near subsets cause far more problems than substantial differences.
>
> That would be the case if the differences were significant, occurred
> often in normal coding, and were not caught be automated tools (such as
> the compiler).
How often do you use the macro preprocessor (directly) when you program
in C++?
How often do you use class syntax when you program in C?
> For example, there is no issue with C++'s requirement
> that void* pointers be explicitly cast - either you add a cast and then
> C and C++ do the same thing, or you omit the cast and your C++ compiler
> tells you of the problem. You have to use unusual code, such as relying
> on the value of "sizeof 'a'", to get something that compiles cleaning as
> C and as C++ but with different meaning.
I suppose you may think so, but that is not the bulk of your code.
> > Since C++ became something more than a preprocessor trick, it has
> > been wisest to just separate the lexers and parsers completely. Near
> > similarities provide the most opportunities for mistakes.
> >
> >> In particular, how many header files are written in a way that they are
> >> directly useable as either C or C++ ?
> >
> > Not without the compiler going through a mode change.
> >
> >> A hefty proportion of C headers,
> >> especially for libraries or code designed for re-use, starts with:
> >>
> >> #ifdef __cplusplus
> >> extern "C" {
> >> #endif
> >
> > As I said.
>
> That is not a "mode change". In C, the pre-processor skips that bit.
> In C++, it applies the "extern "C" {" - but it does not change "modes"
> between C and C++.
Bwahahahahahahahahah.
Sorry. I'm not in the mood to be polite. Not sure why.
> >> Do you /really/ think it is more important for C code to have a digit
> >> separator that is consistent with Java, than to be consistent with C++?
> >
> > I don't think a digit separator is a good thing unless it is space or
> > maybe underscore. There's only so much overloading syntax you can do
> > before things start interacting with each other in weird ways.
> > (Which is one of the reasons I don't even try to mess with C++ any more.)
>
> If you don't like C++, that's fine - people have many good reasons for
> avoiding it. But there are a lot of people who /do/ use it, and who
> also use C.
A lot of people who use C++ and think they use C.
There are a huge lot of programmers you've never met because they use C
and not C++ and have no need of going to your C++ conferences.
> >> Given a free choice, of course it would be best if C++ had been able to
> >> use an underscore as their digit separator, consistent with several
> >> other programming languages. But that bridge has been crossed and burned.
> >
> > Because the C++ community burns the wrong bridges, everyone should.
> >
>
> No, of course not. But when one community makes a decision, other
> related communities may need to take it into consideration.
And may not be profited by letting it distract them too much.
> > (And what is this with Java and Perl? They are pretty close to C, too.)
>
> Perl is not close to C, unless you mean they both use curly brackets.
> Java is somewhat related to C, but more closely related to C++.
And you say C++ is close to C. C++ is closer to Java than C.
> >>> and consistent with C's current rules for
> >>> numeric pre-processing tokens. The other characters mentioned
> >>> (comma, single quote) complicate the lexing process, not just
> >>> for compilers but for all the other tools that look at C
> >>> lexically.
> >>
> >> How many serious C compilers and other C parsing tools do not also
> >> support C++?
> >
> > In addition to Pascal, Fortran, Objective C, Ada, ....
>
> Some tools support such a wide range - many do not.
Does Clang compile Fortran?
> >> The implementation of parsers that handle a single quote
> >> mark for digit separators is already complete - making it work in C mode
> >> as well as C++ mode is going to be a minor matter. And by the time a
> >> hypothetical future C standard supports digit separators, it's a fair
> >> bet that most of these tools will have been updated to C++14.
> >
> > Companies still trash resumes that claim C/C++ skills because they
> > assume that someone who really knows both won't group them that way.
>
> I agree with that attitude. I am not suggesting that writing code in
> the C/C++ common subset is a good idea in general, or will result in the
> best C code or the best C++ code. It may be fairly close to good
> quality C code, but is likely to be non-idiomatic in places and perhaps
> miss out on some features. And it will be way off base for C++ code.
And yet you say C and C++ are close.
That is why I'm not in the mood to be polite.
> Still I maintain that it is an advantage to many developers if the
> fraction of C that is in common with C++ is as large as reasonably
> possible, and that this consistency is a good thing for programmers.
>
> (As has been mentioned in other posts, the situation could be improved
> by C++ adopting some of the features of C that it is missing.)
No. The C++ standards committee should go its own way.
You guys are big boys now.
> > The languages began diverging 30 years ago. They aren't really all
> > that close any more.
> >
> >>> Using whitespace to differentiate two forms of
> >>> comma gives rise to problems during pre-processing, where
> >>> whitespace can be significant for other reasons. (Further
> >>> comments on single quote in a separate posting.)
In a more sober and less hyperbolic tone, I hope --
The time for consolidation is past.
The new frontier is specialization, focusing on individuals and
small communities.
And that does mean that we need to quit trying to focus on a
single standard. We *can* focus on commonalities, but we *need*
to focus on the differences as well.
Languages do color their idioms.
--
Joel Rees
Random rants:
http://reiisi.blogspot.com
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-18 22:18 +0200 |
| Message-ID | <ofkvbv$ut4$1@dont-email.me> |
| In reply to | #110304 |
On 18/05/17 17:52, joel.rees@gmail.com wrote: > On Thursday, May 18, 2017 at 10:13:37 PM UTC+9, David Brown wrote: >> On 18/05/17 14:43, joel.rees@somewhere wrote: >>> On Thursday, May 18, 2017 at 6:14:44 AM UTC+9, David Brown wrote: >>>> On 17/05/17 19:52, Tim Rentsch wrote: >>>>> Richard Heathfield <rjh@somewhere> writes: >> >> No, of course not. But when one community makes a decision, other >> related communities may need to take it into consideration. > > And may not be profited by letting it distract them too much. We are not talking absolutes here - I said C has to take the decisions of C++ into consideration, not follow them blindly. > >>> (And what is this with Java and Perl? They are pretty close to C, too.) >> >> Perl is not close to C, unless you mean they both use curly brackets. >> Java is somewhat related to C, but more closely related to C++. > > And you say C++ is close to C. C++ is closer to Java than C. I said that C++ is mostly a superset of C. There are features in C that C++ does not have, and a few points where they both have a feature but there are differences. That is not the same thing as saying that C++ is close to C. > >>>>> and consistent with C's current rules for >>>>> numeric pre-processing tokens. The other characters mentioned >>>>> (comma, single quote) complicate the lexing process, not just >>>>> for compilers but for all the other tools that look at C >>>>> lexically. >>>> >>>> How many serious C compilers and other C parsing tools do not also >>>> support C++? >>> >>> In addition to Pascal, Fortran, Objective C, Ada, .... >> >> Some tools support such a wide range - many do not. > > Does Clang compile Fortran? I don't know, but I don't see how the question is relevant. > >>>> The implementation of parsers that handle a single quote >>>> mark for digit separators is already complete - making it work in C mode >>>> as well as C++ mode is going to be a minor matter. And by the time a >>>> hypothetical future C standard supports digit separators, it's a fair >>>> bet that most of these tools will have been updated to C++14. >>> >>> Companies still trash resumes that claim C/C++ skills because they >>> assume that someone who really knows both won't group them that way. >> >> I agree with that attitude. I am not suggesting that writing code in >> the C/C++ common subset is a good idea in general, or will result in the >> best C code or the best C++ code. It may be fairly close to good >> quality C code, but is likely to be non-idiomatic in places and perhaps >> miss out on some features. And it will be way off base for C++ code. > > And yet you say C and C++ are close. No, I said that they share a sizeable common subset that covers much of C. C++ has a great deal of features that are not in C - that is both its advantage and its disadvantage compared to C. > > That is why I'm not in the mood to be polite. I am fine with you making direct statements, but we would get on better here if you avoided misinterpreting me. I really don't think I have been unclear here, but let me know if you think I have. > >> Still I maintain that it is an advantage to many developers if the >> fraction of C that is in common with C++ is as large as reasonably >> possible, and that this consistency is a good thing for programmers. >> >> (As has been mentioned in other posts, the situation could be improved >> by C++ adopting some of the features of C that it is missing.) > > No. The C++ standards committee should go its own way. > A lot of C++ programmers think C++ would benefit from designated initialisers, and probably also compound literals and VLAs (there was an attempt to make a "dynamic array" STL container as an equivalent to VLAs, but it collapsed because it could not actually be implemented). > You guys are big boys now. "You guys" - you still think I am a C++ programmer, advocate, addict, or something? > >>> The languages began diverging 30 years ago. They aren't really all >>> that close any more. >>> >>>>> Using whitespace to differentiate two forms of >>>>> comma gives rise to problems during pre-processing, where >>>>> whitespace can be significant for other reasons. (Further >>>>> comments on single quote in a separate posting.) > > In a more sober and less hyperbolic tone, I hope -- > > The time for consolidation is past. > > The new frontier is specialization, focusing on individuals and > small communities. As someone working in one of the major areas for C - embedded development - I can tell you that mixing and combining C and C++ is alive and well, and will be for the foreseeable future. Specialising and "going their own way" is /not/ helpful. Fortunately, it appears the C and C++ standards committees think cooperation and coordination is a good thing, even though the languages have different focuses. > > And that does mean that we need to quit trying to focus on a > single standard. We *can* focus on commonalities, but we *need* > to focus on the differences as well. Oh, I agree that there are differences in the languages and that they have different aims and focuses. I just want cooperation on the areas of obvious overlaps - I think it would be downright idiotic if both languages support something as simple as digit separators, and they did it in different ways. > > Languages do color their idioms. > > -- > Joel Rees > > Random rants: > http://reiisi.blogspot.com >
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-05-19 08:29 +1200 |
| Message-ID | <eo6eh9FhtkdU7@mid.individual.net> |
| In reply to | #110304 |
On 05/19/17 03:52 AM, joel.rees@gmail.com wrote: > On Thursday, May 18, 2017 at 10:13:37 PM UTC+9, David Brown wrote: >> >> It is certainly not uncommon to deal with more than one different >> programming language. But I strongly suspect that if you ask C >> programmers what other languages they use regularly, C++ will come up >> more often than Perl or Java - and certainly more often than Ada or >> Forth. (On the other hand, if you ask Ada or Forth programmers what >> other languages they use, C will be common - it is not symmetrical.) > > I strongly suspect that if you ask C++ programmers what other languages > they work with, they will say, Java, javascript, Python, Ruby, and C. > > But they would likely be wrong about C. That I doubt. Working with C in kernel space and C++ in the application space is a common combination, at least in the embedded Linux world I've inhabited for the past few years. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2017-05-18 21:59 -0400 |
| Message-ID | <oflja0$mde$3@dont-email.me> |
| In reply to | #110330 |
On 5/18/2017 4:29 PM, Ian Collins wrote: > Working with C in kernel space and C++ in the application > space is a common combination, at least in the embedded Linux world I've > inhabited for the past few years. What kind of devices do you code for? Embedded coding always seemed interesting to me.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-05-19 19:30 +1200 |
| Message-ID | <eo7l94FhtkdU8@mid.individual.net> |
| In reply to | #110349 |
On 05/19/17 01:59 PM, DFS wrote: > On 5/18/2017 4:29 PM, Ian Collins wrote: > >> Working with C in kernel space and C++ in the application >> space is a common combination, at least in the embedded Linux world I've >> inhabited for the past few years. > > What kind of devices do you code for? > > Embedded coding always seemed interesting to me. Currently the "smarts" that tell (big) excavator operators where to dig. All of the network connected embedded devices I have worked on in recent years have been C++ on Linux, so there's a nice mix of C kernel/driver work and c++ applications. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-05-19 12:34 +0000 |
| Message-ID | <nDBTA.105513$MW5.25861@fx36.iad> |
| In reply to | #110330 |
Ian Collins <ian-news@hotmail.com> writes: >On 05/19/17 03:52 AM, joel.rees@gmail.com wrote: >> On Thursday, May 18, 2017 at 10:13:37 PM UTC+9, David Brown wrote: >>> >>> It is certainly not uncommon to deal with more than one different >>> programming language. But I strongly suspect that if you ask C >>> programmers what other languages they use regularly, C++ will come up >>> more often than Perl or Java - and certainly more often than Ada or >>> Forth. (On the other hand, if you ask Ada or Forth programmers what >>> other languages they use, C will be common - it is not symmetrical.) >> >> I strongly suspect that if you ask C++ programmers what other languages >> they work with, they will say, Java, javascript, Python, Ruby, and C. >> >> But they would likely be wrong about C. > >That I doubt. Working with C in kernel space and C++ in the application >space is a common combination, at least in the embedded Linux world I've >inhabited for the past few years. Although I've written parts of two kernels and a hypervisor that were written in a subset of C++ (no STL, no exceptions, no RTTI). Basically C with classes, which is my preferred dialect of C++.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2017-05-19 06:37 -0700 |
| Message-ID | <ce696dda-2b03-4769-b0f9-284fedd50e28@googlegroups.com> |
| In reply to | #110373 |
On Friday, May 19, 2017 at 9:34:33 AM UTC-3, Scott Lurndal wrote:
> Ian Collins writes:
> >On 05/19/17 03:52 AM, wrote:
> >> On Thursday, May 18, 2017 at 10:13:37 PM UTC+9, David Brown wrote:
> >>>
> >>> It is certainly not uncommon to deal with more than one different
> >>> programming language. But I strongly suspect that if you ask C
> >>> programmers what other languages they use regularly, C++ will come up
> >>> more often than Perl or Java - and certainly more often than Ada or
> >>> Forth. (On the other hand, if you ask Ada or Forth programmers what
> >>> other languages they use, C will be common - it is not symmetrical.)
> >>
> >> I strongly suspect that if you ask C++ programmers what other languages
> >> they work with, they will say, Java, javascript, Python, Ruby, and C.
> >>
> >> But they would likely be wrong about C.
> >
> >That I doubt. Working with C in kernel space and C++ in the application
> >space is a common combination, at least in the embedded Linux world I've
> >inhabited for the past few years.
>
> Although I've written parts of two kernels and a hypervisor that were
> written in a subset of C++ (no STL, no exceptions, no RTTI). Basically
> C with classes, which is my preferred dialect of C++.
My preferred dialect of C++ is C99 with templates.
It solves the problem of algorithms and containers.
I think the concept of classes is a little broken and inconsistent.
The following sample in C++ have a lot of samples
of the features I would use.
template <class T>
T* New() {
T* p = (T*)malloc(sizeof T);
if (p) {
*p = T(); //(T){}
}
return p;
}
template <class T>
void Delete(T* p) {
if (p) {
Destroy(p);
free(p);
}
}
typedef char* String;
void Destroy(String* s) {
free(*s);
}
struct Node {
String Name = NULL;
Node* pNext = NULL;
};
void Destroy(Node* p) {
Destroy(&p->Name);
}
template <class T>
struct List {
T* pHead = NULL;
T* pTail = NULL;
};
template <class T>
void Destroy(List<T>* p) {
T* pItem = p->pHead;
while (pItem) {
T* pCurrent = pItem;
pItem = pItem->pNext;
Delete(pCurrent);
}
}
template <class T>
void Add(List<T>* pList, T* pItem) {
if (pList->pHead == NULL) {
pList->pHead = pItem;
} else {
pList->pTail->pNext = pItem;
;
}
pList->pTail = pItem;
}
int main() {
Node* p = New<Node>();
List<Node> list = List<Node>(); //{}
Add(&list, p);
p = NULL;
Delete(p);
Destroy(&list);
return 0;
}
And here the version using C99
static inline void* allocate_and_copy(void *s, size_t n)
{
void* pNew = malloc(n);
if (pNew)
{
memcpy(pNew, s, n);
}
return pNew;
}
#define New(...) allocate_and_copy(&(__VA_ARGS__), sizeof(__VA_ARGS__))
#define Delete(T, p)\
while (p) {\
T##_Destroy(p);\
free(p);\
break;\
}
typedef char* String;
void String_Destroy(String* s) {
free(*s);
}
typedef struct Node {
String Name /*= NULL*/;
struct Node* pNext /*= NULL*/;
} Node;
void Node_Destroy(Node* p) {
String_Destroy(&p->Name);
}
#define List(T)\
struct List {\
T* pHead;\
T* pTail;\
}
#define List_Destroy(T, p)\
while ((p)->pHead) {\
T* pCurrent = (p)->pHead;\
(p)->pHead = (p)->pHead->pNext;\
Delete(T, pCurrent);\
}
#define Add(pList, pItem) \
if ((pList)->pHead == NULL) {\
(pList)->pHead = (pItem); \
(pList)->pTail = (pItem);\
}\
else {\
(pList)->pTail->pNext = (pItem); \
(pList)->pTail = (pItem);\
}
int main() {
Node* p = New((Node){0});
List(Node) list = { 0 };
Add(&list, p);
p = NULL;
Delete(Node, p);
List_Destroy(Node, &list);
return 0;
}
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-18 22:09 -0500 |
| Message-ID | <99oshc90cs9mugqg2cc58avre57du3co6j@4ax.com> |
| In reply to | #110304 |
On Thu, 18 May 2017 08:52:33 -0700 (PDT), joel.rees@gmail.com wrote: >Does Clang compile Fortran? Well, no. Clang is the C family (C, C++, Objective-C and some others) front end to LLVM. There are a number of other front ends to LLVM, including a Fortran one.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-05-18 13:59 +0000 |
| Message-ID | <8NhTA.110465$se.92334@fx38.iad> |
| In reply to | #110267 |
joel.rees@gmail.com writes: >On Thursday, May 18, 2017 at 6:14:44 AM UTC+9, David Brown wrote: >> > In C the only sensible choice is underscore (assuming of course >> > option (1) has been ruled out). Using underscore is consistent >> > with identifiers, consistent with what most other programming >> > languages allow (disclaimer: I have only anecdotal data here, >> > nothing systematic), >> >> Consistency with other programming languages is a useful trait. > >Consistency is a hobgoblin. The proper quotation is "Foolish consistency is the hobgoblin of small minds". - Emerson Now, consistency between C and C++ is hardly foolish.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-18 09:21 -0700 |
| Message-ID | <ln60gy2l0b.fsf@kst-u.example.com> |
| In reply to | #110279 |
scott@slp53.sl.home (Scott Lurndal) writes:
> joel.rees@gmail.com writes:
[...]
>>Consistency is a hobgoblin.
>
> The proper quotation is
>
> "Foolish consistency is the hobgoblin of small minds". - Emerson
No, it's "A foolish consistency is the hobgoblin of little minds, adored
by little statesmen and philosophers and divines."
http://www.goodreads.com/quotes/353571-a-foolish-consistency-is-the-hobgoblin-of-little-minds-adored
has more context.
--
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 | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-05-18 12:55 -0400 |
| Message-ID | <e46c95c0-7aee-db18-adb4-2972a611ff08@verizon.net> |
| In reply to | #110267 |
On 05/18/2017 08:43 AM, joel.rees@gmail.com wrote: > On Thursday, May 18, 2017 at 6:14:44 AM UTC+9, David Brown wrote: ... >> Consistency with other programming languages is a useful trait. > > Consistency is a hobgoblin. The quote refers to "A foolish consistency"; there's nothing particularly foolish about this one. ... > Companies still trash resumes that claim C/C++ skills because they > assume that someone who really knows both won't group them that way. > > The languages began diverging 30 years ago. They aren't really all > that close any more. You can take almost any C program that has no syntax errors, constraint violations, or undefined behavior, and, with only minor modifications, convert it into code that has precisely the same defined behavior, whether compiled as C code or as C++ code. That would not be true if the languages had diverged as badly as you're suggesting. Each version of the C standard since C90 has added features that have no counterpart in C++, but later versions of C++ have often added some of those same features. The ones that haven't yet been added to C++, are relatively few, and not yet widely used. The biggest exceptions are things like designated intializers and compound literals, but those are merely convenience features for which there exists less convenient ways to write the same thing that do have the same meaning in C and in C++.
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-19 01:17 -0700 |
| Message-ID | <4688f099-0e01-43ce-bd85-a7f89df934c4@googlegroups.com> |
| In reply to | #110314 |
On Friday, May 19, 2017 at 1:55:15 AM UTC+9, James R. Kuyper wrote: > On 05/18/2017 08:43 AM, joel.rees@somewhere wrote: > > On Thursday, May 18, 2017 at 6:14:44 AM UTC+9, David Brown wrote: > ... > >> Consistency with other programming languages is a useful trait. > > > > Consistency is a hobgoblin. > > The quote refers to "A foolish consistency"; there's nothing > particularly foolish about this one. > > ... > > Companies still trash resumes that claim C/C++ skills because they > > assume that someone who really knows both won't group them that way. > > > > The languages began diverging 30 years ago. They aren't really all > > that close any more. > > You can take almost any C program that has no syntax errors, constraint > violations, or undefined behavior, and, with only minor modifications, > convert it into code that has precisely the same defined behavior, > whether compiled as C code or as C++ code. That would not be true if the > languages had diverged as badly as you're suggesting. > Each version of the C standard since C90 has added features that have no > counterpart in C++, but later versions of C++ have often added some of > those same features. The ones that haven't yet been added to C++, are > relatively few, and not yet widely used. The biggest exceptions are > things like designated intializers and compound literals, but those are > merely convenience features for which there exists less convenient ways > to write the same thing that do have the same meaning in C and in C++. Okay, you can write usable source in the mutual subset. I'm not sure that some of my source that I think (heh) is valid C will be compilable as C++ without some serious dinking in the details. Going from C++ to C, of course, is a no-starter. Twenty years ago, I put a lot of effort into learning how to write in the subset. That effort derailed a couple of my private projects and at least one project at work. It would not be going too far to say trying to use that subset may have been one of the factors in my being asked to quit that company. -- Joel Rees Trying to reinvent the industry all by myself: http://defining-computers.blogspot.jp/
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-19 12:16 +0200 |
| Message-ID | <ofmgg8$3jp$1@dont-email.me> |
| In reply to | #110363 |
On 19/05/17 10:17, joel.rees@gmail.com wrote: > On Friday, May 19, 2017 at 1:55:15 AM UTC+9, James R. Kuyper wrote: >> On 05/18/2017 08:43 AM, joel.rees@somewhere wrote: >>> On Thursday, May 18, 2017 at 6:14:44 AM UTC+9, David Brown wrote: >> ... >>>> Consistency with other programming languages is a useful trait. >>> >>> Consistency is a hobgoblin. >> >> The quote refers to "A foolish consistency"; there's nothing >> particularly foolish about this one. >> >> ... >>> Companies still trash resumes that claim C/C++ skills because they >>> assume that someone who really knows both won't group them that way. >>> >>> The languages began diverging 30 years ago. They aren't really all >>> that close any more. >> >> You can take almost any C program that has no syntax errors, constraint >> violations, or undefined behavior, and, with only minor modifications, >> convert it into code that has precisely the same defined behavior, >> whether compiled as C code or as C++ code. That would not be true if the >> languages had diverged as badly as you're suggesting. >> Each version of the C standard since C90 has added features that have no >> counterpart in C++, but later versions of C++ have often added some of >> those same features. The ones that haven't yet been added to C++, are >> relatively few, and not yet widely used. The biggest exceptions are >> things like designated intializers and compound literals, but those are >> merely convenience features for which there exists less convenient ways >> to write the same thing that do have the same meaning in C and in C++. > > Okay, you can write usable source in the mutual subset. > > I'm not sure that some of my source that I think (heh) is valid C will > be compilable as C++ without some serious dinking in the details. > > Going from C++ to C, of course, is a no-starter. > > Twenty years ago, I put a lot of effort into learning how to write in the > subset. That effort derailed a couple of my private projects and at least > one project at work. It would not be going too far to say trying to use > that subset may have been one of the factors in my being asked to quit > that company. > I really cannot comprehend why you think this is such a big deal. It is /not/ hard to write C in a C++ compatible subset. It does not take "a lot of effort" to learn. It might mean a change in your style of C, and it means a few non-idiomatic points, but it is not difficult. As you say, modern idiomatic C++ cannot be made C compatible in any practical manner.
[toc] | [prev] | [next] | [standalone]
Page 11 of 19 — ← Prev page 1 … 9 10 [11] 12 13 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web