Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #74838 > unrolled thread
| Started by | G G <gdotone@gmail.com> |
|---|---|
| First post | 2015-11-04 06:22 -0800 |
| Last post | 2015-11-05 21:24 -0800 |
| Articles | 20 on this page of 184 — 23 participants |
Back to article view | Back to comp.lang.c
One over another: (*structp).component structp->component G G <gdotone@gmail.com> - 2015-11-04 06:22 -0800
Re: One over another: (*structp).component structp->component Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-04 09:37 -0500
Re: One over another: (*structp).component structp->component G G <gdotone@gmail.com> - 2015-11-04 06:59 -0800
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-04 15:52 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-04 22:05 +0000
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-04 22:20 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-04 23:32 +0000
Re: One over another: (*structp).component structp->component "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-04 15:55 -0800
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-05 00:21 +0000
Re: One over another: (*structp).component structp->component "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-04 15:58 -0800
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-05 00:26 +0000
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-04 16:27 -0800
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-05 00:25 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-05 00:59 +0000
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-05 01:22 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-05 10:30 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-04 18:09 -0800
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-06 01:08 +0000
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-06 01:19 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-06 11:30 +0000
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-06 11:55 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-06 13:29 +0000
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-06 14:00 +0000
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-06 14:24 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-06 16:58 +0000
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-06 17:55 +0000
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-06 18:07 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-06 19:51 +0000
Re: One over another: (*structp).component structp->component Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-06 13:09 -0500
Re: One over another: (*structp).component structp->component Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-06 13:15 -0500
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-06 18:58 +0000
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-06 10:30 -0800
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-06 19:09 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-06 12:35 -0800
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-06 12:38 -0800
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-06 19:43 +0000
Re: One over another: (*structp).component structp->component raltbos@xs4all.nl (Richard Bos) - 2015-11-10 16:39 +0000
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-10 17:28 +0000
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-10 18:04 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-10 11:19 -0800
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-10 21:04 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-10 13:31 -0800
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-10 22:15 +0000
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-10 23:33 +0000
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-10 23:59 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-11 10:46 +0000
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-11 11:01 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-11 08:43 -0800
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-11 16:58 +0000
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-11 09:14 -0800
Re: One over another: (*structp).component structp->component glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-18 00:47 +0000
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-18 04:12 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-17 20:27 -0800
Re: One over another: (*structp).component structp->component glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-18 08:11 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-17 20:14 -0800
Re: One over another: (*structp).component structp->component glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-18 08:14 +0000
Re: One over another: (*structp).component structp->component James Kuyper <jameskuyper@verizon.net> - 2015-11-18 08:12 -0500
Re: One over another: (*structp).component structp->component glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-18 14:33 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-18 09:05 -0800
Re: One over another: (*structp).component structp->component glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-18 23:16 +0000
Re: One over another: (*structp).component structp->component James Kuyper <jameskuyper@verizon.net> - 2015-11-18 18:23 -0500
Re: One over another: (*structp).component structp->component glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-19 00:27 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-19 00:44 +0000
Re: One over another: (*structp).component structp->component glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-19 04:11 +0000
Re: One over another: (*structp).component structp->component James Kuyper <jameskuyper@verizon.net> - 2015-11-19 00:19 -0500
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-19 00:52 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-20 02:24 -0800
Re: One over another: (*structp).component structp->component glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-20 15:07 +0000
Re: One over another: (*structp).component structp->component Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-20 10:19 -0500
Re: One over another: (*structp).component structp->component Philip Lantz <prl@canterey.us> - 2015-11-23 00:06 -0800
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-18 16:21 +0000
Re: One over another: (*structp).component structp->component James Kuyper <jameskuyper@verizon.net> - 2015-11-18 13:29 -0500
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-18 22:00 +0000
Re: One over another: (*structp).component structp->component Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-18 17:33 -0500
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-20 15:38 -0800
Re: One over another: (*structp).component structp->component glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-18 23:23 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-19 00:12 +0000
Re: One over another: (*structp).component structp->component glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-12 09:00 +0000
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-12 10:12 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-11 17:31 +0000
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-11 18:42 +0000
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-11 23:38 +0000
Re: One over another: (*structp).component structp->component David Brown <david.brown@hesbynett.no> - 2015-11-11 10:56 +0100
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-11 10:52 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-11 08:28 -0800
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-11 16:52 +0000
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-11 16:35 +0000
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-10 15:43 -0800
Re: One over another: (*structp).component structp->component raltbos@xs4all.nl (Richard Bos) - 2015-11-13 22:13 +0000
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-13 23:52 +0000
Re: One over another: (*structp).component structp->component raltbos@xs4all.nl (Richard Bos) - 2015-11-17 22:02 +0000
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-17 23:56 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-17 20:10 -0800
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-18 11:51 +0000
Re: One over another: (*structp).component structp->component raltbos@xs4all.nl (Richard Bos) - 2015-11-19 10:33 +0000
Re: One over another: (*structp).component structp->component raltbos@xs4all.nl (Richard Bos) - 2015-11-19 10:23 +0000
Re: One over another: (*structp).component structp->component BartC <bc@freeuk.com> - 2015-11-19 11:46 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-06 11:13 -0800
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-06 19:42 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-04 16:33 -0800
Re: One over another: (*structp).component structp->component Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-04 13:11 -0500
Re: One over another: (*structp).component structp->component G G <gdotone@gmail.com> - 2015-11-04 11:49 -0800
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-04 20:00 +0000
Re: One over another: (*structp).component structp->component Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-04 15:36 -0500
Re: One over another: (*structp).component structp->component Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-04 15:16 -0800
Re: One over another: (*structp).component structp->component "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-04 15:28 -0800
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-04 16:25 -0800
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-05 00:47 +0000
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-04 19:24 -0800
Re: One over another: (*structp).component structp->component Ian Collins <ian-news@hotmail.com> - 2015-11-05 16:34 +1300
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-05 09:39 +0000
Re: One over another: (*structp).component structp->component David Brown <david.brown@hesbynett.no> - 2015-11-05 13:45 +0100
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-05 13:30 +0000
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-05 08:14 -0800
Re: One over another: (*structp).component structp->component G G <gdotone@gmail.com> - 2015-11-05 08:25 -0800
Re: One over another: (*structp).component structp->component Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-05 12:00 -0500
Re: One over another: (*structp).component structp->component G G <gdotone@gmail.com> - 2015-11-05 09:09 -0800
Re: One over another: (*structp).component structp->component "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-05 11:02 -0800
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-05 09:28 -0800
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-05 12:50 -0800
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-05 13:38 -0800
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-05 17:29 -0800
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-05 17:43 -0800
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-05 20:02 -0800
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-06 08:01 -0800
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-06 08:35 -0800
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-06 11:10 -0800
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-06 13:35 -0800
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-06 12:04 -0800
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-06 13:14 -0800
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-10 13:40 -0800
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-10 14:13 -0800
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-13 05:36 -0800
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-13 14:32 -0800
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-14 12:09 -0800
Re: One over another: (*structp).component structp->component raltbos@xs4all.nl (Richard Bos) - 2015-11-17 22:03 +0000
Re: One over another: (*structp).component structp->component David Thompson <dave.thompson2@verizon.net> - 2015-12-06 07:56 -0500
Re: One over another: (*structp).component structp->component G G <gdotone@gmail.com> - 2015-11-05 09:26 -0800
Re: One over another: (*structp).component structp->component Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-05 18:06 +0000
Re: One over another: (*structp).component structp->component G G <gdotone@gmail.com> - 2015-11-05 10:10 -0800
Re: One over another: (*structp).component structp->component G G <gdotone@gmail.com> - 2015-11-05 14:08 -0800
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-05 14:24 -0800
Re: One over another: (*structp).component structp->component James Kuyper <jameskuyper@verizon.net> - 2015-11-05 18:08 -0500
Re: One over another: (*structp).component structp->component G G <gdotone@gmail.com> - 2015-11-05 17:13 -0800
Re: One over another: (*structp).component structp->component James Kuyper <jameskuyper@verizon.net> - 2015-11-05 13:08 -0500
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-05 10:33 -0800
Re: One over another: (*structp).component structp->component James Kuyper <jameskuyper@verizon.net> - 2015-11-05 21:44 -0500
Re: One over another: (*structp).component structp->component David Brown <david.brown@hesbynett.no> - 2015-11-05 10:38 +0100
Re: One over another: (*structp).component structp->component Reinhardt Behm <rbehm@hushmail.com> - 2015-11-05 21:01 +0800
Re: One over another: (*structp).component structp->component James Kuyper <jameskuyper@verizon.net> - 2015-11-05 09:06 -0500
Re: One over another: (*structp).component structp->component "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-05 06:11 -0800
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-05 14:19 +0000
Re: One over another: (*structp).component structp->component Keith Thompson <kst-u@mib.org> - 2015-11-05 09:20 -0800
Re: One over another: (*structp).component structp->component James Kuyper <jameskuyper@verizon.net> - 2015-11-05 12:56 -0500
Re: One over another: (*structp).component structp->component raltbos@xs4all.nl (Richard Bos) - 2015-11-06 11:32 +0000
Re: One over another: (*structp).component structp->component David Brown <david.brown@hesbynett.no> - 2015-11-05 20:26 +0100
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-05 07:50 -0800
Re: One over another: (*structp).component structp->component Martin Shobe <martin.shobe@yahoo.com> - 2015-11-05 11:46 -0600
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-06 11:33 -0800
Re: One over another: (*structp).component structp->component Philip Lantz <prl@canterey.us> - 2015-11-07 00:32 -0800
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-13 03:43 -0800
Re: One over another: (*structp).component structp->component David Brown <david.brown@hesbynett.no> - 2015-11-07 20:03 +0100
Re: One over another: (*structp).component structp->component raltbos@xs4all.nl (Richard Bos) - 2015-11-10 16:42 +0000
Re: One over another: (*structp).component structp->component Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-13 04:03 -0800
Re: One over another: (*structp).component structp->component G G <gdotone@gmail.com> - 2015-11-04 19:42 -0800
Re: One over another: (*structp).component structp->component Reinhardt Behm <rbehm@hushmail.com> - 2015-11-05 12:54 +0800
Re: One over another: (*structp).component structp->component Bartc <bc@freeuk.com> - 2015-11-05 10:36 +0000
Re: One over another: (*structp).component structp->component Reinhardt Behm <rbehm@hushmail.com> - 2015-11-05 20:46 +0800
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-05 09:02 -0800
Re: One over another: (*structp).component structp->component raltbos@xs4all.nl (Richard Bos) - 2015-11-06 11:07 +0000
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-06 11:26 +0000
Re: One over another: (*structp).component structp->component raltbos@xs4all.nl (Richard Bos) - 2015-11-06 15:58 +0000
Re: One over another: (*structp).component structp->component Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-06 11:10 -0500
Re: One over another: (*structp).component structp->component Philip Lantz <prl@canterey.us> - 2015-11-07 01:13 -0800
Re: One over another: (*structp).component structp->component Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-07 11:11 -0500
Re: One over another: (*structp).component structp->component raltbos@xs4all.nl (Richard Bos) - 2015-11-10 16:47 +0000
Re: One over another: (*structp).component structp->component Siri Cruz <chine.bleu@yahoo.com> - 2015-11-04 06:49 -0800
Re: One over another: (*structp).component structp->component James Kuyper <jameskuyper@verizon.net> - 2015-11-04 09:55 -0500
Re: One over another: (*structp).component structp->component G G <gdotone@gmail.com> - 2015-11-04 07:00 -0800
Re: One over another: (*structp).component structp->component James Kuyper <jameskuyper@verizon.net> - 2015-11-04 13:19 -0500
Re: One over another: (*structp).component structp->component Richard Heathfield <rjh@cpax.org.uk> - 2015-11-04 16:17 +0000
Re: One over another: (*structp).component structp->component "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-04 14:53 -0800
Re: One over another: (*structp).component structp->component supercat@casperkitty.com - 2015-11-04 15:29 -0800
Re: One over another: (*structp).component structp->component luser droog <luser.droog@gmail.com> - 2015-11-05 21:24 -0800
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-11-06 11:55 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1i4an$42k$1@dont-email.me> |
| In reply to | #75074 |
On 06/11/2015 11:30, Ben Bacarisse wrote:
> Bartc <bc@freeuk.com> writes:
>> Suppose you have a struct:
>>
>> typedef struct {int day, month, year;} date;
>>
>> And various levels of pointer to it:
>>
>> date *p;
>> date ** pp;
>> date *** ppp;
>> It seems now that these reductions can be repeated to give:
>>
>> p.day
>> pp.day
>> (*ppp).day
>>
>> and finally:
>>
>> p.day
>> pp.day
>> ppp.day
>
> It depends on how you define '.'. There's no obvious reason to make it
> work at more levels of indirection. You'd simple define . to be the
> same as -> when the left hand side is a pointer.
But the -> clearly represents one reduction from (*p).day (to p->day).
If, however, you see (*q).day, has that already been reduced from
(**q).day? If not, you can rewrite it as (*q).day, but you can't tell
that at a glance.
Or would a reduction from what would be (*q).day to q.day be obligatory?
>> In other words, any number of pointer levels: data*********** q, can
>> be fully dereferenced by writing q.day. To me, that doesn't seem
>> right.
>
> Then don't do that (Go doesn't do that).
Well, C already has a track record in this!
If fn is a function pointer (either a real pointer, or just the name of
a function), then C allows you to write any of:
fn();
(*fn)();
(*************fn)();
to call that function.
(OK, it's not quite the same; if there are N levels of pointers to
function, you will need at least N-1 * dereferences to call it. Extra
dereferences are ignored. With one level of pointer, that means it can
be called just like a regular function.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-06 13:29 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <8737wjxnm9.fsf@bsb.me.uk> |
| In reply to | #75082 |
Bartc <bc@freeuk.com> writes:
> On 06/11/2015 11:30, Ben Bacarisse wrote:
>> Bartc <bc@freeuk.com> writes:
>
>>> Suppose you have a struct:
>>>
>>> typedef struct {int day, month, year;} date;
>>>
>>> And various levels of pointer to it:
>>>
>>> date *p;
>>> date ** pp;
>>> date *** ppp;
>
>>> It seems now that these reductions can be repeated to give:
>>>
>>> p.day
>>> pp.day
>>> (*ppp).day
>>>
>>> and finally:
>>>
>>> p.day
>>> pp.day
>>> ppp.day
>>
>> It depends on how you define '.'. There's no obvious reason to make it
>> work at more levels of indirection. You'd simple define . to be the
>> same as -> when the left hand side is a pointer.
>
> But the -> clearly represents one reduction from (*p).day (to p->day).
>
> If, however, you see (*q).day, has that already been reduced from
> (**q).day? If not, you can rewrite it as (*q).day, but you can't tell
> that at a glance.
Eh? Are you simply pointing out that you can't tell if the left-hand
side is a pointer or not. That's true, and it's probably the biggest
reason to be suspicious of this idea.
> Or would a reduction from what would be (*q).day to q.day be
> obligatory?
You've confused me with all this talk of "reduced". To avoid confusion
let's use # for the new universal selector. The idea is simply that
E1#member-name means E1->member_name when E1 has pointer type, and it
means E1.member_name otherwise.
You should be able to answer all your questions from this description.
I can't because I don't understand them.
>>> In other words, any number of pointer levels: data*********** q, can
>>> be fully dereferenced by writing q.day. To me, that doesn't seem
>>> right.
>>
>> Then don't do that (Go doesn't do that).
>
> Well, C already has a track record in this!
No, there is no situation in C where multiple levels of indirection are
taken automatically.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-11-06 14:00 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1ibml$vov$1@dont-email.me> |
| In reply to | #75092 |
On 06/11/2015 13:29, Ben Bacarisse wrote:
> Bartc <bc@freeuk.com> writes:
>
>> On 06/11/2015 11:30, Ben Bacarisse wrote:
>>> It depends on how you define '.'. There's no obvious reason to make it
>>> work at more levels of indirection. You'd simple define . to be the
>>> same as -> when the left hand side is a pointer.
>>
>> But the -> clearly represents one reduction from (*p).day (to p->day).
>>
>> If, however, you see (*q).day, has that already been reduced from
>> (**q).day? If not, you can rewrite it as (*q).day, but you can't tell
>> that at a glance.
>
> Eh? Are you simply pointing out that you can't tell if the left-hand
> side is a pointer or not.
That, and not being able to tell if (*q).day has already been
'converted' or 'rewritten' (if you don't like 'reduced') to the shorter
form.
> That's true, and it's probably the biggest
> reason to be suspicious of this idea.
>
>> Or would a reduction from what would be (*q).day to q.day be
>> obligatory?
>
> You've confused me with all this talk of "reduced". To avoid confusion
> let's use # for the new universal selector. The idea is simply that
>
> E1#member-name means E1->member_name when E1 has pointer type, and it
> means E1.member_name otherwise.
>
> You should be able to answer all your questions from this description.
> I can't because I don't understand them.
If it really was "#", then that wouldn't be so bad! But the problem is
that the sequence involving {"*", "."} is replaced by the shorter
sequence {"."}.
The "." occurs in both, which can lead to some ambiguity unless you go
and research the types involved to rediscover the information that has
been lost when you dropped the "*". Using "->" or "#" keeps that
information (as does keeping "*" and "." of course).
>>>> In other words, any number of pointer levels: data*********** q, can
>>>> be fully dereferenced by writing q.day. To me, that doesn't seem
>>>> right.
>>>
>>> Then don't do that (Go doesn't do that).
(That's inconsistent then. The same arguments that are used to eliminate
the first (or last) * in (***E1).member_name, can be applied to the next
"*" too!
That doesn't apply to the use of ->, because once -> replaces {"*","."}
the first time, you don't then have a new {"*","."} sequence to convert
recursively.)
>> Well, C already has a track record in this!
>
> No, there is no situation in C where multiple levels of indirection are
> taken automatically.
That's true; it is only a single level done automatically (although you
will probably argue, because of how C works, that that's not the case at
all).
It is the case however that you can add any number of extra dereferences
when writing a function call, and the compiler doesn't care.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-11-06 14:24 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1id35$5so$1@dont-email.me> |
| In reply to | #75096 |
On 06/11/2015 14:00, Bartc wrote:
> On 06/11/2015 13:29, Ben Bacarisse wrote:
>> You've confused me with all this talk of "reduced". To avoid confusion
>> let's use # for the new universal selector. The idea is simply that
>>
>> E1#member-name means E1->member_name when E1 has pointer type, and it
>> means E1.member_name otherwise.
>>
>> You should be able to answer all your questions from this description.
>> I can't because I don't understand them.
>
> If it really was "#", then that wouldn't be so bad! But the problem is
> that the sequence involving {"*", "."} is replaced by the shorter
> sequence {"."}.
>
> The "." occurs in both, which can lead to some ambiguity unless you go
> and research the types involved to rediscover the information that has
> been lost when you dropped the "*". Using "->" or "#" keeps that
> information (as does keeping "*" and "." of course).
That last bit's not right; I was assuming "#" would only be used to
represent "*" and ".", and not also just "." working on a plain value
struct.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-06 16:58 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <87lhabvzdq.fsf@bsb.me.uk> |
| In reply to | #75096 |
Bartc <bc@freeuk.com> writes: > On 06/11/2015 13:29, Ben Bacarisse wrote: >> Bartc <bc@freeuk.com> writes: >> >>> On 06/11/2015 11:30, Ben Bacarisse wrote: > >>>> It depends on how you define '.'. There's no obvious reason to make it >>>> work at more levels of indirection. You'd simple define . to be the >>>> same as -> when the left hand side is a pointer. >>> >>> But the -> clearly represents one reduction from (*p).day (to p->day). >>> >>> If, however, you see (*q).day, has that already been reduced from >>> (**q).day? If not, you can rewrite it as (*q).day, but you can't tell >>> that at a glance. >> >> Eh? Are you simply pointing out that you can't tell if the left-hand >> side is a pointer or not. > > That, and not being able to tell if (*q).day has already been > 'converted' or 'rewritten' (if you don't like 'reduced') to the > shorter form. I have no idea what you mean. Nothing has been converted. (*q).day would (under the new meaning) mean the day member of *q if *q is a struct or a union. It would mean the day member of the struct or union pointed to by *q if *q has pointer type. Yes, you need to know the type to know what the expression means but you appear to have some other complaint about conversions. <snip> >>>>> In other words, any number of pointer levels: data*********** q, can >>>>> be fully dereferenced by writing q.day. To me, that doesn't seem >>>>> right. >>>> >>>> Then don't do that (Go doesn't do that). > > (That's inconsistent then. The same arguments that are used to > eliminate the first (or last) * in (***E1).member_name, can be applied > to the next "*" too! No. Your problem is you've decided that it's about elimination (or reduction or conversion) so it looks inconsistent. In fact, it's about operator overloading. x.y would have two meanings depending on the type of a. That's all. One meaning is the old one. The other is the old meaning of ->. <snip> >>> Well, C already has a track record in this! >> >> No, there is no situation in C where multiple levels of indirection are >> taken automatically. > > That's true; it is only a single level done automatically (although > you will probably argue, because of how C works, that that's not the > case at all). Yes, I would. Am I wrong to argue about how C works? > It is the case however that you can add any number of extra > dereferences when writing a function call, and the compiler doesn't > care. That's right. We must fix C so that +++++++42 does not work anymore. It's clearly absurd! -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-11-06 17:55 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1ipev$pkj$1@dont-email.me> |
| In reply to | #75126 |
On 06/11/2015 16:58, Ben Bacarisse wrote: > Bartc <bc@freeuk.com> writes: >> (That's inconsistent then. The same arguments that are used to >> eliminate the first (or last) * in (***E1).member_name, can be applied >> to the next "*" too! > > No. Your problem is you've decided that it's about elimination (or > reduction or conversion) so it looks inconsistent. In fact, it's about > operator overloading. x.y would have two meanings depending on the type > of a. That's all. One meaning is the old one. The other is the old > meaning of ->. We'll have to leave it there then because we're not going to agree on anything. (For one thing, I don't consider "." or "->" operators, but syntactic constructs. Also I'm even less keen on using operator overloading!) >> It is the case however that you can add any number of extra >> dereferences when writing a function call, and the compiler doesn't >> care. > > That's right. We must fix C so that +++++++42 does not work anymore. > It's clearly absurd! That's not the same thing, as it doesn't walk all over the type system. That's assuming you mean + + + + + + +42. If you apply + to an expression of type int, the result is also of type int, and hence you can apply + as many times as you like. But when you have just one pointer to a function and the language lets you dereference it 28 times without complaint, just as you can when you have an actual chain of 28 pointers, then I think that's worthy of a raised eyebrow. Usually in a language typed like C, if you have an expression of type pointer-to-T, and dereference it, that yields an expression of type T. You can't dereference it further. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-06 18:07 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1iq5b$son$1@dont-email.me> |
| In reply to | #75140 |
On 06/11/15 17:55, Bartc wrote: <snip> > But when you have just one pointer to a function and the language lets > you dereference it 28 times without complaint, just as you can when you > have an actual chain of 28 pointers, then I think that's worthy of a > raised eyebrow. I agree with you so rarely that I thought it noteworthy for us, on this occasion, to see eye to eye. I'm far from being an expert on type systems but, as a user thereof, I find this: void func(void); void (*fptr)(void) = func; to be (mildly) illogical. At least according to my own version of the Principle of Least Astonishment, it would make sense for C to insist upon: void func(void); void (*fptr)(void) = &func; whereas in fact C merely *allows* it as an alternative. Likewise, I would have expected the call to have to look like this: (*fptr)(); which again C allows, but only as an alternative to fptr(), rather than as the required form. <snip> -- 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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-06 19:51 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <87si4ivrdb.fsf@bsb.me.uk> |
| In reply to | #75141 |
Richard Heathfield <rjh@cpax.org.uk> writes: <snip> > I'm far from being an expert on type systems but, as a user thereof, I > find this: > void func(void); > void (*fptr)(void) = func; > > to be (mildly) illogical. At least according to my own version of the > Principle of Least Astonishment, it would make sense for C to insist > upon: > > void func(void); > void (*fptr)(void) = &func; > > whereas in fact C merely *allows* it as an alternative. > > Likewise, I would have expected the call to have to look like this: > > (*fptr)(); > > which again C allows, but only as an alternative to fptr(), rather > than as the required form. Modern C does. But it used to be as you prefer in the days of K&R1. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-11-06 13:09 -0500 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1iq8m$t90$1@dont-email.me> |
| In reply to | #75140 |
On 11/6/2015 12:55 PM, Bartc wrote:
> [...]
> We'll have to leave it there then because we're not going to agree on
> anything. (For one thing, I don't consider "." or "->" operators, but
> syntactic constructs.
Have you filed a defect reports against 6.2.3p1, 6.5.2p1, and
6.5.2.3p1-4?
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2015-11-06 13:15 -0500 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <T66%x.663$qL.103@fx15.iad> |
| In reply to | #75140 |
On Friday November 6 2015 12:55, in comp.lang.c, "Bartc" <bc@freeuk.com> wrote: > On 06/11/2015 16:58, Ben Bacarisse wrote: [snip] >> That's right. We must fix C so that +++++++42 does not work anymore. >> It's clearly absurd! > > That's not the same thing, as it doesn't walk all over the type system. > > That's assuming you mean + + + + + + +42. I doubt that Ben means "+ + + + + + +42" in the context of "+++++++42". > If you apply + to an > expression of type int, the result is also of type int, and hence you > can apply + as many times as you like. Knowing Ben, he's not applying "+ to an expresssion of type int". Instead, he's using a property of the C language's Lexical Elements colloquially called "maximal munch". In practice, maximal munch means that +++++++42 is parsed as ++ ++ ++ +42 That is, three pre-increments to a positive integer value 42. [snip] -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-11-06 18:58 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1it5g$9e2$1@dont-email.me> |
| In reply to | #75145 |
On 06/11/2015 18:15, Lew Pitcher wrote: > On Friday November 6 2015 12:55, in comp.lang.c, "Bartc" <bc@freeuk.com> > wrote: > >> On 06/11/2015 16:58, Ben Bacarisse wrote: > [snip] >>> That's right. We must fix C so that +++++++42 does not work anymore. >>> It's clearly absurd! >> >> That's not the same thing, as it doesn't walk all over the type system. >> >> That's assuming you mean + + + + + + +42. > > I doubt that Ben means "+ + + + + + +42" in the context of "+++++++42". > >> If you apply + to an >> expression of type int, the result is also of type int, and hence you >> can apply + as many times as you like. > > Knowing Ben, he's not applying "+ to an expresssion of type int". Instead, > he's using a property of the C language's Lexical Elements colloquially > called "maximal munch". > > In practice, maximal munch means that > +++++++42 > is parsed as > ++ ++ ++ +42 > > That is, three pre-increments to a positive integer value 42. I don't think that's what Ben meant. He probably intended consecutive + operators and just wrote +++++++ in exasperation. Otherwise his remarks wouldn't make sense, as ++42 or ++ +42 doesn't work. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-06 10:30 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <527b5ade-841c-429b-8b64-0fb8959520f7@googlegroups.com> |
| In reply to | #75140 |
On Friday, November 6, 2015 at 11:56:01 AM UTC-6, Bart wrote: > We'll have to leave it there then because we're not going to agree on > anything. (For one thing, I don't consider "." or "->" operators, but > syntactic constructs. Also I'm even less keen on using operator > overloading!) I would suggest that the combination of a "." or "->" and an immediately- following identifier behaves as a unary postfix operator. I'm not really sure what term would best be applied to the "." or "->" since "token" is over-broad, and the behavior doesn't really coincide with normal operators, but I'm not sure I'd go so far as to say that the term "operator" is wrong, though processing of the right-hand "operand" would be outside the normal expression syntax and semantics. It should be noted, however, that there are other things which are called "operators" whose handling also differs from that of most operators. The second operand of "&&", for example, is not a value but rather a piece of code which, when executed, will yield a value. While that distinction is semantic rather than syntactic, the idea that operators can operate on things other than values would hardly be unique to "." and "->'.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-11-06 19:09 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1itq3$coq$1@dont-email.me> |
| In reply to | #75149 |
On 06/11/2015 18:30, supercat@casperkitty.com wrote: > On Friday, November 6, 2015 at 11:56:01 AM UTC-6, Bart wrote: >> We'll have to leave it there then because we're not going to agree on >> anything. (For one thing, I don't consider "." or "->" operators, but >> syntactic constructs. Also I'm even less keen on using operator >> overloading!) > > I would suggest that the combination of a "." or "->" and an immediately- > following identifier behaves as a unary postfix operator. I'm not really > sure what term would best be applied to the "." or "->" since "token" is > over-broad, and the behavior doesn't really coincide with normal operators, > but I'm not sure I'd go so far as to say that the term "operator" is wrong, > though processing of the right-hand "operand" would be outside the normal > expression syntax and semantics. Even when considered to unary operators, it's by no means clear what "." or "->" actually do with the values on their left. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-06 12:35 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <lnfv0i3lxy.fsf@kst-u.example.com> |
| In reply to | #75156 |
Bartc <bc@freeuk.com> writes:
> On 06/11/2015 18:30, supercat@casperkitty.com wrote:
>> On Friday, November 6, 2015 at 11:56:01 AM UTC-6, Bart wrote:
>>> We'll have to leave it there then because we're not going to agree on
>>> anything. (For one thing, I don't consider "." or "->" operators, but
>>> syntactic constructs. Also I'm even less keen on using operator
>>> overloading!)
>>
>> I would suggest that the combination of a "." or "->" and an immediately-
>> following identifier behaves as a unary postfix operator. I'm not really
>> sure what term would best be applied to the "." or "->" since "token" is
>> over-broad, and the behavior doesn't really coincide with normal operators,
>> but I'm not sure I'd go so far as to say that the term "operator" is wrong,
>> though processing of the right-hand "operand" would be outside the normal
>> expression syntax and semantics.
>
> Even when considered to unary operators, it's by no means clear what "."
> or "->" actually do with the values on their left.
What's unclear about it? The left operand (which must be an lvalue of
appropriate type) is evaluated. The result indicates the designated
object containing the member to which the right "operand" refers.
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-06 12:38 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <lnbnb63ltq.fsf@kst-u.example.com> |
| In reply to | #75179 |
Keith Thompson <kst-u@mib.org> writes:
> Bartc <bc@freeuk.com> writes:
>> On 06/11/2015 18:30, supercat@casperkitty.com wrote:
>>> On Friday, November 6, 2015 at 11:56:01 AM UTC-6, Bart wrote:
>>>> We'll have to leave it there then because we're not going to agree on
>>>> anything. (For one thing, I don't consider "." or "->" operators, but
>>>> syntactic constructs. Also I'm even less keen on using operator
>>>> overloading!)
>>>
>>> I would suggest that the combination of a "." or "->" and an immediately-
>>> following identifier behaves as a unary postfix operator. I'm not really
>>> sure what term would best be applied to the "." or "->" since "token" is
>>> over-broad, and the behavior doesn't really coincide with normal operators,
>>> but I'm not sure I'd go so far as to say that the term "operator" is wrong,
>>> though processing of the right-hand "operand" would be outside the normal
>>> expression syntax and semantics.
>>
>> Even when considered to unary operators, it's by no means clear what "."
>> or "->" actually do with the values on their left.
>
> What's unclear about it? The left operand (which must be an lvalue of
> appropriate type) is evaluated. The result indicates the designated
> object containing the member to which the right "operand" refers.
Oops!
My apologies, the left operand of `.` or `->` does not have to be an
lvalue.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-06 19:43 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <87y4eavrq8.fsf@bsb.me.uk> |
| In reply to | #75140 |
Bartc <bc@freeuk.com> writes: > On 06/11/2015 16:58, Ben Bacarisse wrote: >> Bartc <bc@freeuk.com> writes: > >>> (That's inconsistent then. The same arguments that are used to >>> eliminate the first (or last) * in (***E1).member_name, can be applied >>> to the next "*" too! >> >> No. Your problem is you've decided that it's about elimination (or >> reduction or conversion) so it looks inconsistent. In fact, it's about >> operator overloading. x.y would have two meanings depending on the type >> of a. That's all. One meaning is the old one. The other is the old >> meaning of ->. > > We'll have to leave it there Happy to. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-10 16:39 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <56421d7d.6850140@news.xs4all.nl> |
| In reply to | #75140 |
Bartc <bc@freeuk.com> wrote: > We'll have to leave it there then because we're not going to agree on > anything. (For one thing, I don't consider "." or "->" operators, but > syntactic constructs. Then you're clearly, fundamentally, demonstratably and documentedly wrong. The C Standard _does_ call them operators, and your opinion on the matter is as much chaff in the wind as mine. Richard
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-10 17:28 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1t9bm$8fh$1@dont-email.me> |
| In reply to | #75604 |
On 10/11/2015 16:39, Richard Bos wrote: > Bartc <bc@freeuk.com> wrote: > >> We'll have to leave it there then because we're not going to agree on >> anything. (For one thing, I don't consider "." or "->" operators, but >> syntactic constructs. > > Then you're clearly, fundamentally, demonstratably and documentedly > wrong. The C Standard _does_ call them operators, and your opinion on > the matter is as much chaff in the wind as mine. Since that's my opinion, it can't be wrong. Not until I change my mind. You presumably have no opinion of your own on the matter except what has been written. If you'd had to implement this stuff many times as I have, you might have discovered that treating "." as operator just like "+"doesn't really work. The standard also considers the parentheses in a function call such as f(a,b,c) to be an operator. I don't think of () in that context as an operator idea; I think many other people would have a problem with that too. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-10 18:04 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1tbek$h8a$1@dont-email.me> |
| In reply to | #75634 |
On 10/11/15 17:28, BartC wrote: > On 10/11/2015 16:39, Richard Bos wrote: >> Bartc <bc@freeuk.com> wrote: >> >>> We'll have to leave it there then because we're not going to agree on >>> anything. (For one thing, I don't consider "." or "->" operators, but >>> syntactic constructs. >> >> Then you're clearly, fundamentally, demonstratably and documentedly >> wrong. The C Standard _does_ call them operators, and your opinion on >> the matter is as much chaff in the wind as mine. > > Since that's my opinion, it can't be wrong. Not until I change my mind. That you hold the opinion is not in dispute. If you say it's your opinion, I believe you. But if your opinion is in conflict with a verifiable fact, then it is reasonable to say that your opinion is wrong. Whether . and -> are operators in the C language is not a matter of opinion, but a matter of verifiable fact. The C language is defined by an international standard which makes it very clear that . and -> are operators in that language. See, for example, 6.5.2.3 (Structure and union members) - Constraint 1: "The first operand of the . operator..." and Constraint 2: "The first operand of the -> operator..." Clearly, then, . and -> are operators. > You presumably have no opinion of your own on the matter except what has > been written. Such an opinion would be purposeless, since it is demonstrably false. > If you'd had to implement this stuff many times as I have, you might > have discovered that treating "." as operator just like "+"doesn't > really work. Well, it wouldn't. They do different things. If you choose to think of the . and -> operators as something other than operators, that's up to you, but don't be too surprised when people laugh. > The standard also considers the parentheses in a function call such as > f(a,b,c) to be an operator. I don't think of () in that context as an > operator idea; I think many other people would have a problem with that > too. It's perfectly reasonable to think of function-call () as an operator, with a pointer-to-function (eg the function's name) as one operand and the parameter list as a separate, possibly empty set of other operands. -- 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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-10 11:19 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <lnfv0du0fh.fsf@kst-u.example.com> |
| In reply to | #75645 |
Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
> Whether . and -> are operators in the C language is not a matter of
> opinion, but a matter of verifiable fact. The C language is defined by
> an international standard which makes it very clear that . and -> are
> operators in that language. See, for example, 6.5.2.3 (Structure and
> union members) - Constraint 1: "The first operand of the . operator..."
> and Constraint 2: "The first operand of the -> operator..."
>
> Clearly, then, . and -> are operators.
An interesting side note: the . and -> operators are listed in the
standard under "Postfix operators", like postfix ++ and --.
It would have been reasonable IMHO to treat the combinations
`. member_name` and `-> member_name` as postfix operators.
The prefix, which would be the operator's only operand, is an
expression; the member name would be part of the operator symbol.
However, that same section refers to the "first operand" and
"second operand" of the "." and "->" operators.
The fact that the C standard refers to "." and "->" as operators
with two operands is beyond dispute. This and some other cases
demonstrate that C does *not* use the word "operator" only to refer
to something whose operands are expressions (`sizeof ( typename )`
is another example). A description in which an operand of an
operator is always some kind of expression might arguably be more
consistent than the current C standard, and could easily describe
exactly the same language.
But this mild criticism of the way the standard chooses to describe
expression does not, in my opinion, justify rejecting the standard's
usage of the word "operator", which is (a) *reasonably* consistent
as long as you don't insist that operands must be expressions, and
(b) defined by the standard, which gives us a shared vocabulary we
can use to discuss the language.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web