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 13 of 19 — ← Prev page 1 … 11 12 [13] 14 15 … 19 Next page →
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-05-24 15:01 -0400 |
| Message-ID | <606dbb98-9503-0ad3-6038-ac653f735c06@verizon.net> |
| In reply to | #110448 |
On 05/20/2017 06:20 AM, joel.rees@gmail.com wrote:
...
> The source code is here:
>
> https://sourceforge.net/p/bif-c/code/HEAD/tree/trunk/
I finally took the time to look at your code, and discovered a key
problem. You need to be very clear what your target language is, and
them make sure your code is consistent with that choice. Here's why
that's a problem:
definition_header_s is a typedef for a struct type containing a flexible
array member named parameterLink. Unless you change that, your code has
no chance of being compatible with C++, or even with C90. However, it's
much worse than that. You've defined objects of that types with static
storage duration, with initializers for those objects that include
values to be placed in parameterLink.
Standard C doesn't allow that. For struct types containing flexible
array members, "... the size of the structure is as if the flexible
array member were omitted except that it may have more trailing padding
than the omission would imply." 6.7.2.1p18. Therefore, when an object of
such a type is allocated with static, thread, or automatic storage
duration, there is no space specially set aside for the elements of the
flexible array. If the struct has a lot of padding at the end, there
might incidentally be enough space for a few elements of the flexible
array. For example, if double has both a size of 8 and an alignment
requirement of 8, then the following struct type must have an alignment
requirement of at least 8:
struct {
double d;
char c;
char string[];
} dstring;
which implies that dstring must be big enough to store at least 7
elements in dstring.string. However, in general, you cannot count on
there being any space for any elements in the flexible array. Providing
initializers for those non-existent elements is therefore a constraint
violation.
All of the examples in the standard involving flexible array members
create the structs with allocated storage duration, in which case it's
possible to ensure that there's enough space for the desired number of
elements in the flexible array. It should be possible to reserve enough
space for a non-zero number of flexible array members by putting the
struct type in a union with a bigger object, but the standard contains
no examples of how to do that. The required syntax is functionally
equivalent to defining a fixed-length array rather than a flexible one,
while being more complicated than that approach, so I wouldn't recommend
trying that.
Since your code does compile for you, and for me when I use gcc with the
options you specify, it must be relying upon an extension to C which
allows you to provide initializers for the flexible array, and makes
sure that enough space is allocated to store all of those initializers.
This is an entirely reasonable extension, and I would have no objection
to changing standard C to support it - but as it stands, it is an
extension - your code has undefined behavior as far as standard C is
concerned.
The thing to keep in mind is that most C compilers do NOT fully conform
to any particular version of the C standard unless you explicitly tell
them too. Unless you select a -std= option for gcc, it implements GnuC,
not standard C. GnuC is a language distinct from, but very similar to,
standard C. It has many conforming extensions to C, but it also supports
many non-conforming extensions as well.
GnuC is one of the most widely used and most widely available C-like
alternatives to standard C. If you are willing to restrict the
portability of your code to GnuC, I can't really fault that decision -
it's a fairly popular one. But you need to be aware that this is what
you are doing. You should be making this decision explicitly, not as an
accident due to being unfamiliar with the differences between GnuC and
standard C. Most importantly, your documentation for your program should
explicitly state that you're relying upon GnuC.
Note that flexible array members are not supported by C++; this is a
legitimate example of a divergence between the two languages. However,
it is not a counter-example to my claim - there are alternatives to
using flexible array members that provide similar functionality, and
they can be implemented in a way that has the exact same defined
behavior in C and C++. However, those alternatives are not as flexible,
simple, or as elegant as the code you're currently using that relies
upon an extension to C. Using those alternatives would NOT count as
making your code better - flexible array members were invented precisely
because they are a better approach than those alternatives. Explaining
those alternatives is complicated, and I can't spare the time right now
to go into details. However, if you're really interested, I may be able
to find time later.
Removing your code's reliance on this extension would be complicated,
which is one reason I don't think you're likely to make that choice.
However, if you do want to change your code to use standard C rather
than GnuC, you have a couple of options:
1. Target C99, which allows you to continue using flexible array
members, but requires that you allocate the memory for them using
malloc(), calloc(), or realloc().
2. Target C90, and make use of the struct hack. De jure, the struct hack
has undefined behavior in all versions of both C and C++, so it isn't in
the common subset. However, de facto, the struct hack is so popular that
most implementations of C and C++ can be trusted to allow it to work.
Therefore, de facto, you would still be in the common subset of those
languages. You still need to allocate the required memory using
malloc(), calloc(), or realloc().
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-24 13:04 -0700 |
| Message-ID | <3c3f6245-72b5-4952-b8db-f6fddc8218ac@googlegroups.com> |
| In reply to | #110573 |
On Wednesday, May 24, 2017 at 2:01:25 PM UTC-5, James R. Kuyper wrote:
> Standard C doesn't allow that. For struct types containing flexible
> array members, "... the size of the structure is as if the flexible
> array member were omitted except that it may have more trailing padding
> than the omission would imply." 6.7.2.1p18. Therefore, when an object of
> such a type is allocated with static, thread, or automatic storage
> duration, there is no space specially set aside for the elements of the
> flexible array. If the struct has a lot of padding at the end, there
> might incidentally be enough space for a few elements of the flexible
> array. For example, if double has both a size of 8 and an alignment
> requirement of 8, then the following struct type must have an alignment
> requirement of at least 8:
>
> struct {
> double d;
> char c;
> char string[];
> } dstring;
>
> which implies that dstring must be big enough to store at least 7
> elements in dstring.string. However, in general, you cannot count on
> there being any space for any elements in the flexible array. Providing
> initializers for those non-existent elements is therefore a constraint
> violation.
What would you make of something like:
#include <stdint.h>
#include <stdio.h>
#include <assert.h>
#include <stddef.h>
typedef struct { char const *st; uint16_t size; uint16_t arr[]; } foo;
typedef struct { char const *st; uint16_t size; uint16_t arr[8]; } foo8;
_Static_assert(offsetof(foo, arr) == offsetof(foo8,arr),
"Invalid array offset");
typedef union { foo8 f8; foo f; } foo8u;
foo8u myFooXX = {{"Hello",8,{1,2,3,4,5,6,7,8}}};
#define myFoo (myFooXX.f)
void useFoo(foo *p)
{
printf("(%s:", p->st);
for (int i=0; i < p->size; i++)
printf(" %d", p->arr[i]);
printf(")\n");
}
void test(void)
{
printf("Printing foo of size %d:\n", myFoo.size);
useFoo(&myFoo);
}
By my reading, the static assert could fail in a conforming implementation,
though I don't know of any where it would. On any implementation where the
static assert succeeds, the address of the flexible array member would be
guaranteed to coincide with that of the corresponding member in the fixed-
sized structure, which would have room for 8 elements.
I don't particularly like the #define, but unless code tries to use the
same name in a nested scope it shouldn't cause trouble. There are only
two problems I see with the approach:
1. The Standard as written would require that every different size of
structure which might be used by useFoo must be declared before it,
and unless code wants to use C11-specific designated-initializer
syntax it would as a practical measure have to define a separate
union type for each size of structure, which listed the structure of
that size as its first member.
2. The way gcc and clang interpret the Standard, there is no way to
implement such a construct with defined behavior, except through the
use of gcc-specific extensions.
Were it not for the first issue, client code could be written somewhat more
cleanly as:
// Library header
#define makeInitializedFoo(name, s,sz,...) \
union { struct { char const *st; uint16_t size; uint16_t arr[sz];}; foo f;} name = \
{{s,sz,__VA_ARGS__}}
// Client code
makeInitializedFoo(myFoo2, "myFoo", 4, {1,2,3,4});
I see no reason it shouldn't be practical to have the Standard require
compilers to recognize Common-Initial-Sequence aliasing between struct
types that are visible in a union *either* when a member is written *or*
when it's read back, or why compilers that are trying to be helpful
shouldn't recognize aliasing in such cases, but compiler writers demand
that programmers to jump through silly hoops and regard any code that
doesn't do so as "broken".
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-24 14:55 -0700 |
| Message-ID | <f9b0bc03-5c9c-4be4-b6f6-fa29608f7bc8@googlegroups.com> |
| In reply to | #110573 |
On Thursday, May 25, 2017 at 4:01:25 AM UTC+9, James R. Kuyper wrote:
> On 05/20/2017 06:20 AM, joel.rees@somewhere wrote:
> ...
> > The source code is here:
> >
> > https://sourceforge.net/p/bif-c/code/HEAD/tree/trunk/
>
> I finally took the time to look at your code, and discovered a key
> problem. You need to be very clear what your target language is, and
> them make sure your code is consistent with that choice. Here's why
> that's a problem:
>
> definition_header_s is a typedef for a struct type containing a flexible
> array member named parameterLink. Unless you change that, your code has
> no chance of being compatible with C++, or even with C90. However, it's
> much worse than that. You've defined objects of that types with static
> storage duration, with initializers for those objects that include
> values to be placed in parameterLink.
>
> Standard C doesn't allow that. For struct types containing flexible
> array members, "... the size of the structure is as if the flexible
> array member were omitted except that it may have more trailing padding
> than the omission would imply." 6.7.2.1p18. Therefore, when an object of
> such a type is allocated with static, thread, or automatic storage
> duration, there is no space specially set aside for the elements of the
> flexible array. If the struct has a lot of padding at the end, there
> might incidentally be enough space for a few elements of the flexible
> array. For example, if double has both a size of 8 and an alignment
> requirement of 8, then the following struct type must have an alignment
> requirement of at least 8:
>
> struct {
> double d;
> char c;
> char string[];
> } dstring;
>
> which implies that dstring must be big enough to store at least 7
> elements in dstring.string. However, in general, you cannot count on
> there being any space for any elements in the flexible array. Providing
> initializers for those non-existent elements is therefore a constraint
> violation.
>
> All of the examples in the standard involving flexible array members
> create the structs with allocated storage duration, in which case it's
> possible to ensure that there's enough space for the desired number of
> elements in the flexible array. It should be possible to reserve enough
> space for a non-zero number of flexible array members by putting the
> struct type in a union with a bigger object, but the standard contains
> no examples of how to do that. The required syntax is functionally
> equivalent to defining a fixed-length array rather than a flexible one,
> while being more complicated than that approach, so I wouldn't recommend
> trying that.
>
> Since your code does compile for you, and for me when I use gcc with the
> options you specify, it must be relying upon an extension to C which
> allows you to provide initializers for the flexible array, and makes
> sure that enough space is allocated to store all of those initializers.
> This is an entirely reasonable extension, and I would have no objection
> to changing standard C to support it - but as it stands, it is an
> extension - your code has undefined behavior as far as standard C is
> concerned.
>
> The thing to keep in mind is that most C compilers do NOT fully conform
> to any particular version of the C standard unless you explicitly tell
> them too. Unless you select a -std= option for gcc, it implements GnuC,
> not standard C. GnuC is a language distinct from, but very similar to,
> standard C. It has many conforming extensions to C, but it also supports
> many non-conforming extensions as well.
>
> GnuC is one of the most widely used and most widely available C-like
> alternatives to standard C. If you are willing to restrict the
> portability of your code to GnuC, I can't really fault that decision -
> it's a fairly popular one. But you need to be aware that this is what
> you are doing. You should be making this decision explicitly, not as an
> accident due to being unfamiliar with the differences between GnuC and
> standard C. Most importantly, your documentation for your program should
> explicitly state that you're relying upon GnuC.
>
> Note that flexible array members are not supported by C++; this is a
> legitimate example of a divergence between the two languages. However,
> it is not a counter-example to my claim - there are alternatives to
> using flexible array members that provide similar functionality, and
> they can be implemented in a way that has the exact same defined
> behavior in C and C++. However, those alternatives are not as flexible,
> simple, or as elegant as the code you're currently using that relies
> upon an extension to C. Using those alternatives would NOT count as
> making your code better - flexible array members were invented precisely
> because they are a better approach than those alternatives. Explaining
> those alternatives is complicated, and I can't spare the time right now
> to go into details. However, if you're really interested, I may be able
> to find time later.
>
> Removing your code's reliance on this extension would be complicated,
> which is one reason I don't think you're likely to make that choice.
> However, if you do want to change your code to use standard C rather
> than GnuC, you have a couple of options:
>
> 1. Target C99, which allows you to continue using flexible array
> members, but requires that you allocate the memory for them using
> malloc(), calloc(), or realloc().
>
> 2. Target C90, and make use of the struct hack. De jure, the struct hack
> has undefined behavior in all versions of both C and C++, so it isn't in
> the common subset. However, de facto, the struct hack is so popular that
> most implementations of C and C++ can be trusted to allow it to work.
> Therefore, de facto, you would still be in the common subset of those
> languages. You still need to allocate the required memory using
> malloc(), calloc(), or realloc().
I hope you don't mind, James, but I'll follow this up in the thread, 'conversion of code to common subset of C and C++ in my bif-c project (from "if statement with initializer")'.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-24 16:23 -0700 |
| Message-ID | <lnk255x2jc.fsf@kst-u.example.com> |
| In reply to | #110593 |
joel.rees@gmail.com writes:
> On Thursday, May 25, 2017 at 4:01:25 AM UTC+9, James R. Kuyper wrote:
[108 lines deleted]
>
> I hope you don't mind, James, but I'll follow this up in the thread,
> 'conversion of code to common subset of C and C++ in my bif-c project
> (from "if statement with initializer")'.
Joel, if you post a followup to a long article, please don't quote the
whole thing; trim anything that you're not replying to. Depending on
what newsreader someone is using, they might have to scroll down past
the entire quoted content to get to the new text.
Also, please format your lines to less than about 80 columns (70-72 is
probably ideal). My newsreader, for example, will split long lines, but
not at word boundaries.
Thanks.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-05-21 18:01 +0000 |
| Message-ID | <5921d5c0.2947812@news.xs4all.nl> |
| In reply to | #110364 |
David Brown <david.brown@hesbynett.no> wrote: > On 19/05/17 10:17, joel.rees@gmail.com wrote: > > 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 is easy - and so is using goto with abandon. Neither is good practice. If you want to write C, write C. If you want to write C++, write C++. Don't write hobbled C++ and convince yourself that you're writing nice, sleek C. Richard
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-22 10:04 +0200 |
| Message-ID | <ofu5sh$una$1@dont-email.me> |
| In reply to | #110468 |
On 21/05/17 20:01, Richard Bos wrote: > David Brown <david.brown@hesbynett.no> wrote: > >> On 19/05/17 10:17, joel.rees@gmail.com wrote: > >>> 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 is easy - and so is using goto with abandon. Neither is good > practice. > Code that can be compiled as either C or C++ can be a requirement for a project - and writing it that way is therefore not merely /good/, but essential. Yes, I have worked on several projects where all or significant parts of the code must work as C and as C++. In the world of embedded programming, it is not an uncommon requirement. This is in the real world, where programmers get paid to write code that customers ask for, rather than being free to create works of beauty like a painter with a field of sunflowers, and to reject casts of malloc() like an ugly weed. On the other hand, I have never been given a specification that asked for code that "uses goto with abandon". > If you want to write C, write C. If you want to write C++, write C++. In general, yes - that is the most common requirement. But as a professional programmer, you may also be asked to write code in the common subset of C and C++ - just as you may be asked to write code in C90 rather than C11, or C++03 rather than C++14, even though you know you could write clearer or more elegant code in later versions of these languages. Fortunately, writing code that is in a common subset of, for example, C99 and C++98, is easy. The result will not differ much from what you would write in pure C99. You are usually using exactly the same development tools for the job - the same compiler (but slightly different flags), the same editor/IDE, etc. I certainly greatly prefer restricting my C programming to the C++ compatible subset than restricting it to the C90 subset. > Don't write hobbled C++ and convince yourself that you're writing nice, > sleek C. > This is not programming in a hobbled or restricted C++ - it is programming in a marginally restricted C. The common subset is perhaps 90% of C, but it is a mere 20% of C++03 and 10% of C++11. Code written in the common subset is just plain C with a few minor restrictions, but it is very far from how you would solve the same problem writing it in C++. > Richard >
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-24 08:10 -0700 |
| Message-ID | <kfnr2zei93w.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #110364 |
David Brown <david.brown@hesbynett.no> writes: > [...] > > 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. [...] Herein lies the crux the matter: you admit you don't understand the other point of view, yet you insist with absolute certainty that the other point of view is wrong. There's no reason to read any further.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-24 17:54 +0200 |
| Message-ID | <og4a5l$cap$1@dont-email.me> |
| In reply to | #110544 |
On 24/05/17 17:10, Tim Rentsch wrote: > David Brown <david.brown@hesbynett.no> writes: > >> [...] >> >> 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. [...] > > Herein lies the crux the matter: you admit you don't understand > the other point of view, yet you insist with absolute certainty > that the other point of view is wrong. There's no reason to read > any further. > Yes, I am convinced the "other point of view" is wrong in this case. I have asked multiple times for examples, and explanations, and every time so far it has been a matter of misunderstandings, or the poster (Joel Rees in this case) has simply failed to give /any/ examples to show his point. If someone were to post some reasons why they think it is /hard/ to write C in a C++ compatible manner, they may convince me. If someone will post examples or reasons why they think C has suffered because of keeping compatibility with C++, they may convince me of that too. If someone will post examples of the supposed semantic differences between code that is correct C and correct C++, and not just artificial pathological cases, then again I may be convinced. (Note that I am perfectly happy to accept that if compatibility with C++ is not an issue, then you can write "better" C - such as by not casting the results of malloc(). I don't believe it is common that the non-C++-compatible C code will be /significantly/ "better" than compatible C code would be, but certainly /somewhat/ better.) I wrote that I cannot comprehend the other viewpoint here, because I cannot comprehend it. If /you/ think it is /hard/ to write C in a C++ compatible manner, then please enlighten me as to why.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-05-19 12:39 -0400 |
| Message-ID | <4e20e3e3-bb97-ac82-199d-c57bfe601ce3@verizon.net> |
| In reply to | #110363 |
On 05/19/2017 04:17 AM, joel.rees@gmail.com wrote: > On Friday, May 19, 2017 at 1:55:15 AM UTC+9, James R. Kuyper wrote: ... >> 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. My statement was MUCH stronger than your re-statement. It's not just that there's some small amount of usable code that can be written in the mutual subset. Almost anything that can be written in C can be written in the mutual subset. Furthermore, the modifications that would be needed will generally be quite minor. > 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. I'm curious - what features does your C code possess that makes you think it would be difficult to modify it to compile under C++ with the same behavior?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-24 07:55 -0700 |
| Message-ID | <kfnvaoqi9s3.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #110314 |
"James R. Kuyper" <jameskuyper@verizon.net> writes:
> 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++.
An interesting phrase - "merely convenience features". Let's
look at some of the language features in C for which there
exists less convenient ways to write the same thing:
for(), while(), switch(), and do/while() statements
'else' clauses
initializers on local variables
printf(), fprintf(), etc, functions
variadic functions
function prototypes
&&, ||, ?: operators (and some others I'm sure)
typedef's
mixed declarations and statements
compound statements
The whole point of language constructs is to make programs and
programming more convenient: easier to write, easier to read,
easier to understand, easier to get right, and easier to maintain
and extend. Saying there exist less convenient ways to write
the same thing is saying virtually nothing.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2017-05-17 21:14 +0000 |
| Message-ID | <slrn3vfsohpfg2.5f3.ike@iceland.freeshell.org> |
| In reply to | #110084 |
On 2017-05-15, Richard Heathfield <rjh@cpax.org.uk> wrote: > 5. Use the comma, as God intended. Some gods use the comma [for the thousands separator], others use the space, the period, or even the upper comma (single quote) for that purpose. So many gods, so many tastes.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-05-21 17:34 +0000 |
| Message-ID | <5921cf11.1236687@news.xs4all.nl> |
| In reply to | #110084 |
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). Personally, I think that the fact that it makes it look like an identifier _is_ a strike against this option. I don't like it. > > 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++. Ugly is in the eye of the beholder - I prefer this option. Purely on aesthetic grounds. > > 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++. Ew, no. > 5. Use the comma, as God intended. God is English? New to me. > 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: Significant whitespace is a tool of the devil. Sorry, of Python. Nope, I was right the first time 'round. Significant whitespace must be kept to a minimum. This, therefore, is not a reasonable option. Richard
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2017-05-21 19:40 +0100 |
| Message-ID | <ofsmp8$u8f$1@dont-email.me> |
| In reply to | #110467 |
On 21/05/17 18:34, Richard Bos wrote: > 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). > > Personally, I think that the fact that it makes it look like an > identifier _is_ a strike against this option. I don't like it. > >>> 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++. > > Ugly is in the eye of the beholder - I prefer this option. Purely on > aesthetic grounds. > >>> 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++. > > Ew, no. None of those were my idea. I just quoted them. >> 5. Use the comma, as God intended. > > God is English? New to me. Yeah. He lives in Gloucestershire, and has done since at least the Middle Ages. (A search for <proverb God Gloucestershire> may prove enlightening.) >> 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: > > Significant whitespace is a tool of the devil. Sorry, of Python. Nope, I > was right the first time 'round. Significant whitespace must be kept to > a minimum. This, therefore, is not a reasonable option. Well, I didn't claim that it's a /reasonable/ proposition. It would get my vote, though; and I should perhaps warn you that, if we have a referendum on the issue, I'm currently on a roll. -- 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-22 10:13 +0200 |
| Message-ID | <ofu6d7$sr$1@dont-email.me> |
| In reply to | #110471 |
On 21/05/17 20:40, Richard Heathfield wrote: > On 21/05/17 18:34, Richard Bos wrote: >> 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). >> >> Personally, I think that the fact that it makes it look like an >> identifier _is_ a strike against this option. I don't like it. >> >>>> 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++. >> >> Ugly is in the eye of the beholder - I prefer this option. Purely on >> aesthetic grounds. >> >>>> 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++. >> >> Ew, no. > > None of those were my idea. I just quoted them. > >>> 5. Use the comma, as God intended. >> >> God is English? New to me. > > Yeah. He lives in Gloucestershire, and has done since at least the > Middle Ages. (A search for <proverb God Gloucestershire> may prove > enlightening.) > Well, Jesus is Scottish - from the Gallowgate in Glasgow, to be more specific.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-05-15 22:16 +0100 |
| Message-ID | <8737c5253b.fsf@gmail.com> |
| In reply to | #110082 |
David Brown <david.brown@hesbynett.no> writes:
> In my opinion, consistency with C++ is important - when the two
> languages share a common feature that can easily be made the same, it
> is an advantage to programmers if they match.
I agree with this. I'd rather the ' and _ were reversed from their
meaning in C++, but that ship has sailed.
Of course
int main()
{
int x;
x= 1,234,000;
}
already compiles in both languages :)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-17 11:44 -0700 |
| Message-ID | <kfnmvabl3vh.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #110085 |
Gareth Owen <gwowen@gmail.com> writes:
> David Brown <david.brown@hesbynett.no> writes:
>
>> In my opinion, consistency with C++ is important - when the two
>> languages share a common feature that can easily be made the same, it
>> is an advantage to programmers if they match.
>
> I agree with this. I'd rather the ' and _ were reversed from their
> meaning in C++, but that ship has sailed.
The C++ ship has sailed. There is no reason the C ship should
try to sail along behind it. On the contrary, C should chart
its own course, and deliberately choose a different path here.
The problem with trying to maintain consistency with C++ is
it's a one-way street. There is no reciprocity. C++ has gone
through four (yes four!) revisions since C99, but still doesn't
have designated initializers or compound literals. The C++
community wants C to be consistent, but make no effort in the
other direction. Okay, so the people responsible for C++ chose
to shoot themselves in the foot by making underscore unavailable
for numeric literals. Fine, it's their language, that's up to
them. But now they want the C community to shoot themselves in
the foot to maintain consistency? Thanks but no thanks. It's
time to stop pretending that C is downward compatible with C++,
even just mostly. It's time for C to get out of its abusive
relationship with C++. If the C++ folks want compatibility,
let them figure out how to do it on the C++ side. It isn't
like this is a hard problem. For example, the most common
motivation is so C++ can include C header files. This could
be done by introducing a different form of include directive:
#C_include "some_c_header.h"
which would use C rules for interpreting the constructs in the
included header. Note the advantages: no need to go through
the 'extern "C"' song and dance (it would be implied by the new
include directive); the header can use, eg, compound literals,
or other C-only language features, without needing to affect
what is allowed in C++; and in cases where the semantics of
the two languages differ (there seems to be more and more of
these as time goes on), the C header can be written without
worry if the C++ standard (or some future C++ standard!) will
subtly change the meaning of code meant to be taken as C.
It's time to cut the cord. C++ is a separate language, and
should be treated as such by the C community and the ISO C
standards groups.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-17 23:30 +0200 |
| Message-ID | <ofif7j$541$1@dont-email.me> |
| In reply to | #110228 |
On 17/05/17 20:44, Tim Rentsch wrote: > Gareth Owen <gwowen@gmail.com> writes: > >> David Brown <david.brown@hesbynett.no> writes: >> >>> In my opinion, consistency with C++ is important - when the two >>> languages share a common feature that can easily be made the same, it >>> is an advantage to programmers if they match. >> >> I agree with this. I'd rather the ' and _ were reversed from their >> meaning in C++, but that ship has sailed. > > The C++ ship has sailed. There is no reason the C ship should > try to sail along behind it. On the contrary, C should chart > its own course, and deliberately choose a different path here. > > The problem with trying to maintain consistency with C++ is > it's a one-way street. There is no reciprocity. C++ has gone > through four (yes four!) revisions since C99, but still doesn't > have designated initializers or compound literals. I would be very happy to see designated initialisers and compound literals in C++. But petty playground "you hit me first" squabbling is hardly helpful to programmers who deal with both C and C++ code. > The C++ > community wants C to be consistent, but make no effort in the > other direction. It's odd how similar C11 and C++11 atomics and threading support are, if no effort was made to work together. > Okay, so the people responsible for C++ chose > to shoot themselves in the foot by making underscore unavailable > for numeric literals. Fine, it's their language, that's up to > them. I do believe you are exaggerating the issue. 1'000'000 is not really difficult to read or write. Yes, it can be an issue in parsing - but the philosophy of changes to C has always been that the effort involved in implementing a feature is very much lower concern than the benefit to /users/ of the language (and that is of lower concern than backwards compatibility with existing code). > But now they want the C community to shoot themselves in > the foot to maintain consistency? Who is "they" here? The "people responsible for C++"? I don't see them asking the C standards committee to do anything here - I see people who /use/ C and C++ looking for a digit separator to use in C just like they can in C++. > Thanks but no thanks. It's > time to stop pretending that C is downward compatible with C++, > even just mostly. Almost all C /is/ compatible with C++. There are a few features in C that do not exist in C++, and there are a few cases where you need to make minor changes to make C code valid as C++ - sometimes those lead to non-idiomatic C code. But C comes pretty close to being a subset of C++ - close enough that it is perfectly reasonable to program in their common subset. In particular, header files in the common subset are popular and rarely lead to sub-optimal C code. > It's time for C to get out of its abusive > relationship with C++. If the C++ folks want compatibility, > let them figure out how to do it on the C++ side. It isn't > like this is a hard problem. For example, the most common > motivation is so C++ can include C header files. This could > be done by introducing a different form of include directive: > > #C_include "some_c_header.h" > > which would use C rules for interpreting the constructs in the > included header. Note the advantages: no need to go through > the 'extern "C"' song and dance (it would be implied by the new > include directive); That would be convenient. > the header can use, eg, compound literals, It would make far more sense for C++ simply to support compound literals and designated initialisers. > or other C-only language features, without needing to affect > what is allowed in C++; and in cases where the semantics of > the two languages differ (there seems to be more and more of > these as time goes on), the C header can be written without > worry if the C++ standard (or some future C++ standard!) will > subtly change the meaning of code meant to be taken as C. > > It's time to cut the cord. C++ is a separate language, and > should be treated as such by the C community and the ISO C > standards groups. > That may be of interest to /you/, but a good many people work with both languages. Consistency between them is important. I fully support the idea that the C++ committee could do a better job of supporting extra features from C, and making more of an effort for better consistency. But I disagree with the idea that C, as a standard or as a community, should take their ball home in a huff.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-05-18 18:30 +1200 |
| Message-ID | <eo4tbmFhtkdU4@mid.individual.net> |
| In reply to | #110237 |
On 05/18/17 09:30 AM, David Brown wrote: > On 17/05/17 20:44, Tim Rentsch wrote: >> Gareth Owen <gwowen@gmail.com> writes: >> >>> David Brown <david.brown@hesbynett.no> writes: >>> >>>> In my opinion, consistency with C++ is important - when the two >>>> languages share a common feature that can easily be made the same, it >>>> is an advantage to programmers if they match. >>> >>> I agree with this. I'd rather the ' and _ were reversed from their >>> meaning in C++, but that ship has sailed. >> >> The C++ ship has sailed. There is no reason the C ship should >> try to sail along behind it. On the contrary, C should chart >> its own course, and deliberately choose a different path here. >> >> The problem with trying to maintain consistency with C++ is >> it's a one-way street. There is no reciprocity. C++ has gone >> through four (yes four!) revisions since C99, but still doesn't >> have designated initializers or compound literals. > > I would be very happy to see designated initialisers and compound > literals in C++. But petty playground "you hit me first" squabbling is > hardly helpful to programmers who deal with both C and C++ code. Certainly designated initialisers are a serious omission in C++. Maybe C and C++ should trade proper constants and designated initialisers... >> The C++ >> community wants C to be consistent, but make no effort in the >> other direction. > > It's odd how similar C11 and C++11 atomics and threading support are, if > no effort was made to work together. By all accounts, it was a big effort. >> Okay, so the people responsible for C++ chose >> to shoot themselves in the foot by making underscore unavailable >> for numeric literals. Fine, it's their language, that's up to >> them. > > I do believe you are exaggerating the issue. 1'000'000 is not really > difficult to read or write. Yes, it can be an issue in parsing - but > the philosophy of changes to C has always been that the effort involved > in implementing a feature is very much lower concern than the benefit to > /users/ of the language (and that is of lower concern than backwards > compatibility with existing code). I have been using the likes of 1'000'000 on c++ code for a while, people soon get used to it. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | joel.rees@gmail.com |
|---|---|
| Date | 2017-05-18 06:04 -0700 |
| Message-ID | <0b78fc39-1e23-494c-b5d9-9677d5d79489@googlegroups.com> |
| In reply to | #110237 |
On Thursday, May 18, 2017 at 6:30:44 AM UTC+9, David Brown wrote: > [...] > Almost all C /is/ compatible with C++. > [...] Somehow, I have had the impression, from the things you have said, that you were not really a C programmer, but a C++ programmer. Now I know why. -- Joel Rees Delusions of being a novelist: http://reiisi.blogspot.com
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-05-18 17:29 +0200 |
| Message-ID | <ofkee2$242$1@dont-email.me> |
| In reply to | #110271 |
On 18/05/17 15:04, joel.rees@gmail.com wrote: > On Thursday, May 18, 2017 at 6:30:44 AM UTC+9, David Brown wrote: >> [...] >> Almost all C /is/ compatible with C++. >> [...] > > Somehow, I have had the impression, from the things you have said, > that you were not really a C programmer, but a C++ programmer. > > Now I know why. > /I/ don't know why you get that impression, because it is wrong. Indeed, it is perhaps because I program mainly in C and only a little C++ that I am concerned about consistency between the languages. If I were a pure C++ programmer, I would just laugh at the poor old-fashioned programmers who have no digit separators because they can't agree on which language to copy it from, and walk away.
[toc] | [prev] | [next] | [standalone]
Page 13 of 19 — ← Prev page 1 … 11 12 [13] 14 15 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web