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 1 of 10 [1] 2 3 … 10 Next page →
| From | G G <gdotone@gmail.com> |
|---|---|
| Date | 2015-11-04 06:22 -0800 |
| Subject | One over another: (*structp).component structp->component |
| Message-ID | <cbf00349-353f-4490-bc03-ad637a470e05@googlegroups.com> |
(*structp).component structp->component Is there an advantage of choosing one over the other. (equivalent expressions) That comes from p. 577, Problem Solving and Program Design, by Elliot B. Koffman. Also, how would you read those? like: bad attempt follows... (*structp).component : structp is a pointer of type (whatever structp is a structure type of) of component, with component, ???
[toc] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-11-04 09:37 -0500 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1d52p$5hm$1@dont-email.me> |
| In reply to | #74838 |
On 11/4/2015 9:22 AM, G G wrote:
> (*structp).component structp->component
>
> Is there an advantage of choosing one over the other. (equivalent expressions)
They are equivalent. The second form, with the "arrow," is
used much more frequently; the first is seldom seen.
> That comes from p. 577, Problem Solving and Program Design, by Elliot B. Koffman.
>
> Also, how would you read those?
>
> like:
>
> bad attempt follows...
> (*structp).component :
> structp is a pointer of type (whatever structp is a structure type of) of component,
> with component, ???
We can tell by the syntax (in either form) that `structp' is a
pointer to some kind of struct or union. The struct or union type
has an element named `component', but from what you have shown there
is no way to discern the type of that element.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | G G <gdotone@gmail.com> |
|---|---|
| Date | 2015-11-04 06:59 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <dd22abd4-5811-40ed-a9e6-c3d1f10058a7@googlegroups.com> |
| In reply to | #74842 |
On Wednesday, November 4, 2015 at 9:37:28 AM UTC-5, Eric Sosman wrote:
> On 11/4/2015 9:22 AM, G G wrote:
> > (*structp).component structp->component
> We can tell by the syntax (in either form) that `structp' is a
> pointer to some kind of struct or union. The struct or union type
> has an element named `component', but from what you have shown there
> is no way to discern the type of that element.
let me give the example from the book. I understand it, but how would you say it.
#define STRSIZ 10
typedef struct {
char name[STRSIZ];
double diameter;
int moons;
double orbit_time,
rotation_time;
} planet_t;
typedef struct {
double diameter;
planet_t planets[9];
char galaxy[STRSIZ];
} solar_sys_t;
int
scan_planet(planet_t *plnp) /* output - address of planet_t structure
to fill */
{
int result;
result = scan("%s%lf%d%lf%lf", (*plnp).name,
&(*plnp).diameter,
&(*plnp).moons,
&(*plnp).orbit_time,
&(*plnp).rotation_time);
if (result == 5)
result = 1;
else if (result != EOF)
result = 0;
return (result);
}
or it could be written as:
result = scanf("%s%lf%d%lf%lf", plnp->name,
&plnp->diameter,
&plnp->moons,
&plnp->orbit_time,
&plnp->rotation_time);
I understand that they are equivalent.
but how do you express in words: (*plnp).name and plnp->name?
like: int *ptr, ptr is a pointer to a type int.
Sorry for the confusion.
Thanks Eric.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-11-04 15:52 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1d9g4$mvi$1@dont-email.me> |
| In reply to | #74845 |
On 04/11/2015 14:59, G G wrote:
> result = scan("%s%lf%d%lf%lf", (*plnp).name,
> &(*plnp).diameter,
> &(*plnp).moons,
> &(*plnp).orbit_time,
> &(*plnp).rotation_time);
> result = scanf("%s%lf%d%lf%lf", plnp->name,
> &plnp->diameter,
> &plnp->moons,
> &plnp->orbit_time,
> &plnp->rotation_time);
>
As I understand it, the normal syntax to access an element m at the
other end of a pointer to struct p is:
(*p).m
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
(I expect many who use p->m don't aren't even aware that it can be
written using normal C pointer dereference and member selection
operators "*" and ".")
(The same thing happens when you have a pointer to array q and want to
access element i:
(*q)[i]
But in this case there is no shorthand operator. Probably the reason is
that hardly anyone uses pointers to arrays (except me!). They use
instead a pointer to an element of the array. If the array is A (either
an array eg 'int A[]', or a pointer to an element 'int* A'), then the
syntax is:
A[i] or *(A+i)
)
> I understand that they are equivalent.
Yes.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-04 22:05 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <87pozp2zfa.fsf@bsb.me.uk> |
| In reply to | #74850 |
Bartc <bc@freeuk.com> writes: <snip> > As I understand it, the normal syntax to access an element m at the > other end of a pointer to struct p is: > > (*p).m It's nor normal in the sense that it's rarely seen and not usually recommended. > 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 ->. What did change was that (*exp).member and exp->member *became* equivalent, when originally they were not. In "old C" and in K&R, the expression to the left of the -> could a pointer or an int. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-11-04 22:20 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1e07h$n3n$1@dont-email.me> |
| In reply to | #74880 |
On 04/11/2015 22:05, Ben Bacarisse wrote: > Bartc <bc@freeuk.com> writes: > <snip> >> As I understand it, the normal syntax to access an element m at the >> other end of a pointer to struct p is: >> >> (*p).m > > It's nor normal in the sense that it's rarely seen and not usually > recommended. OK, that would be the natural way to do it then. * is the deference operator; "." is the member select operator. No real need for another operator like "->". >> 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. What possible reason could there have been for having "->", when * and . would do the job perfectly adequately? I /think/ that -> was used because (*p).m was ungainly. With a postfix * dereference op allowing you to write p*.m, probably -> would have been unnecessary (although there are then other problems). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-04 23:32 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <87fv0l2ve8.fsf@bsb.me.uk> |
| In reply to | #74882 |
Bartc <bc@freeuk.com> writes: > On 04/11/2015 22:05, Ben Bacarisse wrote: >> Bartc <bc@freeuk.com> writes: >> <snip> >>> As I understand it, the normal syntax to access an element m at the >>> other end of a pointer to struct p is: >>> >>> (*p).m >> >> It's nor normal in the sense that it's rarely seen and not usually >> recommended. > > OK, that would be the natural way to do it then. * is the deference > operator; "." is the member select operator. No real need for another > operator like "->". There's no real need for -> or the (*p).m form. Simply writing p.m is entirely unambiguous because the compiler knows if p is a pointer or a struct (or union). >>> 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. > What possible reason could > there have been for having "->", when * and . would do the job > perfectly adequately? Because, as I explained, (*p).m and p->m were not the same. They only became equivalent much later. > I /think/ that -> was used because (*p).m was ungainly. I don't think it was "added" but was there right from the start because it imposed a new useful context on the left hand side. I think this because (*p).m and p->m were not the same in early C[1]. In early C, for example, allowed 024->st_mem but to outlawed (*024).st_mem. > With a postfix > * dereference op allowing you to write p*.m, probably -> would have > been unnecessary (although there are then other problems). Only if *. was a distinct operator. I think you've ignored the fact that (*p).m and p->m were deliberately different in the original design of the language. [1] See the various documents linked form https://www.bell-labs.com/usr/dmr/www/index.html -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-11-04 15:55 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <1b3a831d-c188-4e39-892c-a14062196197@googlegroups.com> |
| In reply to | #74891 |
On Wednesday, November 4, 2015 at 6:32:40 PM UTC-5, Ben Bacarisse wrote: > There's no real need for -> or the (*p).m form. Simply writing p.m is > entirely unambiguous because the compiler knows if p is a pointer or a > struct (or union). Are you saying that a C compiler WILL TODAY ALLOW "p.m" if p is a native type, or if p is a pointer to a native type? Or that it WOULD BE possible for a C compiler to use only "." because it would know what type p is? Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-05 00:21 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <87a8qt2t3u.fsf@bsb.me.uk> |
| In reply to | #74896 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Wednesday, November 4, 2015 at 6:32:40 PM UTC-5, Ben Bacarisse wrote: >> There's no real need for -> or the (*p).m form. Simply writing p.m is >> entirely unambiguous because the compiler knows if p is a pointer or a >> struct (or union). > > Are you saying that a C compiler WILL TODAY ALLOW "p.m" if p is a native > type, or if p is a pointer to a native type? Or that it WOULD BE possible > for a C compiler to use only "." because it would know what type p is? That it would be possible. Now that the typing it stronger, C does not need both . and ->. Go has gone that route for example. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-11-04 15:58 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <9c6f1af6-c806-4bf0-9b01-89448f5d0fd4@googlegroups.com> |
| In reply to | #74891 |
On Wednesday, November 4, 2015 at 6:32:40 PM UTC-5, Ben Bacarisse wrote:
> ...In early C,
> for example, allowed 024->st_mem but to outlawed (*024).st_mem.
How did it know the context of "024"? What type it related to? I could
only see such a feature working as:
((SWhatever*)024)->st_mem
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-05 00:26 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <874mh12sw6.fsf@bsb.me.uk> |
| In reply to | #74897 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Wednesday, November 4, 2015 at 6:32:40 PM UTC-5, Ben Bacarisse wrote:
>> ...In early C,
>> for example, allowed 024->st_mem but to outlawed (*024).st_mem.
>
> How did it know the context of "024"? What type it related to? I could
> only see such a feature working as:
>
> ((SWhatever*)024)->st_mem
In early C, struct members were not limited to be uned with a particular
struct. They denoted, in effect, simply a type and an offset. You
could access any member from any lvalue, even ones that were not structs
at all:
struct { char hi, lo; };
int i;
i.hi /* valid in old C */
As a result, 100->lo is simply the byte at offset 1 from the pair found
at address 100.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-04 16:27 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <e10943ca-cd4d-48ea-9ed4-cee9658abdc9@googlegroups.com> |
| In reply to | #74897 |
On Wednesday, November 4, 2015 at 5:58:19 PM UTC-6, Rick C. Hodgin wrote: > How did it know the context of "024"? What type it related to? I could > only see such a feature working as: > > ((SWhatever*)024)->st_mem In the early days of C, all structure members existed in the same namespace. Effectively, all structs existed as anonymous members of one union type.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-11-05 00:25 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1e7i3$kc5$1@dont-email.me> |
| In reply to | #74891 |
On 04/11/2015 23:32, Ben Bacarisse wrote: > Bartc <bc@freeuk.com> writes: > >> On 04/11/2015 22:05, Ben Bacarisse wrote: >>> Bartc <bc@freeuk.com> writes: >>> <snip> >>>> As I understand it, the normal syntax to access an element m at the >>>> other end of a pointer to struct p is: >>>> >>>> (*p).m >>> >>> It's nor normal in the sense that it's rarely seen and not usually >>> recommended. >> >> OK, that would be the natural way to do it then. * is the deference >> operator; "." is the member select operator. No real need for another >> operator like "->". > > There's no real need for -> or the (*p).m form. Simply writing p.m is > entirely unambiguous because the compiler knows if p is a pointer or a > struct (or union). The dereference is necessary (otherwise the type system won't work). You're suggesting that that should be done automatically by the language. Some people will agree, others won't. (I don't agree for this level of language; I prefer these things to be explicit so that I can see what's what. That's why I don't like A[i] and B[i] looking the same even though A is int* and B is int[10].) >> 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. No I don't have any information about it. It's a deduction, and I used 'presumably' when I first mentioned it. If I'm wrong about that and -> was always present with another meaning, that -> is what is preferred now instead of (*). >> With a postfix >> * dereference op allowing you to write p*.m, probably -> would have >> been unnecessary (although there are then other problems). > > Only if *. was a distinct operator. No, "*" and "." would need to be distinct to make it work. (Like Pascal in other words which uses "^" and "." for the same purposes.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-05 00:59 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <87y4ed1cs2.fsf@bsb.me.uk> |
| In reply to | #74899 |
Bartc <bc@freeuk.com> writes: > On 04/11/2015 23:32, Ben Bacarisse wrote: >> Bartc <bc@freeuk.com> writes: <snip> >>> With a postfix >>> * dereference op allowing you to write p*.m, probably -> would have >>> been unnecessary (although there are then other problems). >> >> Only if *. was a distinct operator. > > No, "*" and "." would need to be distinct to make it work. (Like > Pascal in other words which uses "^" and "." for the same purposes.) "-> would have been unnecessary" sounds like you are still talking about history -- un this can an alternate history where -> would no be needed. But in old C since (*p).m and p->m are different, you can't get the same semantics unless *. is different from * followed by .. In modern C, of course a postfix * would combine well with ., but then why the past tense? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-11-05 01:22 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1eass$tvs$1@dont-email.me> |
| In reply to | #74906 |
On 05/11/2015 00:59, Ben Bacarisse wrote: > Bartc <bc@freeuk.com> writes: > >> On 04/11/2015 23:32, Ben Bacarisse wrote: >>> Bartc <bc@freeuk.com> writes: > <snip> >>>> With a postfix >>>> * dereference op allowing you to write p*.m, probably -> would have >>>> been unnecessary (although there are then other problems). >>> >>> Only if *. was a distinct operator. >> >> No, "*" and "." would need to be distinct to make it work. (Like >> Pascal in other words which uses "^" and "." for the same purposes.) > > "-> would have been unnecessary" sounds like you are still talking about > history -- un this can an alternate history where -> would no be needed. > But in old C since (*p).m and p->m are different, you can't get the same > semantics unless *. is different from * followed by .. > > In modern C, of course a postfix * would combine well with ., but then > why the past tense? I suppose I meant if * for dereference had been postfix from the start. As it's hardly likely it'll be changed now! (But as I hinted, it could give (or would have given) a few problems with * for multiply, and it doesn't combine as well with ++ and -- (as I found in my own language which uses Pascal-style ^ for deference; Pascal didn't have ++ or --).) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-05 10:30 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <87mvus20xi.fsf@bsb.me.uk> |
| In reply to | #74908 |
Bartc <bc@freeuk.com> writes: > On 05/11/2015 00:59, Ben Bacarisse wrote: >> Bartc <bc@freeuk.com> writes: >> >>> On 04/11/2015 23:32, Ben Bacarisse wrote: >>>> Bartc <bc@freeuk.com> writes: >> <snip> >>>>> With a postfix >>>>> * dereference op allowing you to write p*.m, probably -> would have >>>>> been unnecessary (although there are then other problems). >>>> >>>> Only if *. was a distinct operator. >>> >>> No, "*" and "." would need to be distinct to make it work. (Like >>> Pascal in other words which uses "^" and "." for the same purposes.) >> >> "-> would have been unnecessary" sounds like you are still talking about >> history -- un this can an alternate history where -> would no be needed. >> But in old C since (*p).m and p->m are different, you can't get the same >> semantics unless *. is different from * followed by .. >> >> In modern C, of course a postfix * would combine well with ., but then >> why the past tense? > > I suppose I meant if * for dereference had been postfix from the > start. That's why I said "only if *. was a distinct operator". You can't sensibly get the different semantics that C originally had with a single postfix * and the member selection operator. I suppose you could have some special rules about a . immediately following a *, but that fails to make *. a distinct operator only in name, and is does not match with your reference to Pascal's ^ and .. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-04 18:09 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <lnsi4l5h9f.fsf@kst-u.example.com> |
| In reply to | #74899 |
Bartc <bc@freeuk.com> writes:
> On 04/11/2015 23:32, Ben Bacarisse wrote:
>> Bartc <bc@freeuk.com> writes:
[...]
>>> With a postfix * dereference op allowing you to write p*.m, probably
>>> -> would have been unnecessary (although there are then other
>>> problems).
>>
>> Only if *. was a distinct operator.
>
> No, "*" and "." would need to be distinct to make it work. (Like Pascal
> in other words which uses "^" and "." for the same purposes.)
Pascal's postfix `^` is similar to C's prefix `*`. So in Pascal you can
write `rec.member` (where rec is a record variable) or `ptr^.member`
(where ptr is a pointer to a record).
Ada uses `.` for both cases. The prefix can be either a record (like a C
struct) or a pointer to a record.
To refer to the entire record rather than just a member of it, you use
`Ptr.all`, where `all` is a keyword. This applies to all pointer types,
not just record pointer types. In effect, Ada's postfix `.all` is
equivalent to C's prefix `*`. `Ptr.member` can also be written as
`Ptr.all.member` (though you probably wouldn't do so).
--
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-06 01:08 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1guen$uf5$1@dont-email.me> |
| In reply to | #74899 |
On 05/11/2015 00:25, Bartc wrote:
> On 04/11/2015 23:32, Ben Bacarisse wrote:
>> Bartc <bc@freeuk.com> writes:
>>> OK, that would be the natural way to do it then. * is the deference
>>> operator; "." is the member select operator. No real need for another
>>> operator like "->".
>>
>> There's no real need for -> or the (*p).m form. Simply writing p.m is
>> entirely unambiguous because the compiler knows if p is a pointer or a
>> struct (or union).
>
> The dereference is necessary (otherwise the type system won't work).
> You're suggesting that that should be done automatically by the language.
>
> Some people will agree, others won't.
>
> (I don't agree for this level of language; I prefer these things to be
> explicit so that I can see what's what.
I remember now why I was uneasy about this.
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;
Then the standard * and . ops provides an easily scalable method of
dereferencing those pointers:
(*p).day
(**pp).day
(***ppp).day
But using ->, that only accounts for the final dereference, ie. a "*" op
followed by ".":
p->day
(*pp)->day
(**ppp)->day
Now, forget ->. And also allow any * dereference followed by "." to be
denoted just by ".". Now that first lot of examples:
(*p).day
(**pp).day
(***ppp).day
can be reduced down to these:
p.day
(*pp).day
(**ppp).day
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
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.
With normal dereferences, you can cancel out one * by adding a &
address-of prefix, so that &(**p).day is the same as (*p).day. What
happens however when you have just 'q.day' but want to lose a
dereference by writing &q.day? It becomes difficult to see what is going on.
Can a "*" dereference still be added manually? That would mean being
able to mix (**p).day, and (*p).day and p.day within the same
expression! I think it would be confusing.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-06 01:19 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1gv24$d0$1@dont-email.me> |
| In reply to | #75037 |
On 06/11/15 01:08, Bartc wrote: <snip> > With normal dereferences, you can cancel out one * by adding a & > address-of prefix, so that &(**p).day is the same as (*p).day. No. &(**p).day is the address of the 'day' member of (to take your example) a 'date' structure, and that structure is pointed to by a pointer which is in turn pointed to by p, and that's nothing like the same as (*p).day. You meant that (&**p).day is the same as (*p).day, I think. > What > happens however when you have just 'q.day' but want to lose a > dereference by writing &q.day? It becomes difficult to see what is going > on. Not at all. You won't "lose a dereference", though. &q.day is the address of the day member of the q struct. -- 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 11:30 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <87oaf7xt4b.fsf@bsb.me.uk> |
| In reply to | #75037 |
Bartc <bc@freeuk.com> writes:
> On 05/11/2015 00:25, Bartc wrote:
>> On 04/11/2015 23:32, Ben Bacarisse wrote:
>>> Bartc <bc@freeuk.com> writes:
>
>>>> OK, that would be the natural way to do it then. * is the deference
>>>> operator; "." is the member select operator. No real need for another
>>>> operator like "->".
>>>
>>> There's no real need for -> or the (*p).m form. Simply writing p.m is
>>> entirely unambiguous because the compiler knows if p is a pointer or a
>>> struct (or union).
>>
>> The dereference is necessary (otherwise the type system won't work).
>> You're suggesting that that should be done automatically by the language.
>>
>> Some people will agree, others won't.
>>
>> (I don't agree for this level of language; I prefer these things to be
>> explicit so that I can see what's what.
>
> I remember now why I was uneasy about this.
>
> 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;
>
> Then the standard * and . ops provides an easily scalable method of
> dereferencing those pointers:
>
> (*p).day
> (**pp).day
> (***ppp).day
>
> But using ->, that only accounts for the final dereference, ie. a "*"
> op followed by ".":
>
> p->day
> (*pp)->day
> (**ppp)->day
>
> Now, forget ->. And also allow any * dereference followed by "." to be
> denoted just by ".". Now that first lot of examples:
>
> (*p).day
> (**pp).day
> (***ppp).day
>
> can be reduced down to these:
>
> p.day
> (*pp).day
> (**ppp).day
>
> 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.
> 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).
> With normal dereferences, you can cancel out one * by adding a &
> address-of prefix, so that &(**p).day is the same as (*p).day.
It's (&**p).day not &(**p).day.
> What
> happens however when you have just 'q.day' but want to lose a
> dereference by writing &q.day? It becomes difficult to see what is
> going on.
I don't know what you mean by losing a dereference. &q.day does not
mean what you think it does (it's a pointer to one member) and you don't
give the type of q. What's more, you'd need to say if you are still
assuming that . must work with arbitrary levels. That, I agree, would
be confusing but the solution ot *that* is simple.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 1 of 10 [1] 2 3 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web