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 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-11-18 18:23 -0500 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <564D0860.6020400@verizon.net> |
| In reply to | #76466 |
On 11/18/2015 06:16 PM, glen herrmannsfeldt wrote: > Keith Thompson <kst-u@mib.org> wrote: > > (snip, I wrote) > >>> (I presume that *&2 still doesn't work.) > >> Correct. The operand of `&` must be an lvalue, which `2` isn't. >> (It's not an object, so it doesn't have an address.) > > The reason for that comment was wondering if *&array works > when array is an array. Since array names aren't lvalue, it > seems that they shouldn't allow for &. "An identifier is a primary expression, provided it has been declared as designating an object (in which case it is an lvalue) ..." (6.5.1p2). An array name is an identifier, and it designates an object (namely, the named array). Are you thinking of the 6.3.2.1p3, which says "... an expression that has type ‘‘array of type’’ is converted to an expression with type ‘‘pointer to type’’ that points to the initial element of the array object and is not an lvalue." ? Keep in mind that those words are prefixed by "Except when it is the operand of ... the unary & operator ...", so 6.3.2.1p3 doesn't apply to this case. *&array is an lvalue of array type referring to precisely the same object as array itself.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-11-19 00:27 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n2j528$r6h$1@speranza.aioe.org> |
| In reply to | #76467 |
James Kuyper <jameskuyper@verizon.net> wrote: > On 11/18/2015 06:16 PM, glen herrmannsfeldt wrote: >> Keith Thompson <kst-u@mib.org> wrote: (snip, I wrote) >>>> (I presume that *&2 still doesn't work.) >>> Correct. The operand of `&` must be an lvalue, which `2` isn't. >>> (It's not an object, so it doesn't have an address.) Just to be sure, I mean array, like: int array[10]; >> The reason for that comment was wondering if *&array works >> when array is an array. Since array names aren't lvalue, it >> seems that they shouldn't allow for &. > "An identifier is a primary expression, provided it has been declared as > designating an object (in which case it is an lvalue) ..." (6.5.1p2). An > array name is an identifier, and it designates an object (namely, the > named array). int x[10], y[10]; x=y; /* if x is an lvalue */ > Are you thinking of the 6.3.2.1p3, which says "... an expression that > has type ‘‘array of type’’ is converted to an expression with type > ‘‘pointer to type’’ that points to the initial element of the array > object and is not an lvalue." ? > Keep in mind that those words are prefixed by "Except when it is the > operand of ... the unary & operator ...", so 6.3.2.1p3 doesn't apply to > this case. > *&array is an lvalue of array type referring to precisely the same > object as array itself. I am trying to remember cases where a * or & applied to some experession work the same as without the * or &. fp(x) and (*fp)(x) seem to mean the same thing. (*sp).y and sp->y but not sp.y I have certain ways that I write arrays and pointer expressions, and ways that I don't, the latter because they seem less obvious, or otherwise not needed. I always write array+i or p+i, and not &array[i], nor &p[i]. But then again, I was doing assembly programming some years before learning C. You get used to adding offsets to addresses and dereferencing them later. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-19 00:44 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <87wptevmvg.fsf@bsb.me.uk> |
| In reply to | #76471 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> James Kuyper <jameskuyper@verizon.net> wrote:
>> On 11/18/2015 06:16 PM, glen herrmannsfeldt wrote:
>>> Keith Thompson <kst-u@mib.org> wrote:
>
> (snip, I wrote)
>
>>>>> (I presume that *&2 still doesn't work.)
>
>>>> Correct. The operand of `&` must be an lvalue, which `2` isn't.
>>>> (It's not an object, so it doesn't have an address.)
>
> Just to be sure, I mean array, like:
>
> int array[10];
>
>>> The reason for that comment was wondering if *&array works
>>> when array is an array. Since array names aren't lvalue, it
>>> seems that they shouldn't allow for &.
>
>> "An identifier is a primary expression, provided it has been declared as
>> designating an object (in which case it is an lvalue) ..." (6.5.1p2). An
>> array name is an identifier, and it designates an object (namely, the
>> named array).
>
> int x[10], y[10];
> x=y; /* if x is an lvalue */
No, x must be a modifiable lvalue to appear on the left of an assignment
and it's not. It's not one for more the one reason -- the one that
applies here, I'd say, is that x is converted to a pointer that is not a
lvalue, but there is also 6.3.2.1 p1 ("A modifiable lvalue is an lvalue
that does not have array type...").
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-11-19 04:11 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n2ji69$iag$1@speranza.aioe.org> |
| In reply to | #76472 |
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
(snip, I wrote)
>>>>>> (I presume that *&2 still doesn't work.)
(snip, someone wrote)
>>>>> Correct. The operand of `&` must be an lvalue, which `2` isn't.
>>>>> (It's not an object, so it doesn't have an address.)
(snip on lvalue and &)
>> int x[10], y[10];
>> x=y; /* if x is an lvalue */
> No, x must be a modifiable lvalue to appear on the left of an assignment
> and it's not. It's not one for more the one reason -- the one that
> applies here, I'd say, is that x is converted to a pointer that is not a
> lvalue, but there is also 6.3.2.1 p1 ("A modifiable lvalue is an lvalue
> that does not have array type...").
OK, I never thought about non-modifiable lvalue before.
I always thought the whole idea of lvalue, what the l was for,
was that they could go on the left side of assignment operators.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-11-19 00:19 -0500 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n2jm0s$j5e$1@dont-email.me> |
| In reply to | #76481 |
On 11/18/2015 11:11 PM, glen herrmannsfeldt wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
> (snip, I wrote)
>
>>>>>>> (I presume that *&2 still doesn't work.)
>
> (snip, someone wrote)
>>>>>> Correct. The operand of `&` must be an lvalue, which `2` isn't.
>>>>>> (It's not an object, so it doesn't have an address.)
>
> (snip on lvalue and &)
>
>>> int x[10], y[10];
>>> x=y; /* if x is an lvalue */
>
>> No, x must be a modifiable lvalue to appear on the left of an assignment
>> and it's not. It's not one for more the one reason -- the one that
>> applies here, I'd say, is that x is converted to a pointer that is not a
>> lvalue, but there is also 6.3.2.1 p1 ("A modifiable lvalue is an lvalue
>> that does not have array type...").
>
> OK, I never thought about non-modifiable lvalue before.
>
> I always thought the whole idea of lvalue, what the l was for,
> was that they could go on the left side of assignment operators.
That's the origin of the term - lvalue was short for "left value".
However, that's not the definition of the term.
"An _lvalue_ is an expression (with an object type other than void) that
potentially designates an object;64) if an lvalue does not designate an
object when it is evaluated, the behavior is undefined. When an object
is said to have a particular type, the type is
specified by the lvalue used to designate the object. A modifiable
lvalue is an lvalue that does not have array type, does not have an
incomplete type, does not have a const-qualified type, and if it is a
structure or union, does not have any member (including, recursively,
any member or element of all contained aggregates or unions) with a
const-qualified type." (6.3.2.1p1)
I've used underscores to indicate that the first appearances of "lvalue"
and "modifiable lvalue" in the above paragraph are both italicized,
indicating that the sentences they appear in constitute the official
definitions for those terms.
lvalues can be used to read a value, as well as to write it, and in many
context lvalues of array type are automatically converted into pointers
to the first element of the array, which is NOT an lvalue.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-19 00:52 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n2j6ce$gcs$1@dont-email.me> |
| In reply to | #76471 |
On 19/11/2015 00:27, glen herrmannsfeldt wrote:
> James Kuyper <jameskuyper@verizon.net> wrote:
>> On 11/18/2015 06:16 PM, glen herrmannsfeldt wrote:
>>> Keith Thompson <kst-u@mib.org> wrote:
>
> (snip, I wrote)
>
>>>>> (I presume that *&2 still doesn't work.)
>
>>>> Correct. The operand of `&` must be an lvalue, which `2` isn't.
>>>> (It's not an object, so it doesn't have an address.)
>
> Just to be sure, I mean array, like:
>
> int array[10];
>
>>> The reason for that comment was wondering if *&array works
>>> when array is an array. Since array names aren't lvalue, it
>>> seems that they shouldn't allow for &.
>
>> "An identifier is a primary expression, provided it has been declared as
>> designating an object (in which case it is an lvalue) ..." (6.5.1p2). An
>> array name is an identifier, and it designates an object (namely, the
>> named array).
>
> int x[10], y[10];
> x=y; /* if x is an lvalue */
>
>> Are you thinking of the 6.3.2.1p3, which says "... an expression that
>> has type ‘‘array of type’’ is converted to an expression with type
>> ‘‘pointer to type’’ that points to the initial element of the array
>> object and is not an lvalue." ?
>
>> Keep in mind that those words are prefixed by "Except when it is the
>> operand of ... the unary & operator ...", so 6.3.2.1p3 doesn't apply to
>> this case.
>> *&array is an lvalue of array type referring to precisely the same
>> object as array itself.
>
> I am trying to remember cases where a * or & applied to some experession
> work the same as without the * or &.
>
> fp(x) and (*fp)(x) seem to mean the same thing.
Not only that, but if f is an actual function, then it can be called with:
(*f)();
While, if fp is a pointer to a function, it can be called with:
fp();
Just in case your code is in danger of becoming too obvious.
To round it off, you define your function pointers like this in regular
code:
void (*fp)();
but in a parameter list, you only need to say:
(void fp())
I think you can also write (void (*fp)()) to mean exactly the same
thing. (Why isn't 'void fp()' made into an error just to keep things
consistent? You tell me!)
When it comes to arrays, that's a whole subject, but there are some
parallels with functions. This is a value array in normal code:
int a[10];
but when part of a parameter list:
(int a[10])
this becomes a pointer to (to an int? What happens to the 10?). It
becomes very, very confusing. Unlike functions, array declarations in
parameter lists I think are one pointer level out of sync with the same
declaration anywhere else. Function pointers I believe are equivalent
aside from the special case above.
(This is why, when I generate C code, I refuse to go along with all
these arcane rules and special cases, and try and impose my own idea of
a type system.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-20 02:24 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <lnpoz5dl4m.fsf@kst-u.example.com> |
| In reply to | #76471 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
[...]
> I am trying to remember cases where a * or & applied to some experession
> work the same as without the * or &.
I believe the only such cases involve function designators.
An expression of type FOO is implicitly converted to FOO* only if FOO is
a function type. If FOO is an array type, then the conversion is to a
pointer to the element type.
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-11-20 15:07 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n2nd05$6nv$1@speranza.aioe.org> |
| In reply to | #76613 |
Keith Thompson <kst-u@mib.org> wrote: (snip, I wrote) >> I am trying to remember cases where a * or & applied to some experession >> work the same as without the * or &. > I believe the only such cases involve function designators. > An expression of type FOO is implicitly converted to FOO* only if FOO is > a function type. If FOO is an array type, then the conversion is to a > pointer to the element type. Maybe I am remembering K&R days. For K&R was array == &array? -- glen
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-11-20 10:19 -0500 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n2ndhj$2dh$1@dont-email.me> |
| In reply to | #76636 |
On 11/20/2015 10:07 AM, glen herrmannsfeldt wrote:
> Keith Thompson <kst-u@mib.org> wrote:
>
> (snip, I wrote)
>
>>> I am trying to remember cases where a * or & applied to some experession
>>> work the same as without the * or &.
>
>> I believe the only such cases involve function designators.
>
>> An expression of type FOO is implicitly converted to FOO* only if FOO is
>> a function type. If FOO is an array type, then the conversion is to a
>> pointer to the element type.
>
> Maybe I am remembering K&R days.
>
> For K&R was array == &array?
Indeterminate. K&R's description of the "==" operator is rather
brief, and doesn't mention what happens when it's applied to two
pointers of different types.
The two expressions were, however, of different types:
If the type of the identifier is "array of ...", however,
then the value of the identifier-expression is a pointer
to the first object in the array, and the type of the
expression is "pointer to ...".
-- K&R Classic, A.7.1
The result of the unary & operaator is a pointer to the
object referred to by the lvalue. If the type of the
lvalue is "...", the type of the result is "pointer to ...".
-- K&R Classic, A.7.2
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-11-23 00:06 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <MPG.30bc68e2bb9b935ba5@news.eternal-september.org> |
| In reply to | #76640 |
Eric Sosman wrote: > glen herrmannsfeldt wrote: > > Keith Thompson wrote: > > > > (snip, I wrote) > > > >>> I am trying to remember cases where a * or & applied to some experession > >>> work the same as without the * or &. > > > >> I believe the only such cases involve function designators. > > > >> An expression of type FOO is implicitly converted to FOO* only if FOO is > >> a function type. If FOO is an array type, then the conversion is to a > >> pointer to the element type. > > > > Maybe I am remembering K&R days. > > > > For K&R was array == &array? > > Indeterminate. K&R's description of the "==" operator is rather > brief, and doesn't mention what happens when it's applied to two > pointers of different types. > > The two expressions were, however, of different types: > > If the type of the identifier is "array of ...", however, > then the value of the identifier-expression is a pointer > to the first object in the array, and the type of the > expression is "pointer to ...". > -- K&R Classic, A.7.1 > > The result of the unary & operaator is a pointer to the > object referred to by the lvalue. If the type of the > lvalue is "...", the type of the result is "pointer to ...". > -- K&R Classic, A.7.2 No, actually &array is not allowed in K&R C. Section 5.3 says "an array name is a constant ... p=&a [is] illegal." A.7.1, right after the sentence you quoted, says, "an array identifier is not an lvalue expression." A.7.2 says that & can only be applied to an lvalue. (It doesn't say it in so many words, but it is clear from the text, including, for example, in the sentence you quoted.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-18 16:21 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <87ziybwa6f.fsf@bsb.me.uk> |
| In reply to | #76395 |
James Kuyper <jameskuyper@verizon.net> writes: > On 11/18/2015 03:14 AM, glen herrmannsfeldt wrote: >> Keith Thompson <kst-u@mib.org> wrote: >> >> (snip on . and ->) >> (then I wrote) >>>> Somehow this is reminding me of the case for function pointers, >>>> though I haven't used them for a while. >> >>>> If you have an: >> >>>> double (*fp)(); /* function pointer */ >> >>>> and assign it to point to a function. >> >>>> fp=sqrt; >> >>>> do you call it with (*fp)(2.0) or fp(2.0)? >> >>> Either is correct. >> >> Is one more correct? Seems to me that they should be different, >> in the same way that . and -> are different. > > It used to be that you needed to have an expression with function type > in order to call a function, so fp(2.0) would have been a constraint > violation, and (*fp)(2.0) was the correct way to use a function pointer. > However, in C99 the rules were changed. It's older than that -- it was changed in C90. Only K&R C needed the * to call though a pointer. In C90 and above, all calls are "as if" though a pointer by making function designators "decay" to pointers like arrays do. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-11-18 13:29 -0500 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <564CC36D.7030205@verizon.net> |
| In reply to | #76409 |
On 11/18/2015 11:21 AM, Ben Bacarisse wrote: > James Kuyper <jameskuyper@verizon.net> writes: ... >> It used to be that you needed to have an expression with function type >> in order to call a function, so fp(2.0) would have been a constraint >> violation, and (*fp)(2.0) was the correct way to use a function pointer. >> However, in C99 the rules were changed. > > It's older than that -- it was changed in C90. Only K&R C needed the * > to call though a pointer. In C90 and above, all calls are "as if" > though a pointer by making function designators "decay" to pointers like > arrays do. I'll take your word for it, since I don't have a copy of the C90 standard to check, but I'm surprised, because I don't remember becoming aware of this feature until the same time I became aware of the C99 draft standard.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-18 22:00 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <87a8qbvug9.fsf@bsb.me.uk> |
| In reply to | #76435 |
James Kuyper <jameskuyper@verizon.net> writes: > On 11/18/2015 11:21 AM, Ben Bacarisse wrote: >> James Kuyper <jameskuyper@verizon.net> writes: > ... >>> It used to be that you needed to have an expression with function type >>> in order to call a function, so fp(2.0) would have been a constraint >>> violation, and (*fp)(2.0) was the correct way to use a function pointer. >>> However, in C99 the rules were changed. >> >> It's older than that -- it was changed in C90. Only K&R C needed the * >> to call though a pointer. In C90 and above, all calls are "as if" >> though a pointer by making function designators "decay" to pointers like >> arrays do. > > I'll take your word for it, since I don't have a copy of the C90 > standard to check, I don't either but if you know the text in question you can search Google Books for snippets from Herbert Schildt's book -- a book that includes the text of the 1990 standard. Ages ago I converted (not very well) the text file[1] purporting to be a late draft of ANSI C into HTML[2]. Using that and the above book I can confirm that the same words are indeed in the standard. > but I'm surprised, because I don't remember becoming > aware of this feature until the same time I became aware of the C99 > draft standard. It's easy to miss since the old (*f)(...) still works just fine. Similarly, the old fun_ptr = &function also still works. I remember just coming across it by accident but I don't remember when. It was long after 1990 though. [1] http://www.bsb.me.uk/ansi-c/ansi-c.txt [2] http://www.bsb.me.uk/ansi-c/ansi-c-one-file.html -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-11-18 17:33 -0500 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n2iu7b$ie4$1@dont-email.me> |
| In reply to | #76463 |
On 11/18/2015 5:00 PM, Ben Bacarisse wrote:
> [... When did "funcptr()" become the same as "(*funcptr)()" ...]
> It's easy to miss since the old (*f)(...) still works just fine.
> Similarly, the old fun_ptr = &function also still works. I remember
> just coming across it by accident but I don't remember when. It was
> long after 1990 though.
I don't have the actual C89 or C90 Standards, but a text file
thought to be a draft of C89 describes the equivalence of fp()
and (*fp)(). It's also mentioned in the Rationale (6.5.2.2), which
discusses the multiplicity of ways to call a function, and says
that (emphasis mine) "The *C89* Committee saw no real harm in
allowing these forms ..."
So, the equivalence certainly predates C99.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-11-20 15:38 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <kfnd1v48cms.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #76464 |
Eric Sosman <esosman@comcast-dot-net.invalid> writes:
> From: Eric Sosman <esosman@comcast-dot-net.invalid>(/*gp*/)
> Subject: Re: One over another: (*structp).component structp->component
> Newsgroups: comp.lang.c
> Date: Wed, 18 Nov 2015 17:33:23 -0500
>
> On 11/18/2015 5:00 PM, Ben Bacarisse wrote:
>> [... When did "funcptr()" become the same as "(*funcptr)()" ...]
>> It's easy to miss since the old (*f)(...) still works just fine.
>> Similarly, the old fun_ptr = &function also still works. I remember
>> just coming across it by accident but I don't remember when. It was
>> long after 1990 though.
>
> I don't have the actual C89 or C90 Standards, but a text file
> thought to be a draft of C89 describes the equivalence of fp()
> and (*fp)(). It's also mentioned in the Rationale (6.5.2.2), which
> discusses the multiplicity of ways to call a function, and says
> that (emphasis mine) "The *C89* Committee saw no real harm in
> allowing these forms ..."
And there are a few other ways that one could check:
1. There is this document online
http://home.datacomm.ch/t_wolf/tw/c/c9x_changes.html
that details all changes between C90 and C99.
2. At the start of the C99 standard there is a list of changes
made since C90. That isn't conclusive since it doesn't list
absolutely everything, but for something this significant it's a
pretty good indicator.
3. If nothing else, try it out using 'gcc -ansi -pedantic'.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-11-18 23:23 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n2j1af$jqe$1@speranza.aioe.org> |
| In reply to | #76463 |
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: (snip) > It's easy to miss since the old (*f)(...) still works just fine. > Similarly, the old fun_ptr = &function also still works. I remember > just coming across it by accident but I don't remember when. It was > long after 1990 though. This is the one I also forgot ... Was it always fun_ptr = &function? And then fun_ptr = function with C90? -- glen
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-19 00:12 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <874mgix2x2.fsf@bsb.me.uk> |
| In reply to | #76468 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > > (snip) > >> It's easy to miss since the old (*f)(...) still works just fine. >> Similarly, the old fun_ptr = &function also still works. I remember >> just coming across it by accident but I don't remember when. It was >> long after 1990 though. > > This is the one I also forgot ... > > Was it always fun_ptr = &function? I'm not sure but I expect there was a transition with compilers trying out the new semantics, but of all the C90 changes, this one was more committee-driven than others that came from experiments like C++ and enhanced compilers. > And then fun_ptr = function with C90? Though the old &function works just as well. Function designators "decay" to pointers but not when they are the operand of &. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-11-12 09:00 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n21kfh$nn5$1@speranza.aioe.org> |
| In reply to | #75774 |
BartC <bc@freeuk.com> wrote: > On 11/11/2015 16:43, Keith Thompson wrote: >> BartC <bc@freeuk.com> writes: (snip) >> If you don't like making "." act like "->", you're not alone; I don't >> particularly like it myself. But your idea that it would obviously be >> extended to multiple levels is not a valid argument. A C-like language >> could easily spell "->" as "." with no ambiguity *and make no other >> changes*. You are inventing a problem that does not exist. Personally, 40 years ago I probably would have done it, but a little late now. > One of the problems is if you see, for example: > (**p).m > you can't tell if you can rewrite that as (*p).m, or whether that > reduction has already been done. Not without having to hunt down the > declarations of everything involved. There are lots of things you can't do without seeing the declarations. > Another problem, although some may not see it as one, is that if p is a > struct and you have: > p.m > then p is changed to a pointer to the struct, then no changes are needed > to p.m. > But not you find you need a pointer to pointer, and /now/ it needs > changing to (*p).m. I don't think using "->" in this case will work, as > one elimination of a pointer has already been done. Just as something can't be both a struct and pointer at the same time, it also can't be a pointer to struct and pointer to pointer to struct at the same time. The compiler will be able to figure it out. For comparison, note that Java uses . with object references. Java has nothing like a struct that isn't referenced though an object reference, though you do have to remember that this is an object reference. For another comparison, note that PL/I allows one to omit structure qualifiers if the result isn't ambiguous. That is, if the actual reference is a.b.c, you can say a.c or b.c or c, as long as there are no other valid, and so ambiguous, structures. Also, PL/I allows one to move subscripts around on structure references, so you can write a(i).b(j).c(k) as a.b.c(i,j,k), in addition to the above partial qualification. As I understand it, this feature comes from COBOL which allows only one dimensional arrays for each level of structure. You declare a(i).b(j).c(k), but then reference it as a.b.c(i,j,k). > It all seems very untidy to me, especially if it's possible to write > (*p).m, p->m or p.m at the same time. (Currently (*p).m and p->m can be > used at the same time, but you can see here that they are equivalent. > You can't with the new proposal.) But the compiler will know. -- glen
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-12 10:12 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n21ois$hi4$1@dont-email.me> |
| In reply to | #75807 |
On 12/11/2015 09:00, glen herrmannsfeldt wrote: > BartC <bc@freeuk.com> wrote: >> Another problem, although some may not see it as one, is that if p is a >> struct and you have: > >> p.m > >> then p is changed to a pointer to the struct, then no changes are needed >> to p.m. > >> But[now] you find you need a pointer to pointer, and /now/ it needs >> changing to (*p).m. I don't think using "->" in this case will work, as >> one elimination of a pointer has already been done. > > Just as something can't be both a struct and pointer at the same time, > it also can't be a pointer to struct and pointer to pointer to struct > at the same time. The compiler will be able to figure it out. The compiler might (although it would be able to pick up fewer errors), but it's us humans who will have more of a problem. > For comparison, note that Java uses . with object references. > Java has nothing like a struct that isn't referenced though an > object reference, though you do have to remember that this is an > object reference. I think that's a more acceptable way of eliminating these explicit dereferences (whatever Ben might say, if it means not having to write "*" or "->", then you've eliminated them). That is, by having a data type that doesn't need dereferencing. Java calls them references, I (in one of my languages), use the term 'handle'. In this case what pointer operations may or may not be needed happen behind the scenes, and after a while you forget about them completely. That works because the pointers have been eliminated at 'both ends'. In C, you will still need explicit pointer declarations at one end, but can optionally leave out the dereference at the other. > For another comparison, note that PL/I allows one to omit > structure qualifiers if the result isn't ambiguous. That is, > if the actual reference is a.b.c, you can say a.c or b.c or c, > as long as there are no other valid, and so ambiguous, structures. > > Also, PL/I allows one to move subscripts around on structure > references, so you can write a(i).b(j).c(k) as a.b.c(i,j,k), Is there anything that PL/I /doesn't/ allow? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-11 17:31 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <87fv0cl9wy.fsf@bsb.me.uk> |
| In reply to | #75731 |
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. > then surely, using the same arguments for > doing so, you would want the latter to become p.m. Yes, that would be the natural way to do that translation, but that was not the proposal, only your incorrect interpretation of it. I accept that you may have been originally confused by a bad or ambiguous description from me, but I clarified several times so I think your misunderstanding is deliberate. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web