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 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-11 18:42 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n2021u$qk$1@dont-email.me> |
| In reply to | #75781 |
On 11/11/2015 17:31, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > >> On 11/11/2015 10:46, Ben Bacarisse wrote: >>> BartC <bc@freeuk.com> writes: >>> <snip> >>>> This sub-thread started with a discussion of operators "*" >>>> (dereference) followed by "." being replaced by just "." instead of >>>> "->". >>>> >>>> One reason to justify that was that, if "." was considered to be an >>>> operator, then the left-operand could have multiple overloads of the >>>> form T and T* (and probably T** and so on). >>> >>> Not "probably". No one advocated for that. >> >> But it will be a natural consequence. If you change the language so >> that (**p).m becomes (*p).m, > > No one suggested that. It was you that introduced the idea that there > was some sort of translation going on. Only by the incorrect > categorisation of the idea as a translation can you suggest that it has > this consequence. I gave the intended definition in relatives formal > language and it does not have this effect as a consequence, natural or > otherwise. I still can't see how the consequence can be avoided. It's probably easier to see using Pascal syntax. Given this expression: p^^^^^^.m the proposal, by whatever explanation of how it would work, effectively eliminates the last ^, so that we now have: p^^^^^.m You're saying it wouldn't go any further, while I don't think there's any point in stopping. (As, expressed this way, there doesn't seem much point in removing just one ^, especially if there will still be the choice of leaving it in, leading to confusion.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-11 23:38 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <87bnb0ayzj.fsf@bsb.me.uk> |
| In reply to | #75782 |
BartC <bc@freeuk.com> writes: > On 11/11/2015 17:31, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 11/11/2015 10:46, Ben Bacarisse wrote: >>>> BartC <bc@freeuk.com> writes: >>>> <snip> >>>>> This sub-thread started with a discussion of operators "*" >>>>> (dereference) followed by "." being replaced by just "." instead of >>>>> "->". >>>>> >>>>> One reason to justify that was that, if "." was considered to be an >>>>> operator, then the left-operand could have multiple overloads of the >>>>> form T and T* (and probably T** and so on). >>>> >>>> Not "probably". No one advocated for that. >>> >>> But it will be a natural consequence. If you change the language so >>> that (**p).m becomes (*p).m, >> >> No one suggested that. It was you that introduced the idea that there >> was some sort of translation going on. Only by the incorrect >> categorisation of the idea as a translation can you suggest that it has >> this consequence. I gave the intended definition in relatives formal >> language and it does not have this effect as a consequence, natural or >> otherwise. > > I still can't see how the consequence can be avoided. Yes, I know. > It's probably > easier to see using Pascal syntax. Given this expression: > > p^^^^^^.m > > the proposal, by whatever explanation of how it would work, > effectively eliminates the last ^, so that we now have: > > p^^^^^.m Yes it makes what you are saying clear, but I've never had any problem following what you are saying. You've decided, for your own rhetorical purposes, to rephrase what I was talking about as a translation or a replacement or an elimination (you've called it various things in that vein). > You're saying it wouldn't go any further, while I don't think there's > any point in stopping. An elimination or replacement can be iterated. But there is nothing to iterate in what I described: If E has structure or union type, E.m selects the m member of the structure or union denoted by E. If E has type pointer to structure or union, E.m selects the m member of the structure or union pointed to by E. Your meaning (which no one has advocated) could also be expressed in similar language but it would be more complicated and, importantly, it would be different language conveying a different intent. > (As, expressed this way, there doesn't seem > much point in removing just one ^, especially if there will still be > the choice of leaving it in, leading to confusion.) No doubt that's why you chose to express it like that. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-11 10:56 +0100 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1v38r$7k7$1@dont-email.me> |
| In reply to | #75688 |
On 10/11/15 23:15, Richard Heathfield wrote: > On 10/11/15 21:04, BartC wrote: >> * The (...) function 'operator' also has a few moonlighting jobs: >> enclosing function parameters, > > ?: encloses one of its operands too. And so does []. So what? > >> controlling evaluation order in an expression, > > I think you'll find that evaluation order is unspecified. > >> enclosing conditions for if and while, and enclosing the >> controlling expressions of a for-loop. > > Citation needed - please show where the Standard requires this. > I take this to mean that Bart thinks the "() function call operator" is special because the same characters, ( and ), are used for different purposes (as listed). Of course, the same applies to several other operators - the character "+" is the addition operator, the unary pluss operator, and half of the increment operators and part of a compound assignment operator.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-11 10:52 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1v6gv$ic9$1@dont-email.me> |
| In reply to | #75725 |
On 11/11/2015 09:56, David Brown wrote:
> On 10/11/15 23:15, Richard Heathfield wrote:
>> On 10/11/15 21:04, BartC wrote:
>
>>> * The (...) function 'operator' also has a few moonlighting jobs:
>>> enclosing function parameters,
>> ?: encloses one of its operands too. And so does []. So what?
(I meant enclosing function parameters in a prototype.
But now you mention it, "?:" is also odd. and "[]" for indexing is also
different. When I write parsers, such forms need special dedicated
handling as they have their own syntax.
Even once parsed into (ifx a b c) or (index a i), they are still treated
differently from (+ a b) or (- x). Amongst many reasons, because I allow
the first two to be l-values.)
>>> controlling evaluation order in an expression,
>>
>> I think you'll find that evaluation order is unspecified.
(You know what I mean here: (a+b)*c instead of a+b*c. But "+" is
presumably performed before the multiply in the first example, and after
the multiply in the second. If that isn't controlling evaluation order,
then I don't know what the purpose of (,) is here.)
>>> enclosing conditions for if and while, and enclosing the
>>> controlling expressions of a for-loop.
>>
>> Citation needed - please show where the Standard requires this.
(I can't be bothered to look. But I would be very surprised if I could
write:
if a==b {...}
for i=0; i<N; ++i {...}
So maybe you could show me where the Standard says I /don't/ need
parentheses for such statements.
> I take this to mean that Bart thinks the "() function call operator" is
> special because the same characters, ( and ), are used for different
> purposes (as listed). Of course, the same applies to several other
> operators - the character "+" is the addition operator, the unary pluss
> operator, and half of the increment operators and part of a compound
> assignment operator.
In token form, "+" is separate from "++", and has unary and binary versions.
While "()" is two tokens "(" and ")", with their many uses, always in
pairs, and for most of which I'm sure even the standard would not say
they are being used as operators.
But even once you get past the syntax and into some internal form, for
example:
(f x y) // function call
(+ x y) // binary add
There are still many differences between them as I've already listed.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-11 08:28 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <lnpozgsdox.fsf@kst-u.example.com> |
| In reply to | #75730 |
BartC <bc@freeuk.com> writes:
> On 11/11/2015 09:56, David Brown wrote:
>> On 10/11/15 23:15, Richard Heathfield wrote:
>>> On 10/11/15 21:04, BartC wrote:
>>
>>>> * The (...) function 'operator' also has a few moonlighting jobs:
>>>> enclosing function parameters,
>
>>> ?: encloses one of its operands too. And so does []. So what?
>
> (I meant enclosing function parameters in a prototype.
>
> But now you mention it, "?:" is also odd. and "[]" for indexing is also
> different. When I write parsers, such forms need special dedicated
> handling as they have their own syntax.
>
> Even once parsed into (ifx a b c) or (index a i), they are still treated
> differently from (+ a b) or (- x). Amongst many reasons, because I allow
> the first two to be l-values.)
Yes, some C operators require different handling than other C
operators. Not all operators are alike. The operands of the things
that the C standard calls "operators" are not always expressions, and
when they are expressions they're not always evaluated. The choice
of which things to call "operators" and which things not to call
"operators" is largely arbitrary.
If you were writing a parser for C, would the fact that the C
standard refers to ".", "->", and "()" as "operators" cause you
the slightest inconvenience?
[...]
>>>> enclosing conditions for if and while, and enclosing the
>>>> controlling expressions of a for-loop.
>>>
>>> Citation needed - please show where the Standard requires this.
>
> (I can't be bothered to look. But I would be very surprised if I could
> write:
>
> if a==b {...}
> for i=0; i<N; ++i {...}
>
> So maybe you could show me where the Standard says I /don't/ need
> parentheses for such statements.
Of course those examples are invalid.
Your original statement, quoted above, could be interpreted to require
parentheses around *each* of the controlling expressions of a for loop.
I'm sure that's not what you meant, but I suspect that's what Richard
was referring to, and that he misunderstood what you wrote.
for ((i = 0); (i < N); (++i)) {...}
The outer parentheses are required. The inner parentheses are not.
[...]
--
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-11 16:52 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1vrk6$426$1@dont-email.me> |
| In reply to | #75761 |
On 11/11/15 16:28, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> On 11/11/2015 09:56, David Brown wrote:
>>> On 10/11/15 23:15, Richard Heathfield wrote:
>>>> On 10/11/15 21:04, BartC wrote:
>>>
>>>>> * The (...) function 'operator' also has a few moonlighting jobs:
>>>>> enclosing function parameters,
>>
<snip>
>
>>>>> enclosing conditions for if and while, and enclosing the
>>>>> controlling expressions of a for-loop.
>>>>
>>>> Citation needed - please show where the Standard requires this.
>>
>> (I can't be bothered to look. But I would be very surprised if I could
>> write:
>>
>> if a==b {...}
>> for i=0; i<N; ++i {...}
>>
>> So maybe you could show me where the Standard says I /don't/ need
>> parentheses for such statements.
>
> Of course those examples are invalid.
>
> Your original statement, quoted above, could be interpreted to require
> parentheses around *each* of the controlling expressions of a for loop.
> I'm sure that's not what you meant, but I suspect that's what Richard
> was referring to, and that he misunderstood what you wrote.
No, the context is that of the function-call operator. As far as I am
aware, nothing in the Standard mandates that while/if/for/switch must be
implemented using the function-call operator. Parentheses, yes.
Function-call operator, no.
--
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-11 16:35 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1vqjd$ff$1@dont-email.me> |
| In reply to | #75730 |
On 11/11/15 10:52, BartC wrote:
> On 11/11/2015 09:56, David Brown wrote:
>> On 10/11/15 23:15, Richard Heathfield wrote:
>>> On 10/11/15 21:04, BartC wrote:
>>
>>>> * The (...) function 'operator' also has a few moonlighting jobs:
>>>> enclosing function parameters,
>
>>> ?: encloses one of its operands too. And so does []. So what?
>
> (I meant enclosing function parameters in a prototype.
Still so what?
> But now you mention it, "?:" is also odd. and "[]" for indexing is also
> different. When I write parsers, such forms need special dedicated
> handling as they have their own syntax.
As do the C versions. Again, so what?
> Even once parsed into (ifx a b c) or (index a i), they are still treated
> differently from (+ a b) or (- x). Amongst many reasons, because I allow
> the first two to be l-values.)
I don't see what you're getting at here. There is no requirement for all
operators to share the same syntax.
>
>>>> controlling evaluation order in an expression,
>>>
>>> I think you'll find that evaluation order is unspecified.
>
> (You know what I mean here: (a+b)*c instead of a+b*c.
We were talking about the function call operator, not parentheses used
for grouping arithmetical expressions.
> But "+" is
> presumably performed before the multiply in the first example, and after
> the multiply in the second. If that isn't controlling evaluation order,
> then I don't know what the purpose of (,) is here.)
C doesn't require it. Consider:
int a(void) { puts("A"); return 2; }
int b(void) { puts("B"); return 3; }
int c(void) { puts("C"); return 5; }
void foo(void)
{
int d = a()+b()*c();
printf("%d\n", d);
}
C requires that d be assigned the value 17, but the output could be any of:
A
B
C
17
A
C
B
17
B
A
C
17
or indeed any of the other three combinations. Adding the parentheses
can change the value printed for d:
void foo(void)
{
int d = (a()+b())*c();
printf("%d\n", d);
}
to 25, but the possibilities for the printing of A, B, and C are as
varied as before.
>
>>>> enclosing conditions for if and while, and enclosing the
>>>> controlling expressions of a for-loop.
>>>
>>> Citation needed - please show where the Standard requires this.
>
> (I can't be bothered to look.
Then you won't be surprised if I continue to believe that if, for,
while, and switch are not required to be implemented using the function
call operator.
> But I would be very surprised if I could
> write:
>
> if a==b {...}
> for i=0; i<N; ++i {...}
>
> So maybe you could show me where the Standard says I /don't/ need
> parentheses for such statements.
We're not talking about parentheses in general. We're talking about the
function call operator.
<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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-10 15:43 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <kfnsi4dfmj2.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #75634 |
BartC <bc@freeuk.com> writes: > 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 everyone agrees with that statement... http://www.houstonpress.com/arts/no-it-s-not-your-opinion-you-re-just-wrong-7611752
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-13 22:13 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <56466012.24590687@news.xs4all.nl> |
| In reply to | #75634 |
BartC <bc@freeuk.com> 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. My opinion is that you're not BartC, you're BillG. And that opinion can't be wrong, Billy-boy... ...or can it? Richard
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-13 23:52 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n25t01$vub$1@dont-email.me> |
| In reply to | #75978 |
On 13/11/2015 22:13, Richard Bos wrote: > BartC <bc@freeuk.com> 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. > > My opinion is that you're not BartC, you're BillG. And that opinion > can't be wrong, Billy-boy... > > ...or can it? We're talking about terminology, not easily proven or disproven facts. I'm also only looking at the bigger picture than your holy C standard, where these constructs are in use across a swathe of languages. The subject is also about a proposal to change the language, requiring a new Standard and rendering your current one worthless. That's the one that /currently/ calls "." and "->" 'operators', but will the new one do so? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-17 22:02 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <564ba300.24991968@news.xs4all.nl> |
| In reply to | #75990 |
BartC <bc@freeuk.com> wrote: > On 13/11/2015 22:13, Richard Bos wrote: > > BartC <bc@freeuk.com> 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. > > > > My opinion is that you're not BartC, you're BillG. And that opinion > > can't be wrong, Billy-boy... > > > > ...or can it? > > We're talking about terminology, not easily proven or disproven facts. No, we're talking about nomenclature. I have the documentation to prove that ->, in C, is called an operator, and so do you. Meanwhile, for all the documentation we have of you, you might as well be called Barack Hussein Obama. > I'm also only looking at the bigger picture than your holy C standard, > where these constructs are in use across a swathe of languages. Too bleedin' bad you're doing it in comp.lang.c, then, and not in comp.programming.holy-wars. > The subject is also about a proposal to change the language, requiring a > new Standard and rendering your current one worthless. That's the one > that /currently/ calls "." and "->" 'operators', but will the new one do so? ...yes. Yes, it will. It'll also call "return" a keyword, and C a programming language. You don't get to make these things up, they've been made up already, decades ago. Get over it already. Richard
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-17 23:56 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n2geng$fv$1@dont-email.me> |
| In reply to | #76299 |
On 17/11/2015 22:02, Richard Bos wrote: > BartC <bc@freeuk.com> wrote: >> We're talking about terminology, not easily proven or disproven facts. > > No, we're talking about nomenclature. Well I say it's terminology. > I have the documentation to prove > that ->, in C, is called an operator, and so do you. Meanwhile, for all > the documentation we have of you, you might as well be called Barack > Hussein Obama. The C standard is a user reference manual. If someone is involved in implementing it, they can choose whatever terms they like when doing so, including dropping the pretence that "." or "->" is anything like a regular operator if it makes things easier. >> I'm also only looking at the bigger picture than your holy C standard, >> where these constructs are in use across a swathe of languages. > > Too bleedin' bad you're doing it in comp.lang.c, then, and not in > comp.programming.holy-wars. You still don't get it. The subthread discussed introducing a new idea from outside the existing language. That means you are no longer tied to the Standard but have the freedom to think a tiny bit differently. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-17 20:10 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <lnk2pghrrq.fsf@kst-u.example.com> |
| In reply to | #76334 |
BartC <bc@freeuk.com> writes:
[...]
>> I have the documentation to prove
>> that ->, in C, is called an operator, and so do you. Meanwhile, for all
>> the documentation we have of you, you might as well be called Barack
>> Hussein Obama.
>
> The C standard is a user reference manual. If someone is involved in
> implementing it, they can choose whatever terms they like when doing so,
> including dropping the pretence that "." or "->" is anything like a
> regular operator if it makes things easier.
The C standard is effectively a contract between users and implementers;
it applies equally to both. Neither users nor compiler writers are
obligated to call "." and "->" operators -- unless of course they want
to be understood by other people who are familiar with C and its
standard.
>>> I'm also only looking at the bigger picture than your holy C standard,
>>> where these constructs are in use across a swathe of languages.
>>
>> Too bleedin' bad you're doing it in comp.lang.c, then, and not in
>> comp.programming.holy-wars.
>
> You still don't get it. The subthread discussed introducing a new idea
> from outside the existing language. That means you are no longer tied to
> the Standard but have the freedom to think a tiny bit differently.
The new idea is permitting `.` to be used as a synomym for `->` in
addition to its current meaning. The question of whether either of
should be called "operators" is, I think, completely orthogonal to
that. If the committee were to decide to make `.` a synonym for `->`,
I can't think of any reason why they'd also change the definition of
"operator".
Yes, `.` and `->` are different from other operators. *All* operators
are different from each other in some ways. That doesn't mean they're
not operators. Your definition of "operator" and the standard's
definition are, I'd say, equally valid -- except that the standard's
definition is *standard*, and is the only one I'm interested in using in
the context of 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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-18 11:51 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n2hokc$mm6$1@dont-email.me> |
| In reply to | #76348 |
On 18/11/2015 04:10, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> The C standard is a user reference manual. If someone is involved in >> implementing it, they can choose whatever terms they like when doing so, >> including dropping the pretence that "." or "->" is anything like a >> regular operator if it makes things easier. > Yes, `.` and `->` are different from other operators. *All* operators > are different from each other in some ways. That's certainly true of the motley assortment of programming constructs that C lumps together as 'operators'! Actually, is there anything that /isn't/ an operator, apart from obvious statement syntax and tokens such as numbers and identifiers? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-19 10:33 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <564da4cd.4098593@news.xs4all.nl> |
| In reply to | #76388 |
BartC <bc@freeuk.com> wrote: > On 18/11/2015 04:10, Keith Thompson wrote: > > > Yes, `.` and `->` are different from other operators. *All* operators > > are different from each other in some ways. > > That's certainly true of the motley assortment of programming constructs > that C lumps together as 'operators'! > > Actually, is there anything that /isn't/ an operator, apart from obvious > statement syntax and tokens such as numbers and identifiers? That's like asking whether there's anything living that isn't a protist, apart from the obvious bacteria, plants, animals and fungi. Richard
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-19 10:23 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <564da285.3514250@news.xs4all.nl> |
| In reply to | #76334 |
BartC <bc@freeuk.com> wrote: > On 17/11/2015 22:02, Richard Bos wrote: > > BartC <bc@freeuk.com> wrote: > > >> We're talking about terminology, not easily proven or disproven facts. > > > > No, we're talking about nomenclature. > > Well I say it's terminology. > > > I have the documentation to prove > > that ->, in C, is called an operator, and so do you. Meanwhile, for all > > the documentation we have of you, you might as well be called Barack > > Hussein Obama. > > The C standard is a user reference manual. No, it's an ISO International Standard. > > Too bleedin' bad you're doing it in comp.lang.c, then, and not in > > comp.programming.holy-wars. > > You still don't get it. The subthread discussed introducing a new idea > from outside the existing language. That means you are no longer tied to > the Standard but have the freedom to think a tiny bit differently. The new idea being not to call -> an operator? No? Why does that new idea then require that we change what -> is called? You might drum up more support for your Big New Idea if you didn't _fight_ the Standard to introduce it, but chose to work _with_ it. Richard
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-19 11:46 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n2kcmv$mno$1@dont-email.me> |
| In reply to | #76499 |
On 19/11/2015 10:23, Richard Bos wrote: > BartC <bc@freeuk.com> wrote: >> You still don't get it. The subthread discussed introducing a new idea >> from outside the existing language. That means you are no longer tied to >> the Standard but have the freedom to think a tiny bit differently. > > The new idea being not to call -> an operator? No? Why does that new > idea then require that we change what -> is called? No, it was to make just ".", as in "p.m", do the same job as either "p->m" or (*p).m. > You might drum up more support for your Big New Idea It wasn't my idea and I didn't like it. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-06 11:13 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <lnsi4j2b6p.fsf@kst-u.example.com> |
| In reply to | #75126 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> That's right. We must fix C so that +++++++42 does not work anymore.
> It's clearly absurd!
+++++++42 doesn't work. Did you mean + + + + + + +42?
--
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:42 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <874mgyx6bv.fsf@bsb.me.uk> |
| In reply to | #75158 |
Keith Thompson <kst-u@mib.org> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > [...] >> That's right. We must fix C so that +++++++42 does not work anymore. >> It's clearly absurd! > > +++++++42 doesn't work. Did you mean + + + + + + +42? Yes. Or !!!!!!!!!!0. Or ~~~~~~~~0. You get the idea. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-04 16:33 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <lnziyt5lpt.fsf@kst-u.example.com> |
| In reply to | #74891 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Bartc <bc@freeuk.com> writes:
>> On 04/11/2015 22:05, Ben Bacarisse wrote:
>>> Bartc <bc@freeuk.com> writes:
[...]
>>>> The parentheses are needed otherwise C rules would parse it as *(p.m),
>>>> which is not what you want.
>>>>
>>>> Presumably that was a bit much to be writing everywhere so the
>>>> following special operator was introduced:
>>>>
>>>> p->m
>>>
>>> How do you know that? C has has both . and -> for as long I've know the
>>> language it's had both for as long as I can tell from various manuals
>>> and so on, but that does not mean there was ont a time before C had ->.
>>
>> Well, maybe it was added very early on.
>
> Do you have any information to suggest it was not always present along
> with . and *? I don't, but you keep saying "added" as if you do.
The 1974 and 1975 versions of the C Reference manual (the earliest I can
find) have both the "." and "->" operators.
Except for the relaxation of the requirement that E1 be of pointer
type, the expression "E1−>MOS" is exactly equivalent to "(*E1).MOS".
(MOS is member-of-structure; C did not yet have unions.)
The prefix to the "." operator had to be an lvalue, but it was merely
*assumed* to refer to an object of the appropriate structure type.
If I'm not mistaken, that means you could do something like this:
struct word { char c0; char c1; };
int n;
n.c0 = 10;
n.c1 = 20;
The prefix of the "->" operator was assumed to be a pointer, but could
in fact be a pointer, character, or integer.
According to the 1972 B reference manual, B didn't have the "." or "->"
operator, nor did it have structs or unions.
[...]
> [1] See the various documents linked form
> https://www.bell-labs.com/usr/dmr/www/index.html
K&R1, published in 1978, says that the prefix to "." has to be of the
appropriate struct or union type, and that "E1->MOS" is the same as
"(*E1).MOS". But then it goes on to say that the rules are not enforced
strictly, "in order to allow an escape from the typing mechanism". The
prefix of "->" was still allowed to be either a pointer or an integer.
"Such constructions are non-portable".
*If* there was ever a version of C that had "." and not "->", it had to
have existed between 1975 and 1978, and as far as I can tell no
documentation of it has survived.
--
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 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web