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 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-10 21:04 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1tlvt$vva$1@dont-email.me> |
| In reply to | #75645 |
On 10/11/2015 18:04, Richard Heathfield wrote: > On 10/11/15 17:28, BartC wrote: >> Since that's my opinion, it can't be wrong. Not until I change my mind. > > That you hold the opinion is not in dispute. If you say it's your > opinion, I believe you. But if your opinion is in conflict with a > verifiable fact, then it is reasonable to say that your opinion is wrong. > > Whether . and -> are operators in the C language is not a matter of > opinion, but a matter of verifiable fact. The C language is defined by > an international standard which makes it very clear that . and -> are > operators in that language. See, for example, 6.5.2.3 (Structure and > union members) - Constraint 1: "The first operand of the . operator..." > and Constraint 2: "The first operand of the -> operator..." > > Clearly, then, . and -> are operators. There are other languages than C. Many will have equivalents to "?:", "()", "." and "->". Probably not all will call those 'operators'. It would be ludicrous to have "." an operator in one language but not another, when it does the same thing, depending on what the authors of the language reference manual decided to use. >> If you'd had to implement this stuff many times as I have, you might >> have discovered that treating "." as operator just like "+"doesn't >> really work. > > Well, it wouldn't. They do different things. I don't mean that they're different like "+" and "-" are different. Internally, "." and "+" need quite different approaches. > If you choose to think of the . and -> operators as something other than > operators, that's up to you, but don't be too surprised when people laugh. Well, it'll be my turn to laugh when they try and fail to implement "->" the same way they would do multiply. >> The standard also considers the parentheses in a function call such as >> f(a,b,c) to be an operator. I don't think of () in that context as an >> operator idea; I think many other people would have a problem with that >> too. > > It's perfectly reasonable to think of function-call () as an operator, > with a pointer-to-function (eg the function's name) as one operand and > the parameter list as a separate, possibly empty set of other operands. Yeah, function calls in C, and unary or binary operators, are pretty much the same thing, apart from a few little details: * The syntax is completely different * Functions can take any number of operands * Functions can pass control to your own code unlike operators * Operand overloading takes place with operators unlike functions * It is possible to have a pointer to a function but not an operator * Operators usually yield a value, functions need not * The (...) function 'operator' also has a few moonlighting jobs: enclosing function parameters, controlling evaluation order in an expression, enclosing conditions for if and while, and enclosing the controlling expressions of a for-loop. The C standard can of course use 'operator' to mean pretty much anything that separates out different parts of an expression, but conflating different aspects of a language like that isn't always useful. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-10 13:31 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <ln37wdtubr.fsf@kst-u.example.com> |
| In reply to | #75671 |
BartC <bc@freeuk.com> writes:
> On 10/11/2015 18:04, Richard Heathfield wrote:
[...]
>> Clearly, then, . and -> are operators.
>
> There are other languages than C.
And there are other newsgroups than comp.lang.c.
> Many will have equivalents to "?:",
> "()", "." and "->". Probably not all will call those 'operators'.
Agreed.
> It would be ludicrous to have "." an operator in one language but not
> another, when it does the same thing, depending on what the authors of
> the language reference manual decided to use.
If a language has a standard that clearly defines what an "operator"
is, it would be ludicrous to use your own meaning of the word when
discussing that language.
I'm not aware of any universal definition of "operator", and I don't see
anything seriously wrong with the way the C standard uses the word.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-10 22:15 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1tq5p$h7h$1@dont-email.me> |
| In reply to | #75671 |
On 10/11/15 21:04, BartC wrote: > On 10/11/2015 18:04, Richard Heathfield wrote: <snip> >> See, for example, 6.5.2.3 (Structure and >> union members) - Constraint 1: "The first operand of the . operator..." >> and Constraint 2: "The first operand of the -> operator..." >> >> Clearly, then, . and -> are operators. > > There are other languages than C. Many will have equivalents to "?:", > "()", "." and "->". Probably not all will call those 'operators'. Perhaps not, but that's beside the point. Here, we discuss C, and in C they are most definitely operators. > It would be ludicrous to have "." an operator in one language but not > another, when it does the same thing, depending on what the authors of > the language reference manual decided to use. No, that's not ludicrous at all, or at least certainly not so ludicrous as to be unbelievable. Differences in naming are rife in computing: ENTER vs RETURN, newline vs line feed, caret vs cursor, hash vs pound, function vs procedure vs subroutine... Put it down to the extraordinarily diverse and creative nature of the human spirit. >>> If you'd had to implement this stuff many times as I have, you might >>> have discovered that treating "." as operator just like "+"doesn't >>> really work. >> >> Well, it wouldn't. They do different things. > > I don't mean that they're different like "+" and "-" are different. > Internally, "." and "+" need quite different approaches. I would imagine that, internally, "+" and "=" need quite different approaches too. I don't see that as a reason to call one of them an operator but the other one something different. >> If you choose to think of the . and -> operators as something other than >> operators, that's up to you, but don't be too surprised when people >> laugh. > > Well, it'll be my turn to laugh when they try and fail to implement "->" > the same way they would do multiply. You might have to wait a while, since "they" have already implemented "->" quite satisfactorily. <snip> > Yeah, function calls in C, and unary or binary operators, are pretty > much the same thing, apart from a few little details: > > * The syntax is completely different There is no consistency of syntax in C operators. The syntax for = is different to that of ?:, the syntax of sizeof differs from that of %, and the syntax of * even differs from that of *! So syntactic similarity is clearly not a requirement for operators in general, and there's nothing special in that regard about the function call operator. > * Functions can take any number of operands It's a comma-separated list. So what? It's rather more logical than * having a different number of operands to *, isn't it? > * Functions can pass control to your own code unlike operators Well, the function-call operator can pass control to your own code, at any rate, which shows that there is at least one operator that *can* pass control to your own code. > * Operand overloading takes place with operators unlike functions We're talking about the function call operator, not functions. Do you mean "operator overloading" (in a rather limited fashion compared to some languages), as in 4 + 2 and 4.0 + 2.0 both being legal? If so, try sqrt(4.0) and sqrt(4), and you'll see that the function call operator does actually have roughly the same amount of overloading as +. > * It is possible to have a pointer to a function but not an operator It is not, however, possible to have a pointer to a function-call operator. In this respect as well, the function-call operator is like other operators. > * Operators usually yield a value, functions need not Nobody is trying to argue that functions are operators. The operator in question is the function call operator, which yields the value (if any) returned by the function. > * The (...) function 'operator' also has a few moonlighting jobs: > enclosing function parameters, ?: encloses one of its operands too. And so does []. So what? > controlling evaluation order in an expression, I think you'll find that evaluation order is unspecified. > enclosing conditions for if and while, and enclosing the > controlling expressions of a for-loop. Citation needed - please show where the Standard requires this. > The C standard can of course use 'operator' to mean pretty much anything > that separates out different parts of an expression, but conflating > different aspects of a language like that isn't always useful. And likewise, you can of course use any terms you like to describe pretty much anything you like, but in a C newsgroup the decision to use terms in a way different to everybody else is likely to cause confusion, to nobody's advantage. -- 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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-10 23:33 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1tuon$5vs$1@dont-email.me> |
| In reply to | #75688 |
On 10/11/2015 22:15, Richard Heathfield wrote: > On 10/11/15 21:04, BartC wrote: >> * Operand overloading takes place with operators unlike functions > > We're talking about the function call operator, not functions. Do you > mean "operator overloading" (in a rather limited fashion compared to > some languages), as in 4 + 2 and 4.0 + 2.0 both being legal? If so, try > sqrt(4.0) and sqrt(4), and you'll see that the function call operator > does actually have roughly the same amount of overloading as +. (That latter example isn't overloading (it's promotion).) >> The C standard can of course use 'operator' to mean pretty much anything >> that separates out different parts of an expression, but conflating >> different aspects of a language like that isn't always useful. > > And likewise, you can of course use any terms you like to describe > pretty much anything you like, but in a C newsgroup the decision to use > terms in a way different to everybody else is likely to cause confusion, > to nobody's advantage. 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). This I didn't like the sound of, and it was all the fault of the Standard calling "." an operator! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-10 23:59 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1u09d$amh$1@dont-email.me> |
| In reply to | #75697 |
On 10/11/15 23:33, BartC wrote: > On 10/11/2015 22:15, Richard Heathfield wrote: >> On 10/11/15 21:04, BartC wrote: > >>> * Operand overloading takes place with operators unlike functions >> >> We're talking about the function call operator, not functions. Do you >> mean "operator overloading" (in a rather limited fashion compared to >> some languages), as in 4 + 2 and 4.0 + 2.0 both being legal? If so, try >> sqrt(4.0) and sqrt(4), and you'll see that the function call operator >> does actually have roughly the same amount of overloading as +. > > (That latter example isn't overloading (it's promotion).) Okay, so what /do/ you mean? >>> The C standard can of course use 'operator' to mean pretty much anything >>> that separates out different parts of an expression, but conflating >>> different aspects of a language like that isn't always useful. >> >> And likewise, you can of course use any terms you like to describe >> pretty much anything you like, but in a C newsgroup the decision to use >> terms in a way different to everybody else is likely to cause confusion, >> to nobody's advantage. > > This sub-thread started with a discussion of operators "*" (dereference) > followed by "." being replaced by just "." instead of "->". (...which is a daft idea, as it blurs a very important distinction between structures and pointers.) > > 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). That doesn't look like a justification to me. It looks more like a good way to make programs harder to read. > This I didn't like the sound of, and it was all the fault of the > Standard calling "." an operator! Nope. The discussion didn't change the language, so nothing got broken, so there is no fault to be assigned to anyone or anything. -- 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-11 10:46 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <878u64n78r.fsf@bsb.me.uk> |
| In reply to | #75697 |
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. > This I didn't like the sound of, and it was all the fault of the > Standard calling "." an operator! You don't like the idea of operator overloading? C uses it a lot. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-11 11:01 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1v72v$k6r$1@dont-email.me> |
| In reply to | #75729 |
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, then surely, using the same arguments for doing so, you would want the latter to become p.m. It would be inconsistent otherwise. And those arguments could probably also be applied to (*A)[i] becoming A[i], and (*f)(a,b) becoming f(a,b). We've practically eliminated explicit derefs from the language! (Not a bad idea for the next language up, but not in this one IMO.) >> This I didn't like the sound of, and it was all the fault of the >> Standard calling "." an operator! > > You don't like the idea of operator overloading? C uses it a lot. No it was *. becoming . I didn't like, as I've sort of explained above. Not that I'm that fond of operator overloading! (I think it belongs tucked away into the language.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-11 08:43 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <lnlha4sczj.fsf@kst-u.example.com> |
| 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, then surely, using the same arguments for doing
> so, you would want the latter to become p.m.
>
> It would be inconsistent otherwise. And those arguments could probably
> also be applied to (*A)[i] becoming A[i], and (*f)(a,b) becoming f(a,b).
I don't see it as a "natural consequence" at all. In existing languages
that permit the prefix of "." to be either a structure or a pointer to a
structure, this does not extend to a pointer to a pointer to a structure
(in any case I'm familiar with), and nobody advocates making it work to
arbitrary levels. Perhaps it's inconsistent in some sense, but that
inconsistency has not been a problem.
> We've practically eliminated explicit derefs from the language! (Not a
> bad idea for the next language up, but not in this one IMO.)
Nobody suggested that.
>>> This I didn't like the sound of, and it was all the fault of the
>>> Standard calling "." an operator!
>>
>> You don't like the idea of operator overloading? C uses it a lot.
>
> No it was *. becoming . I didn't like, as I've sort of explained above.
> Not that I'm that fond of operator overloading! (I think it belongs
> tucked away into the language.)
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.
--
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-11 16:58 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n1vruu$6ef$1@dont-email.me> |
| In reply to | #75766 |
On 11/11/2015 16:43, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> No it was *. becoming . I didn't like, as I've sort of explained above. >> Not that I'm that fond of operator overloading! (I think it belongs >> tucked away into the language.) > > 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. 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. 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. 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.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-11 09:14 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <0a2f46e2-0de1-4c7e-964b-37a649091ebe@googlegroups.com> |
| In reply to | #75774 |
On Wednesday, November 11, 2015 at 10:58:25 AM UTC-6, Bart 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. Semantically, changing "p" from a struct to a pointer to a struct will change the *meaning* of p.m unless nothing ever writes to p.m; while there could be some advantages to being able to designate members as allowing both forms of syntax for use in that situation, I don't think it should be explicit. Rather, I'd suggest that there may be usefulness to allowing a structure to designate one pointer-type field within it as a 'default pointer' and allow "->" to access members of the structure identified by that pointer, and "." to access members of the structure itself. That could work out rather nicely if, for example, one implemented a structure which combined a pointer and a size and wanted to be able to use it in code that had formerly just used the pointer. Making "->" and "." synonymous would interfere with such usage.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-11-18 00:47 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n2ghq8$6k3$1@speranza.aioe.org> |
| In reply to | #75777 |
supercat@casperkitty.com wrote: (snip) > Semantically, changing "p" from a struct to a pointer to a struct will change > the *meaning* of p.m unless nothing ever writes to p.m; while there could > be some advantages to being able to designate members as allowing both forms > of syntax for use in that situation, I don't think it should be explicit. (snip) > Making "->" and "." synonymous would interfere with such usage. As far as I know, all compilers expect (*p).q or p->q with pointers, and r.q for non-pointers. 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)? note again, that the compiler knows the difference. For arrays, such as int x[10][10]; do you assign to a pointer (of appropriate type) with p=x; or p=&x; -- glen
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-18 04:12 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n2gtmu$6m1$1@dont-email.me> |
| In reply to | #76337 |
On 18/11/15 00:47, glen herrmannsfeldt wrote: > supercat@casperkitty.com wrote: > > (snip) > >> Semantically, changing "p" from a struct to a pointer to a struct will change >> the *meaning* of p.m unless nothing ever writes to p.m; while there could >> be some advantages to being able to designate members as allowing both forms >> of syntax for use in that situation, I don't think it should be explicit. > > (snip) > >> Making "->" and "." synonymous would interfere with such usage. > > As far as I know, all compilers expect (*p).q or p->q with pointers, > and r.q for non-pointers. Thankfully, a conforming implementation is required to make this distinction. > 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)? Personally, I call it with (*fp)(2.0). It is a lexical reminder to the reader that fp is a pointer-to-function, so there's no point in my grepping for double fp(double). > > note again, that the compiler knows the difference. > > For arrays, such as > > int x[10][10]; > > do you assign to a pointer (of appropriate type) with > > p=x; > > or > > p=&x; That would depend on whether p's "appropriate type" is "pointer to array of 10 int" or "pointer to array of 10 arrays of 10 int". -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-17 20:27 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <ln7flghqzf.fsf@kst-u.example.com> |
| In reply to | #76349 |
Richard Heathfield <rjh@cpax.org.uk> writes:
> On 18/11/15 00:47, glen herrmannsfeldt wrote:
[...]
>> If you have an:
>>
>> double (*fp)(); /* function pointer */
I'd write that as
double (*fp)(double);
>> and assign it to point to a function.
>>
>> fp=sqrt;
>>
>> do you call it with (*fp)(2.0) or fp(2.0)?
>
> Personally, I call it with (*fp)(2.0). It is a lexical reminder to the
> reader that fp is a pointer-to-function, so there's no point in my
> grepping for double fp(double).
I probably would too. I'm slightly troubled by the fact that the
expression `*fp` (which is of function type) is implicitly converted to
pointer-to-function type, but that's not enough to override the IMHO
added clarity of distinguishing between functions and function pointers.
[...]
--
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-18 08:11 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n2hbqt$kn0$1@speranza.aioe.org> |
| In reply to | #76352 |
Keith Thompson <kst-u@mib.org> wrote: (snip, I wrote) >>> If you have an: >>> double (*fp)(); /* function pointer */ > I'd write that as > double (*fp)(double); >>> and assign it to point to a function. >>> fp=sqrt; >>> do you call it with (*fp)(2.0) or fp(2.0)? >> Personally, I call it with (*fp)(2.0). It is a lexical reminder to the >> reader that fp is a pointer-to-function, so there's no point in my >> grepping for double fp(double). > I probably would too. I'm slightly troubled by the fact that the > expression `*fp` (which is of function type) is implicitly converted to > pointer-to-function type, but that's not enough to override the IMHO > added clarity of distinguishing between functions and function pointers. Just to be sure, are you saying what my examples show? It doesn't sound like I would have said it. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-17 20:14 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <lnfv04hrjy.fsf@kst-u.example.com> |
| In reply to | #76337 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> supercat@casperkitty.com wrote:
[...]
> As far as I know, all compilers expect (*p).q or p->q with pointers,
> and r.q for non-pointers.
By definition, all conforming C compilers do so. (A compiler could
accept p.q as an extension.)
> 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.
> For arrays, such as
>
> int x[10][10];
>
> do you assign to a pointer (of appropriate type) with
>
> p=x;
>
> or
>
> p=&x;
x and &x are of different types.
--
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-18 08:14 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n2hc1j$kun$1@speranza.aioe.org> |
| In reply to | #76350 |
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. >> For arrays, such as >> int x[10][10]; >> do you assign to a pointer (of appropriate type) with >> p=x; >> or >> p=&x; > x and &x are of different types. Is there an array case where two expressions work the same way, but one has a * or & that the other doesn't have? I thought so, but I don't remember which one it is. -- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-11-18 08:12 -0500 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n2htbm$8r8$1@dont-email.me> |
| In reply to | #76371 |
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. "A _function designator_ is an expression that has function type. Except when it is the operand of the sizeof operator, the _Alignof operator,65) or the unary & operator, a function designator with type ‘‘function returning type’’ is converted to an expression that has type ‘‘pointer to function returning type’’." (6.3.2.1p4) I use underscores to indicate that the first occurrence of "function designator" in that clause is in italics, an ISO convention indicating that this sentence serves as the definition for that phrase. If a function designator always gets converted into a pointer to function, how can you ever call it? You can call it because there was a corresponding change to the rule for function calls in C99: "The expression that denotes the called function shall have type pointer to function returning void or returning a complete object type other than an array type." (6.5.2.2p1) As a result, fp(2.0) is now directly supported, but (*fp)(2.0) also works, because of the implicit conversion to a pointer type. >>> For arrays, such as > >>> int x[10][10]; > >>> do you assign to a pointer (of appropriate type) with > >>> p=x; > >>> or > >>> p=&x; > >> x and &x are of different types. > > Is there an array case where two expressions work the same way, > but one has a * or & that the other doesn't have? > > I thought so, but I don't remember which one it is. Yes: "Except when it is the operand of the sizeof operator or the unary & operator, or is a string literal used to initialize an array, 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." (6.3.2.1p3) Therefore, array == &array[0]. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-11-18 14:33 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n2i28l$8lr$1@speranza.aioe.org> |
| In reply to | #76395 |
James Kuyper <jameskuyper@verizon.net> wrote: > 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 */ (snip) >>>> 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. > "A _function designator_ is an expression that has function type. Except > when it is the operand of the sizeof operator, the _Alignof operator,65) > or the unary & operator, a function designator with type ‘‘function > returning type’’ is converted to an expression that has type ‘‘pointer > to function returning type’’." (6.3.2.1p4) OK, this seems to say the opposite of what I thought it should say. > I use underscores to indicate that the first occurrence of "function > designator" in that clause is in italics, an ISO convention indicating > that this sentence serves as the definition for that phrase. > If a function designator always gets converted into a pointer to > function, how can you ever call it? You can call it because there was a > corresponding change to the rule for function calls in C99: Even more, how can you call f(x)? Doesn't that f (function, not pointer) get converted, too? > "The expression that denotes the called function shall have type pointer > to function returning void or returning a complete object type other > than an array type." (6.5.2.2p1) > As a result, fp(2.0) is now directly supported, but (*fp)(2.0) also > works, because of the implicit conversion to a pointer type. Seems to me what some people call bass-ackwards, but I suppose it works. (snip) >> Is there an array case where two expressions work the same way, >> but one has a * or & that the other doesn't have? >> I thought so, but I don't remember which one it is. > Yes: > "Except when it is the operand of the sizeof operator or the > unary & operator, or is a string literal used to initialize an array, 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." (6.3.2.1p3) > Therefore, array == &array[0]. OK, but I was thinking about where array == &array. Since I never write &array[0], but instead always array+0 (or + other value), I don't even know if that is (&array)[0] or &(array[0]). I know that &*array should work, but I don't know about *&array. (I presume that *&2 still doesn't work.) I thought there was a case where, similar to the function case, to equivalent expressions differed only in & or *, but not both. But then again, I have never tried to write one. I might not have used function pointers since I had a C99 compiler, and always use the (*fp)() form. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-18 09:05 -0800 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <lnwptffdan.fsf@kst-u.example.com> |
| In reply to | #76403 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> James Kuyper <jameskuyper@verizon.net> wrote:
[...]
>> If a function designator always gets converted into a pointer to
>> function, how can you ever call it? You can call it because there was a
>> corresponding change to the rule for function calls in C99:
It's already been pointed out that the change was in C89, not C99.
> Even more, how can you call f(x)?
>
> Doesn't that f (function, not pointer) get converted, too?
Yes, it does. The prefix of a function call must be a
pointer-to-function. The most common case is that it's a function name,
which is implicitly converted from function type to pointer-to-function
type. (That conversion is conceptual, and is unlikely to be visible in
the generated code.)
[...]
> (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.)
[...]
--
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-18 23:16 +0000 |
| Subject | Re: One over another: (*structp).component structp->component |
| Message-ID | <n2j0ss$ivk$1@speranza.aioe.org> |
| In reply to | #76424 |
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 &. -- glen
[toc] | [prev] | [next] | [standalone]
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web