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 5 of 19 — ← Prev page 1 … 3 4 [5] 6 7 … 19 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-15 06:55 -0700 |
| Message-ID | <kfny3tyns1v.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #110004 |
GOTHIER Nathan <nathan.gothier@gmail.com> writes: > On Sun, 14 May 2017 19:14:34 -0700 > Tim Rentsch <txr@alumni.caltech.edu> wrote: > >> So what you want is something along the lines of structs >> with (private) data and functions that operate on the >> data of the instance on which the function is invoked >> (plus any other arguments, of course)? Is that all >> or is there something more? Constructors? Destructors? >> Copy assignment? Move assignment? References? I'm >> trying to understand where you mean to draw the line. > > There is no need for class to manipulate private data and > functions when you can easily use source inclusion with an upto 31 > characters namespace for identifiers. Obviously some other people feel otherwise. I would like to understand more precisely what it is they do want before deciding what might be needed to accommodate that.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-15 10:33 -0700 |
| Message-ID | <kfny3tym3cp.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #109993 |
(For some strange reason my news reader lost Robert Wessel's
orginal reply, so I am following up to my own message, using a
copy of his posting taken from Patrick Schluter's followup.)
Robert Wessel <robertwessel2@yahoo.com> writes:
> On Sun, 14 May 2017 19:14:34 -0700, Tim Rentsch
> <txr@alumni.caltech.edu> wrote:
>
>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>
>>> On Sat, 13 May 2017 08:54:12 -0700, Tim Rentsch
>>> <txr@alumni.caltech.edu> wrote:
>>>
>>>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>>>
>>>>> On Thu, 11 May 2017 19:00:06 +0100, bartc <bc@freeuk.com> wrote:
>>>>>> [...]
>>>>>>
>>>>>> I think there are already enough possibilities for scope inside
>>>>>> functions (so an infinite number of versions of the same identifier can
>>>>>> be used, and if that's not enough, you can use upper/lower case
>>>>>> {} variations).
>>>>>>
>>>>>> Outside a function, there are fewer possibilities: namely one for each
>>>>>> identifier. Despite the span of code being far bigger (an entire module
>>>>>> for local names, the entire program for global ones).
>>>>>
>>>>> C++ classes provide an excellent intermediate scope for items. If
>>>>> there were a major feature of C++ I'd want in C, it would be classes
>>>>> (not inherence, overloading, templates...).
>>>>
>>>> I'm curious to know what sort of items you envision putting in
>>>> those classes. For all the examples I have thought of it seems
>>>> of little practical value or there is a straightforward way of
>>>> accomplishing the same goal without needing any extensions. What
>>>> are your use cases?
>>>
>>> A major issue for large projects is namespace pollution. The ability
>>> to bury most bits of a particular subsystem inside a class greatly
>>> reduces that problem (leaving only the name of the class globally
>>> visible). The ability to make items private further enhances
>>> encapsulation.
>>>
>>> Obviously you can put data items inside a struct in C, but not (in any
>>> "good" way), functions (methods) intended to work on them. [...]
>>
>> So what you want is something along the lines of structs
>> with (private) data and functions that operate on the
>> data of the instance on which the function is invoked
>> (plus any other arguments, of course)? Is that all
>> or is there something more? Constructors? Destructors?
>> Copy assignment? Move assignment? References? I'm
>> trying to understand where you mean to draw the line.
>>
>> (I assume throw/catch is meant to be on your list of 'not's
>> along with inheritance, etc.)
>
> Ah. OK, I'll take ctors and dtors. And those imply something like
> new and delete.
Let me pause here for a moment and start with these.
If what you want is struct-objects that are always referred to by
pointer, this can be done in C as it (mostly) is today. All that's
missing is a little bit of syntactic sugar so method calls can be
written 'foo->method()' instead of, eg, 'Whatsit_method( foo )'.
We don't really need any new semantics, as the mapping between the
two is straightforward. Note that this includes ctors and dtors,
since always using pointers implies that dtors must be invoked
explicitly.
Things change drastically once we want to be able to instance
struct-objects either at file scope or as local variables. Now
ctors, and more significantly dtors, must be invoked invisibly as
part of scoping and lifetime rules. The well-known C++ expert
Scott Myers has said he considers destructors to be the most
important feature of C++ (this is from memory so I may not have
the words exactly right, but they should be close). Local
objects and implied destructor calls are a big step outside of
what C is as it is now. I mean that not only in the sense that
the language would change but also that the flavor of programs
would substantially change. For example, suppose you saw this in
a C program:
int main(){
return 0;
}
In C this program does nothing. In C-with-file-scope-ctors this
program might do almost anything. And if people can do it, they
will. Is this really what we want? Consider the question
carefully, because once it happens there will be no going back.
Let me be clear that I don't mean to argue against adding some
limited form of classes to C (or perhaps a relative of C that is
closer to C than C++ is). I understand your motivation, and at
least partly agree with it - encapsulation is a good thing, and C
is somewhat impoverished in that area. At the same time, it is
very important to exercise caution (even extreme caution) when
considering new language constructs, because seemingly minor
changes can have surprising effects on the character of the
language and its usage.
> Some of the others are nice-to-have, but not critical, [...]
>
> That doubtless reflects some of my development practices, where I
> tend to focus heavily on decomposing systems into (fairly opaque)
> components with good interfaces.
>
> A limited form of classes would help program structure by making
> encapsulation much easier, as well as eliminating the vast
> majority of namespace pollution.
Certainly I agree with what I think is the spirit of your
comments. I too am a huge fan of encapsulation. My concern is
about how to accomplish that without changing the essential
character of C, which IMO is important to preserve.
> Other people have come to different conclusions. Jacob Navia,
> for example, thought so highly of operator overloading he wrote
> his own compiler to support it. Personally I think operator
> overloading has its niche, but it's a small one.
Function overloading or operator overloading definitely can be
useful, within certain contexts. I think the important
difference is that I want encapsulation in almost every program I
work on, but want overloading in only some of them. I should
add though that my perspective is different from Jacob's, since
he has a compiler to support for an implementation that has
extended width numeric types.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-15 10:54 -0700 |
| Message-ID | <0ab935a9-7068-4bff-8dab-d4a7aa057ab6@googlegroups.com> |
| In reply to | #110055 |
On Monday, May 15, 2017 at 12:34:07 PM UTC-5, Tim Rentsch wrote: > Function overloading or operator overloading definitely can be > useful, within certain contexts. I think the important > difference is that I want encapsulation in almost every program I > work on, but want overloading in only some of them. I should > add though that my perspective is different from Jacob's, since > he has a compiler to support for an implementation that has > extended width numeric types. The primary argument I've read against overloading is that it requires name mangling that would complicate interactions between code compiled in different languages. Such problems wouldn't arise if overloading were limited to functions with static scope, but allowing overloading of such functions would make it possible to have static functions that share a name chain to exported functions that don't.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-15 12:00 -0700 |
| Message-ID | <lnfug63pye.fsf@kst-u.example.com> |
| In reply to | #110055 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> If what you want is struct-objects that are always referred to by
> pointer, this can be done in C as it (mostly) is today. All that's
> missing is a little bit of syntactic sugar so method calls can be
> written 'foo->method()' instead of, eg, 'Whatsit_method( foo )'.
> We don't really need any new semantics, as the mapping between the
> two is straightforward. Note that this includes ctors and dtors,
> since always using pointers implies that dtors must be invoked
> explicitly.
And we can do `foo->method(foo)` in C. It just requires `method` to
be a member of pointer-to-function type, and some way to ensure that
the struct object that foo points to has been properly initialized.
(`foo->method()` doesn't work because there's no implicit `this`
as there is in C++.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-16 05:11 -0700 |
| Message-ID | <kfn4lwlm27c.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #110069 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
> [...]
>> If what you want is struct-objects that are always referred to by
>> pointer, this can be done in C as it (mostly) is today. All that's
>> missing is a little bit of syntactic sugar so method calls can be
>> written 'foo->method()' instead of, eg, 'Whatsit_method( foo )'.
>> We don't really need any new semantics, as the mapping between the
>> two is straightforward. Note that this includes ctors and dtors,
>> since always using pointers implies that dtors must be invoked
>> explicitly.
>
> And we can do `foo->method(foo)` in C. It just requires `method` to
> be a member of pointer-to-function type, and some way to ensure that
> the struct object that foo points to has been properly initialized.
> (`foo->method()` doesn't work because there's no implicit `this`
> as there is in C++.)
Yes, it could be done that way, but probably wouldn't be, because
the space costs are too high: a pointer-to-function would be
needed in every object for every method. Adding one level of
indirection allows only one pointer for each struct, plus a
single instance of a struct with method function pointers, eg,
foo->m->method( foo )
Even though this way is better than the previous one, neither is
really acceptable for large-scale deployment. The reason is
having to duplicate the object being sent to (ie, in the sense of
having to name it twice, eg, the token 'foo' in this case).
In terms of usability having the syntactic sugar for method
calls is pretty much an essential component here.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-05-17 08:24 +1200 |
| Message-ID | <eo15gaFrasmU7@mid.individual.net> |
| In reply to | #110135 |
On 05/17/17 12:11 AM, Tim Rentsch wrote: > Keith Thompson <kst-u@mib.org> writes: > >> Tim Rentsch <txr@alumni.caltech.edu> writes: >> [...] >>> If what you want is struct-objects that are always referred to by >>> pointer, this can be done in C as it (mostly) is today. All that's >>> missing is a little bit of syntactic sugar so method calls can be >>> written 'foo->method()' instead of, eg, 'Whatsit_method( foo )'. >>> We don't really need any new semantics, as the mapping between the >>> two is straightforward. Note that this includes ctors and dtors, >>> since always using pointers implies that dtors must be invoked >>> explicitly. >> >> And we can do `foo->method(foo)` in C. It just requires `method` to >> be a member of pointer-to-function type, and some way to ensure that >> the struct object that foo points to has been properly initialized. >> (`foo->method()` doesn't work because there's no implicit `this` >> as there is in C++.) > > Yes, it could be done that way, but probably wouldn't be, because > the space costs are too high: a pointer-to-function would be > needed in every object for every method. Adding one level of > indirection allows only one pointer for each struct, plus a > single instance of a struct with method function pointers, eg, > > foo->m->method( foo ) > > Even though this way is better than the previous one, neither is > really acceptable for large-scale deployment. The reason is > having to duplicate the object being sent to (ie, in the sense of > having to name it twice, eg, the token 'foo' in this case). > In terms of usability having the syntactic sugar for method > calls is pretty much an essential component here. The technique described by Keith is widely used in kernels, particularity in module and driver interfaces. The space overhead is a cost worth bearing when you want a modular interface and there aren't too many objects. It was also use in the (for its day) excellent XView window system on Sun workstations. That was where I got infected by the OO bug! -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-19 18:43 -0700 |
| Message-ID | <kfntw4gjo9v.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #110177 |
Ian Collins <ian-news@hotmail.com> writes: > On 05/17/17 12:11 AM, Tim Rentsch wrote: >> Keith Thompson <kst-u@mib.org> writes: >> >>> Tim Rentsch <txr@alumni.caltech.edu> writes: >>> [...] >>>> If what you want is struct-objects that are always referred to by >>>> pointer, this can be done in C as it (mostly) is today. All that's >>>> missing is a little bit of syntactic sugar so method calls can be >>>> written 'foo->method()' instead of, eg, 'Whatsit_method( foo )'. >>>> We don't really need any new semantics, as the mapping between the >>>> two is straightforward. Note that this includes ctors and dtors, >>>> since always using pointers implies that dtors must be invoked >>>> explicitly. >>> >>> And we can do `foo->method(foo)` in C. It just requires `method` to >>> be a member of pointer-to-function type, and some way to ensure that >>> the struct object that foo points to has been properly initialized. >>> (`foo->method()` doesn't work because there's no implicit `this` >>> as there is in C++.) >> >> Yes, it could be done that way, but probably wouldn't be, because >> the space costs are too high: a pointer-to-function would be >> needed in every object for every method. Adding one level of >> indirection allows only one pointer for each struct, plus a >> single instance of a struct with method function pointers, eg, >> >> foo->m->method( foo ) >> >> Even though this way is better than the previous one, neither is >> really acceptable for large-scale deployment. The reason is >> having to duplicate the object being sent to (ie, in the sense of >> having to name it twice, eg, the token 'foo' in this case). >> In terms of usability having the syntactic sugar for method >> calls is pretty much an essential component here. > > The technique described by Keith is widely used in kernels, > particularity in module and driver interfaces. The space overhead is > a cost worth bearing when you want a modular interface and there > aren't too many objects. [...] Yes, I didn't mean to imply it's unworkable in all contexts. If the number pointers is small, or the number of objects is small, or especially if both are small, then it's not too bad. But it doesn't scale to the general case of lots of pointers and lots of objects, which is (at least potentially) true in the case that was under discussion.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-05-20 22:06 +1200 |
| Message-ID | <eoaio9Fp50iU3@mid.individual.net> |
| In reply to | #110436 |
On 05/20/17 01:43 PM, Tim Rentsch wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> On 05/17/17 12:11 AM, Tim Rentsch wrote: >>> Keith Thompson <kst-u@mib.org> writes: >>> >>>> And we can do `foo->method(foo)` in C. It just requires `method` to >>>> be a member of pointer-to-function type, and some way to ensure that >>>> the struct object that foo points to has been properly initialized. >>>> (`foo->method()` doesn't work because there's no implicit `this` >>>> as there is in C++.) >>> >>> Yes, it could be done that way, but probably wouldn't be, because >>> the space costs are too high: a pointer-to-function would be >>> needed in every object for every method. Adding one level of >>> indirection allows only one pointer for each struct, plus a >>> single instance of a struct with method function pointers, eg, >>> >>> foo->m->method( foo ) >>> >>> Even though this way is better than the previous one, neither is >>> really acceptable for large-scale deployment. The reason is >>> having to duplicate the object being sent to (ie, in the sense of >>> having to name it twice, eg, the token 'foo' in this case). >>> In terms of usability having the syntactic sugar for method >>> calls is pretty much an essential component here. >> >> The technique described by Keith is widely used in kernels, >> particularity in module and driver interfaces. The space overhead is >> a cost worth bearing when you want a modular interface and there >> aren't too many objects. [...] > > Yes, I didn't mean to imply it's unworkable in all > contexts. If the number pointers is small, or the > number of objects is small, or especially if both > are small, then it's not too bad. But it doesn't > scale to the general case of lots of pointers and > lots of objects, which is (at least potentially) > true in the case that was under discussion. XView scaled pretty well :) -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-26 15:54 -0700 |
| Message-ID | <kfnfufrgreo.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #110447 |
Ian Collins <ian-news@hotmail.com> writes: > On 05/20/17 01:43 PM, Tim Rentsch wrote: >> Ian Collins <ian-news@hotmail.com> writes: >> >>> On 05/17/17 12:11 AM, Tim Rentsch wrote: >>>> Keith Thompson <kst-u@mib.org> writes: >>>> >>>>> And we can do `foo->method(foo)` in C. It just requires `method` to >>>>> be a member of pointer-to-function type, and some way to ensure that >>>>> the struct object that foo points to has been properly initialized. >>>>> (`foo->method()` doesn't work because there's no implicit `this` >>>>> as there is in C++.) >>>> >>>> Yes, it could be done that way, but probably wouldn't be, because >>>> the space costs are too high: a pointer-to-function would be >>>> needed in every object for every method. Adding one level of >>>> indirection allows only one pointer for each struct, plus a >>>> single instance of a struct with method function pointers, eg, >>>> >>>> foo->m->method( foo ) >>>> >>>> Even though this way is better than the previous one, neither is >>>> really acceptable for large-scale deployment. The reason is >>>> having to duplicate the object being sent to (ie, in the sense of >>>> having to name it twice, eg, the token 'foo' in this case). >>>> In terms of usability having the syntactic sugar for method >>>> calls is pretty much an essential component here. >>> >>> The technique described by Keith is widely used in kernels, >>> particularity in module and driver interfaces. The space overhead is >>> a cost worth bearing when you want a modular interface and there >>> aren't too many objects. [...] >> >> Yes, I didn't mean to imply it's unworkable in all >> contexts. If the number pointers is small, or the >> number of objects is small, or especially if both >> are small, then it's not too bad. But it doesn't >> scale to the general case of lots of pointers and >> lots of objects, which is (at least potentially) >> true in the case that was under discussion. > > XView scaled pretty well :) If you mean it kept working reasonably in all the particular systems you experienced, then at least one of the relevant dimensions must have been under-represented. The mathematics is not wrong.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-05-27 11:06 +1200 |
| Message-ID | <eorqnrFqj75U2@mid.individual.net> |
| In reply to | #110768 |
On 05/27/17 10:54 AM, Tim Rentsch wrote: > Ian Collins <ian-news@hotmail.com> writes: > >> On 05/20/17 01:43 PM, Tim Rentsch wrote: >>> Ian Collins <ian-news@hotmail.com> writes: >>> >>>> On 05/17/17 12:11 AM, Tim Rentsch wrote: >>>>> Keith Thompson <kst-u@mib.org> writes: >>>>> >>>>>> And we can do `foo->method(foo)` in C. It just requires `method` to >>>>>> be a member of pointer-to-function type, and some way to ensure that >>>>>> the struct object that foo points to has been properly initialized. >>>>>> (`foo->method()` doesn't work because there's no implicit `this` >>>>>> as there is in C++.) >>>>> >>>>> Yes, it could be done that way, but probably wouldn't be, because >>>>> the space costs are too high: a pointer-to-function would be >>>>> needed in every object for every method. Adding one level of >>>>> indirection allows only one pointer for each struct, plus a >>>>> single instance of a struct with method function pointers, eg, >>>>> >>>>> foo->m->method( foo ) >>>>> >>>>> Even though this way is better than the previous one, neither is >>>>> really acceptable for large-scale deployment. The reason is >>>>> having to duplicate the object being sent to (ie, in the sense of >>>>> having to name it twice, eg, the token 'foo' in this case). >>>>> In terms of usability having the syntactic sugar for method >>>>> calls is pretty much an essential component here. >>>> >>>> The technique described by Keith is widely used in kernels, >>>> particularity in module and driver interfaces. The space overhead is >>>> a cost worth bearing when you want a modular interface and there >>>> aren't too many objects. [...] >>> >>> Yes, I didn't mean to imply it's unworkable in all >>> contexts. If the number pointers is small, or the >>> number of objects is small, or especially if both >>> are small, then it's not too bad. But it doesn't >>> scale to the general case of lots of pointers and >>> lots of objects, which is (at least potentially) >>> true in the case that was under discussion. >> >> XView scaled pretty well :) > > If you mean it kept working reasonably in all the particular > systems you experienced, then at least one of the relevant > dimensions must have been under-represented. The mathematics is > not wrong. Well the data set was every SunOS desktop until Solaris moved to Motif in the mid 90s! Maybe we didn't have such cluttered desktops back then, but what we had was impressive for the hardware it ran on. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-15 19:15 -0500 |
| Message-ID | <k2gkhcpftck7rhqu38bi1uje3ontphrt8o@4ax.com> |
| In reply to | #110055 |
On Mon, 15 May 2017 10:33:58 -0700, Tim Rentsch
<txr@alumni.caltech.edu> wrote:
>(For some strange reason my news reader lost Robert Wessel's
>orginal reply, so I am following up to my own message, using a
>copy of his posting taken from Patrick Schluter's followup.)
>
>Robert Wessel <robertwessel2@yahoo.com> writes:
>
>> On Sun, 14 May 2017 19:14:34 -0700, Tim Rentsch
>> <txr@alumni.caltech.edu> wrote:
>>
>>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>>
>>>> On Sat, 13 May 2017 08:54:12 -0700, Tim Rentsch
>>>> <txr@alumni.caltech.edu> wrote:
>>>>
>>>>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>>>>
>>>>>> On Thu, 11 May 2017 19:00:06 +0100, bartc <bc@freeuk.com> wrote:
>>>>>>> [...]
>>>>>>>
>>>>>>> I think there are already enough possibilities for scope inside
>>>>>>> functions (so an infinite number of versions of the same identifier can
>>>>>>> be used, and if that's not enough, you can use upper/lower case
>>>>>>> {} variations).
>>>>>>>
>>>>>>> Outside a function, there are fewer possibilities: namely one for each
>>>>>>> identifier. Despite the span of code being far bigger (an entire module
>>>>>>> for local names, the entire program for global ones).
>>>>>>
>>>>>> C++ classes provide an excellent intermediate scope for items. If
>>>>>> there were a major feature of C++ I'd want in C, it would be classes
>>>>>> (not inherence, overloading, templates...).
>>>>>
>>>>> I'm curious to know what sort of items you envision putting in
>>>>> those classes. For all the examples I have thought of it seems
>>>>> of little practical value or there is a straightforward way of
>>>>> accomplishing the same goal without needing any extensions. What
>>>>> are your use cases?
>>>>
>>>> A major issue for large projects is namespace pollution. The ability
>>>> to bury most bits of a particular subsystem inside a class greatly
>>>> reduces that problem (leaving only the name of the class globally
>>>> visible). The ability to make items private further enhances
>>>> encapsulation.
>>>>
>>>> Obviously you can put data items inside a struct in C, but not (in any
>>>> "good" way), functions (methods) intended to work on them. [...]
>>>
>>> So what you want is something along the lines of structs
>>> with (private) data and functions that operate on the
>>> data of the instance on which the function is invoked
>>> (plus any other arguments, of course)? Is that all
>>> or is there something more? Constructors? Destructors?
>>> Copy assignment? Move assignment? References? I'm
>>> trying to understand where you mean to draw the line.
>>>
>>> (I assume throw/catch is meant to be on your list of 'not's
>>> along with inheritance, etc.)
>>
>> Ah. OK, I'll take ctors and dtors. And those imply something like
>> new and delete.
>
>Let me pause here for a moment and start with these.
>
>If what you want is struct-objects that are always referred to by
>pointer, this can be done in C as it (mostly) is today. All that's
>missing is a little bit of syntactic sugar so method calls can be
>written 'foo->method()' instead of, eg, 'Whatsit_method( foo )'.
>We don't really need any new semantics, as the mapping between the
>two is straightforward. Note that this includes ctors and dtors,
>since always using pointers implies that dtors must be invoked
>explicitly.
Yes, you can do that manually, but that bit of syntactic sugar (both
methods and implicit this), adds not only enforcement, but
considerable convenience, as well as avoiding a lot of opportunities
for errors in implementing the manual system.
>Things change drastically once we want to be able to instance
>struct-objects either at file scope or as local variables. Now
>ctors, and more significantly dtors, must be invoked invisibly as
>part of scoping and lifetime rules. The well-known C++ expert
>Scott Myers has said he considers destructors to be the most
>important feature of C++ (this is from memory so I may not have
>the words exactly right, but they should be close).
I'd rate both ctors and dtors quite highly.
>Local
>objects and implied destructor calls are a big step outside of
>what C is as it is now. I mean that not only in the sense that
>the language would change but also that the flavor of programs
>would substantially change. For example, suppose you saw this in
>a C program:
>
> int main(){
> return 0;
> }
>
>In C this program does nothing. In C-with-file-scope-ctors this
>program might do almost anything. And if people can do it, they
>will. Is this really what we want? Consider the question
>carefully, because once it happens there will be no going back.
ctors and dtors don't actually add anything unless you use them. I'm
not sure having them really changes the "essential character of C",
whatever exactly that may be, so that point doesn't really cause me
too much worry (of course I like this idea, so I may be biased). OTOH,
I think *exceptions* would significantly change the character of C.
In any event, consider the following buried in the middle of a program
somewhere:
atexit(ProcessDatabaseAndSendOneMillionSpamEmails);
How is that better than a dtor invoked on global scope object?
>Let me be clear that I don't mean to argue against adding some
>limited form of classes to C (or perhaps a relative of C that is
>closer to C than C++ is). I understand your motivation, and at
>least partly agree with it - encapsulation is a good thing, and C
>is somewhat impoverished in that area. At the same time, it is
>very important to exercise caution (even extreme caution) when
>considering new language constructs, because seemingly minor
>changes can have surprising effects on the character of the
>language and its usage.
I certainly approve of some caution, but not immobility.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-05-16 12:54 -0700 |
| Message-ID | <kfnzieclgqq.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #110109 |
Robert Wessel <robertwessel2@yahoo.com> writes:
> On Mon, 15 May 2017 10:33:58 -0700, Tim Rentsch
> <txr@alumni.caltech.edu> wrote:
>
>> (For some strange reason my news reader lost Robert Wessel's
>> orginal reply, so I am following up to my own message, using a
>> copy of his posting taken from Patrick Schluter's followup.)
>>
>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>
>>> On Sun, 14 May 2017 19:14:34 -0700, Tim Rentsch
>>> <txr@alumni.caltech.edu> wrote:
>>>
>>>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>>>
>>>>> On Sat, 13 May 2017 08:54:12 -0700, Tim Rentsch
>>>>> <txr@alumni.caltech.edu> wrote:
>>>>>
>>>>>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>>>>>
>>>>>>> On Thu, 11 May 2017 19:00:06 +0100, bartc <bc@freeuk.com> wrote:
>>>>>>>> [...]
>>>>>>>>
>>>>>>>> I think there are already enough possibilities for scope inside
>>>>>>>> functions (so an infinite number of versions of the same
>>>>>>>> identifier can be used, and if that's not enough, you can use
>>>>>>>> upper/lower case variations).
>>>>>>>>
>>>>>>>> Outside a function, there are fewer possibilities: namely one for
>>>>>>>> each identifier. Despite the span of code being far bigger (an
>>>>>>>> entire module for local names, the entire program for global
>>>>>>>> ones).
>>>>>>>
>>>>>>> C++ classes provide an excellent intermediate scope for items. If
>>>>>>> there were a major feature of C++ I'd want in C, it would be
>>>>>>> classes (not inherence, overloading, templates...).
>>>>>>
>>>>>> I'm curious to know what sort of items you envision putting in
>>>>>> those classes. For all the examples I have thought of it seems
>>>>>> of little practical value or there is a straightforward way of
>>>>>> accomplishing the same goal without needing any extensions. What
>>>>>> are your use cases?
>>>>>
>>>>> A major issue for large projects is namespace pollution. The ability
>>>>> to bury most bits of a particular subsystem inside a class greatly
>>>>> reduces that problem (leaving only the name of the class globally
>>>>> visible). The ability to make items private further enhances
>>>>> encapsulation.
>>>>>
>>>>> Obviously you can put data items inside a struct in C, but not (in
>>>>> any "good" way), functions (methods) intended to work on them. [...]
>>>>
>>>> So what you want is something along the lines of structs
>>>> with (private) data and functions that operate on the
>>>> data of the instance on which the function is invoked
>>>> (plus any other arguments, of course)? Is that all
>>>> or is there something more? Constructors? Destructors?
>>>> Copy assignment? Move assignment? References? I'm
>>>> trying to understand where you mean to draw the line.
>>>>
>>>> (I assume throw/catch is meant to be on your list of 'not's
>>>> along with inheritance, etc.)
>>>
>>> Ah. OK, I'll take ctors and dtors. And those imply something like
>>> new and delete.
>>
>> Let me pause here for a moment and start with these.
>>
>> If what you want is struct-objects that are always referred to by
>> pointer, this can be done in C as it (mostly) is today. All that's
>> missing is a little bit of syntactic sugar so method calls can be
>> written 'foo->method()' instead of, eg, 'Whatsit_method( foo )'.
>> We don't really need any new semantics, as the mapping between the
>> two is straightforward. Note that this includes ctors and dtors,
>> since always using pointers implies that dtors must be invoked
>> explicitly.
>
> Yes, you can do that manually, but that bit of syntactic sugar (both
> methods and implicit this), adds not only enforcement, but
> considerable convenience, as well as avoiding a lot of opportunities
> for errors in implementing the manual system.
I agree the syntactic sugar makes a big difference. Sorry
if that wasn't clear from what I said before.
>> Things change drastically once we want to be able to instance
>> struct-objects either at file scope or as local variables. Now
>> ctors, and more significantly dtors, must be invoked invisibly as
>> part of scoping and lifetime rules. The well-known C++ expert
>> Scott Myers has said he considers destructors to be the most
>> important feature of C++ (this is from memory so I may not have
>> the words exactly right, but they should be close).
>
> I'd rate both ctors and dtors quite highly.
Yes, I get that. What I was saying is not about whether they
are valuable or not, but about how large a change is implied
if they were to be included (ie, for struct-objects instanced
at file scope or block/temporary scope).
>> Local
>> objects and implied destructor calls are a big step outside of
>> what C is as it is now. I mean that not only in the sense that
>> the language would change but also that the flavor of programs
>> would substantially change. For example, suppose you saw this in
>> a C program:
>>
>> int main(){
>> return 0;
>> }
>>
>> In C this program does nothing. In C-with-file-scope-ctors this
>> program might do almost anything. And if people can do it, they
>> will. Is this really what we want? Consider the question
>> carefully, because once it happens there will be no going back.
>
> ctors and dtors don't actually add anything unless you use them.
What I think you mean is that they don't add anything unless the
program uses them. I'm not worried about code that I write; it's
the code written by other people (and that I want to understand)
that is of concern.
> I'm not sure having them really changes the "essential character
> of C", whatever exactly that may be, so that point doesn't really
> cause me too much worry (of course I like this idea, so I may be
> biased).
C has the wonderful property that everything is out in the open,
with nothing hidden away somewhere else in the program. Consider
code along the lines of this example:
while ( c = *p++ ) {
Foo x = { p-1, c };
if ( c == '\n' ) continue;
... rest of loop ...
}
In C there is no need to wonder if moving the declaration of 'x'
to just after the if() will change the program behavior. But if
ctors and dtors have been added that is no longer true. To
understand the behavior of this while() loop it is necessary to
look somewhere else besides just the code in the loop. What is
more important, that dependency is not obvious in the code itself
(unlike, eg, function calls). That difference would give the
language a very different feel.
> OTOH, I think *exceptions* would significantly change the
> character of C.
I'm not sure how large the difference would be, given that C
already has setjmp/longjmp (note: please don't take this as my
suggesting that exceptions be added to C). But assuming for the
moment that having exceptions would change the character of the
language, I think the change is still less than that of ctors and
dtors, for two reasons. One, exceptions can happen only at
function calls, which makes them easier to track down than dtors,
which can pop up in unexpected places. Two, if an exception is
thrown in some function call, /we know what's going to happen/ -
no more processing takes place after the call, and the throw
keeps going through stack frames looking for a handler. In
contrast, if a ctor or a dtor gets called, anything might happen.
> In any event, consider the following buried in the middle of a program
> somewhere:
>
> atexit(ProcessDatabaseAndSendOneMillionSpamEmails);
>
> How is that better than a dtor invoked on global scope object?
It's better in that the call is explicit in the statements
executed rather than implicit in a simple declaration, and its
semantics are more well-defined (because file scope ctors and
dtors have unspecified ordering). But a bigger problem is local
objects. A call to atexit() affects global program behavior but
it doesn't affect local program behavior - break's and continue's
are stil just break's and continue's, etc. With local objects
(that have constructor/destructor behavior) that is no longer
true - any control transfer might be accompanied by a dtor call.
(Disclaimer: I believe this is true for any control transfer,
but I haven't thought carefully to see if some classes of
transfer might be excludeable.)
>> Let me be clear that I don't mean to argue against adding some
>> limited form of classes to C (or perhaps a relative of C that is
>> closer to C than C++ is). I understand your motivation, and at
>> least partly agree with it - encapsulation is a good thing, and C
>> is somewhat impoverished in that area. At the same time, it is
>> very important to exercise caution (even extreme caution) when
>> considering new language constructs, because seemingly minor
>> changes can have surprising effects on the character of the
>> language and its usage.
>
> I certainly approve of some caution, but not immobility.
It is not my intention or desire to freeze the process. The word
I used before is "caution", but that isn't quite right. What I
want to say is something more like "restraint" - changes, yes,
but as much as possible conservative changes. For example,
rather than ctors and dtors being fully general function bodies,
perhaps more restricted forms will give you what you want without
having to change the language so drastically.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-17 00:12 -0500 |
| Message-ID | <30mnhct2tsp9b8cri8jelmqtmsqk9se6iq@4ax.com> |
| In reply to | #110175 |
On Tue, 16 May 2017 12:54:37 -0700, Tim Rentsch
<txr@alumni.caltech.edu> wrote:
>Robert Wessel <robertwessel2@yahoo.com> writes:
>C has the wonderful property that everything is out in the open,
>with nothing hidden away somewhere else in the program. Consider
>code along the lines of this example:
>
> while ( c = *p++ ) {
> Foo x = { p-1, c };
> if ( c == '\n' ) continue;
> ... rest of loop ...
> }
>
>In C there is no need to wonder if moving the declaration of 'x'
>to just after the if() will change the program behavior. But if
>ctors and dtors have been added that is no longer true. To
>understand the behavior of this while() loop it is necessary to
>look somewhere else besides just the code in the loop. What is
>more important, that dependency is not obvious in the code itself
>(unlike, eg, function calls). That difference would give the
>language a very different feel.
That non-locality is certainly one of the complaints commonly leveled
against C++. As a practical matter I've never had real trouble with
that, outside of a few excessively large class hierarchies
(fortunately the class hierarchy needing a wall-sized chart to diagram
has fallen somewhat out of fashion). In any event, a limited
implementations of classes (without inheritance) would make for a
pretty short search for the code being invoked).
>> In any event, consider the following buried in the middle of a program
>> somewhere:
>>
>> atexit(ProcessDatabaseAndSendOneMillionSpamEmails);
>>
>> How is that better than a dtor invoked on global scope object?
>
>It's better in that the call is explicit in the statements
>executed rather than implicit in a simple declaration, and its
>semantics are more well-defined (because file scope ctors and
>dtors have unspecified ordering).
A pet peeve of mine. It makes automatic addition of things at file
scope to a collection at program startup painful. Trivially it could
be defined as in-order-of-occurrence within a translation unit (and
frankly, it may already be), but the problem is when there are
multiple translation units linked together.
> But a bigger problem is local
>objects. A call to atexit() affects global program behavior but
>it doesn't affect local program behavior - break's and continue's
>are stil just break's and continue's, etc. With local objects
>(that have constructor/destructor behavior) that is no longer
>true - any control transfer might be accompanied by a dtor call.
Again, it's not something I feel is a problem. While understanding
that other people have different opinions.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-17 08:15 -0700 |
| Message-ID | <64b5ae6a-1bc9-44c2-affa-099199efc3f6@googlegroups.com> |
| In reply to | #110199 |
On Wednesday, May 17, 2017 at 12:12:37 AM UTC-5, robert...@yahoo.com wrote: > A pet peeve of mine. It makes automatic addition of things at file > scope to a collection at program startup painful. Trivially it could > be defined as in-order-of-occurrence within a translation unit (and > frankly, it may already be), but the problem is when there are > multiple translation units linked together. It would seem helpful to have a recommendation that implementations should, when practical, specify that if any void(void) functions are declared with names that start with __stdc_autorun_, the system will execute them in implementation-defined sequence based upon names, after static variable default-zero initialization but before main(). A system may behave as though explicitly-initialized static variables are initialized to zero before any such functions are run, and are then later initialized to their specified values via compiler-generated functions whose names start with __stdc_autorun__, and names with two consecutive underscores after autorun would be reserved for that purpose. Such functionality could be added to many existing systems via a build- script utility which would build a list of all such functions within existing object files, generate a function that would call of them in sequence followed by main(), and produce an executable that would launch that new function rather than one called main(). In some cases, it might be necessary to rename the main function to something else, but a utility to patch the object file containing main() should not be infeasible.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-05-17 15:46 +0000 |
| Message-ID | <4f_SA.160564$3%2.83344@fx09.iad> |
| In reply to | #110207 |
supercat@casperkitty.com writes:
>On Wednesday, May 17, 2017 at 12:12:37 AM UTC-5, robert...@yahoo.com wrote:
>> A pet peeve of mine. It makes automatic addition of things at file
>> scope to a collection at program startup painful. Trivially it could
>> be defined as in-order-of-occurrence within a translation unit (and
>> frankly, it may already be), but the problem is when there are
>> multiple translation units linked together.
>
>It would seem helpful to have a recommendation that implementations should,
>when practical, specify that if any void(void) functions are declared with
>names that start with __stdc_autorun_, the system will execute them in
>implementation-defined sequence based upon names, after static variable
>default-zero initialization but before main(). A system may behave as
>though explicitly-initialized static variables are initialized to zero
>before any such functions are run, and are then later initialized to their
>specified values via compiler-generated functions whose names start with
>__stdc_autorun__, and names with two consecutive underscores after autorun
>would be reserved for that purpose.
All Unix/Linux systems already have such capabilities (leveraging
.init/.fini sections in the ELF codefile) to perform run-time
initialization of objects in libraries (shared objects) as they're
loaded.
The crt.o for C++ will also iterate over a vector of initialization
functions that execute static constructors.
extern void (*__CTOR_LIST__[])();
/*
* This is called by setup64.S to call the constructors of global objects,
* before it calls dvmm_bsp_start().
*
* GNU LD lays out the __CTOR_LIST__ as an array of function pointers. The
* first element of the array (index == 0) contains an integer which
* represents the value derived from subtracting two from the actual number
* of entries in the table. Thus the content of the first element is
* one less than the index of the last entry in the table.
*
* Call in reverse order XXX - why? Check crt0.o for canonical behavior
*/
extern "C" void
__call_constructors()
{
size_t count = *(size_t *)__CTOR_LIST__;
for(count++; count; --count) {
__CTOR_LIST__[count]();
}
}
/*
* G++'s generated code calls this if a pure virtual member is ever called.
*/
extern "C" void
__cxa_pure_virtual()
{
panic("pure virtual function called\n");
}
/*
* This is needed even though we don't ever use the delete operator because
* G++ generates an extra (unused) virtual destructor that calls it.
*/
void
operator delete(void *)
{
panic("operator delete(void*) called\n");
}
/*
* Catch unintended calls to new.
*/
void*
operator new(size_t)
{
panic("operator new(void*) called\n");
}
/*
* G++ generates code for shared library support, even though it isn't
* relevant (or called). That code looks for this symbol.
*/
void *__dso_handle;
/*
* Global object constructors call this to register their corresponding
* destructor. We just ignore it; we never call global object destructors
* because we never exit.
*/
extern "C" int
__cxa_atexit(void (*f)(void *), void *p, void *d)
{
return 0;
}
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-17 08:57 -0700 |
| Message-ID | <cbbb99d8-2dbb-42ed-8d6f-ae61e107f4b6@googlegroups.com> |
| In reply to | #110209 |
On Wednesday, May 17, 2017 at 10:46:18 AM UTC-5, Scott Lurndal wrote: > supercat writes: > >It would seem helpful to have a recommendation that implementations should, > >when practical, specify that if any void(void) functions are declared with > >names that start with __stdc_autorun_, the system will execute them in > >implementation-defined sequence based upon names, after static variable > >default-zero initialization but before main(). A system may behave as > >though explicitly-initialized static variables are initialized to zero > >before any such functions are run, and are then later initialized to their > >specified values via compiler-generated functions whose names start with > >__stdc_autorun__, and names with two consecutive underscores after autorun > >would be reserved for that purpose. > > All Unix/Linux systems already have such capabilities (leveraging > .init/.fini sections in the ELF codefile) to perform run-time > initialization of objects in libraries (shared objects) as they're > loaded. I would not expect many hosted implementations to have difficulty providing such a feature. I think having a standard means by which source code could request such a thing, however, would be more helpful than requiring the use of system-dependent means of achieving such effects. Using reserved names for the purpose should make it practical for code that uses the feature to be adapted to almost any system which doesn't use the names for some contrary purpose; at worst, someone targeting such a system could manually write a function to call all of the necessary initialization functions and then call that from main(). I would expect that freestanding implementations which begin execution with main() should generally be able to provide such a feature, but those which generate functions for use within other code might have difficulties. A sensible way of accomodating such limitations may be to say that future platforms must define a macro to indicate whether they support the feature, as well as a macro which, if inserted at file scope, will cause a program to be rejected if it cannot accommodate the feature [e.g. by including a dummy reference to a linker symbol that would be defined if the feature is supported but not otherwise].
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-05-17 09:45 -0700 |
| Message-ID | <lnmvab3003.fsf@kst-u.example.com> |
| In reply to | #110211 |
supercat@casperkitty.com writes:
[...]
> I would expect that freestanding implementations which begin execution with
> main() should generally be able to provide such a feature, but those which
> generate functions for use within other code might have difficulties. A
> sensible way of accomodating such limitations may be to say that future
> platforms must define a macro to indicate whether they support the feature,
> as well as a macro which, if inserted at file scope, will cause a program to
> be rejected if it cannot accommodate the feature [e.g. by including a dummy
> reference to a linker symbol that would be defined if the feature is
> supported but not otherwise].
Even assuming the first macro is a good idea, the second is unnecessary.
#ifndef FEATURE_IMPLEMENTED
#error "Feature is not implemented"
#endif
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-05-17 10:09 -0700 |
| Message-ID | <e53c182c-e029-4602-b942-c65fdaa18130@googlegroups.com> |
| In reply to | #110218 |
On Wednesday, May 17, 2017 at 11:45:58 AM UTC-5, Keith Thompson wrote: > supercat writes: > [...] > > I would expect that freestanding implementations which begin execution with > > main() should generally be able to provide such a feature, but those which > > generate functions for use within other code might have difficulties. A > > sensible way of accomodating such limitations may be to say that future > > platforms must define a macro to indicate whether they support the feature, > > as well as a macro which, if inserted at file scope, will cause a program to > > be rejected if it cannot accommodate the feature [e.g. by including a dummy > > reference to a linker symbol that would be defined if the feature is > > supported but not otherwise]. > > Even assuming the first macro is a good idea, the second is unnecessary. > > #ifndef FEATURE_IMPLEMENTED > #error "Feature is not implemented" > #endif Especially on freestanding implementations, support for the second feature may be dependent upon what is done with the object files produced by the compiler, and a compiler would have no way of knowing that. A compiler could, however, document that a build system which supports the feature must define a particular external symbol and one which does not must refrain from doing so.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-05-17 11:37 -0500 |
| Message-ID | <mhuohcp92icen9l63hsog3nosme7876hh7@4ax.com> |
| In reply to | #110207 |
On Wed, 17 May 2017 08:15:29 -0700 (PDT), supercat@casperkitty.com wrote: >On Wednesday, May 17, 2017 at 12:12:37 AM UTC-5, robert...@yahoo.com wrote: >> A pet peeve of mine. It makes automatic addition of things at file >> scope to a collection at program startup painful. Trivially it could >> be defined as in-order-of-occurrence within a translation unit (and >> frankly, it may already be), but the problem is when there are >> multiple translation units linked together. > >It would seem helpful to have a recommendation that implementations should, >when practical, specify that if any void(void) functions are declared with >names that start with __stdc_autorun_, the system will execute them in >implementation-defined sequence based upon names, after static variable >default-zero initialization but before main(). A system may behave as >though explicitly-initialized static variables are initialized to zero >before any such functions are run, and are then later initialized to their >specified values via compiler-generated functions whose names start with >__stdc_autorun__, and names with two consecutive underscores after autorun >would be reserved for that purpose. > >Such functionality could be added to many existing systems via a build- >script utility which would build a list of all such functions within >existing object files, generate a function that would call of them in >sequence followed by main(), and produce an executable that would launch >that new function rather than one called main(). In some cases, it might >be necessary to rename the main function to something else, but a utility >to patch the object file containing main() should not be infeasible. I'd prefer something a bit less hackish. Another simple (and hackish) scheme is to use some modifier to assign an optional priority, and call the ctors in order by priority. The problem with approaches like that is that they're not very maintainable, nor do they scale to projects where all the source is not under one entities control. It's hard to insert a new dependency in the middle of an existing chain, especially if you aren't the one who's defined the whole chain. I don't know if there is a reasonable solution.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-05-18 07:24 +1200 |
| Message-ID | <eo3mbhF5ec3U2@mid.individual.net> |
| In reply to | #110207 |
On 05/18/17 03:15 AM, supercat@casperkitty.com wrote: > On Wednesday, May 17, 2017 at 12:12:37 AM UTC-5, robert...@yahoo.com wrote: >> A pet peeve of mine. It makes automatic addition of things at file >> scope to a collection at program startup painful. Trivially it could >> be defined as in-order-of-occurrence within a translation unit (and >> frankly, it may already be), but the problem is when there are >> multiple translation units linked together. > > It would seem helpful ... Please don't over snip, readers should have to search up thread to find out what the pet peeve was! -- Ian
[toc] | [prev] | [next] | [standalone]
Page 5 of 19 — ← Prev page 1 … 3 4 [5] 6 7 … 19 Next page →
Back to top | Article view | comp.lang.c
csiph-web