Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #2800 > unrolled thread
| Started by | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| First post | 2011-03-29 12:27 -0500 |
| Last post | 2011-04-11 14:27 -0700 |
| Articles | 20 on this page of 404 — 24 participants |
Back to article view | Back to comp.lang.c++
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-03-29 12:27 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-03-30 00:03 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-03-30 12:39 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-03-30 20:42 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-03-31 12:38 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-03-31 19:28 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-01 12:40 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-02 02:33 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-04 12:42 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-04 20:12 +0100
Re: Problem with array objects cg_chas <cg_chas@hotmail.com> - 2011-04-04 16:31 -0400
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-05 12:39 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-05 19:13 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-05 20:16 +0100
Re: Problem with array objects Garrett Hartshaw <ghartshaw@gmail.com> - 2011-04-06 01:36 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-06 10:32 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-06 12:20 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-06 18:42 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-06 14:47 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-06 23:51 +0100
Re: Problem with array objects Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-07 09:44 +0200
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-07 12:28 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-07 21:39 +0100
Re: Problem with array objects cg_chas <cg_chas@hotmail.com> - 2011-04-07 18:16 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-08 01:14 +0100
Re: Problem with array objects cg_chas <cg_chas@hotmail.com> - 2011-04-07 23:03 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-08 08:48 +0100
Re: Problem with array objects cg_chas <cg_chas@hotmail.com> - 2011-04-08 04:15 -0400
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-08 12:39 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-08 21:04 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-09 13:15 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-09 20:32 +0100
Re: Problem with array objects cg_chas <cg_chas@hotmail.com> - 2011-04-09 22:05 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-10 03:44 +0100
Re: Problem with array objects cg_chas <cg_chas@hotmail.com> - 2011-04-09 23:07 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-10 13:32 +0100
Re: Problem with array objects cg_chas <cg_chas@hotmail.com> - 2011-04-10 10:15 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-10 18:29 +0100
Re: Problem with array objects cg_chas <cg_chas@hotmail.com> - 2011-04-10 17:55 -0400
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-11 12:40 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-11 22:07 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-12 12:51 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 19:53 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-13 12:32 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-14 14:02 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-14 12:53 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-14 19:17 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-15 12:25 -0500
Re: Problem with array objects gwowen <gwowen@gmail.com> - 2011-04-15 11:07 -0700
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-16 08:02 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 22:21 +0100
Re: Problem with array objects gwowen <gwowen@gmail.com> - 2011-04-15 14:22 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 23:01 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-16 10:10 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 23:24 +0100
Re: Problem with array objects drew@furrfu.invalid (Drew Lawson) - 2011-04-15 21:48 +0000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 23:16 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 19:05 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-18 12:44 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-18 21:35 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-19 13:46 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-20 17:29 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-23 12:59 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-23 20:31 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-24 09:26 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-24 00:04 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-24 11:24 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-24 02:16 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-24 14:10 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-24 04:37 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-24 16:11 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-24 13:31 +0100
Re: Problem with array objects Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-24 17:57 +0200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-24 17:39 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-25 10:19 +1200
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-25 10:12 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-25 00:46 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-25 11:59 +1200
Re: Problem with array objects "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-25 05:01 +0200
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-25 14:56 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-25 10:57 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-26 12:36 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-26 22:42 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-27 12:53 -0500
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-04-27 19:06 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-27 20:09 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-29 12:57 -0500
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-04-29 19:10 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-29 19:56 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-02 13:20 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-02 22:43 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-05 14:13 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-05 22:21 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-06 10:49 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-06 12:29 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-07 11:34 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-08 04:05 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-10 12:31 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-10 22:10 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-12 12:19 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-13 09:54 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-14 11:20 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-14 23:59 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-17 12:59 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-18 19:36 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-19 13:20 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-20 14:29 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-23 13:53 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-23 22:53 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-23 23:04 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-23 23:19 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-24 02:26 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-24 13:16 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-24 14:58 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-24 15:05 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-24 17:39 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-24 17:58 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-24 21:04 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-24 21:11 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 00:12 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-25 00:33 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 11:39 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-25 12:04 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 12:56 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-25 13:15 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 16:36 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-25 16:47 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 17:15 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-25 17:39 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 21:09 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-25 22:24 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 01:28 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-25 09:57 -0400
Re: Problem with array objects "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-05-25 16:50 +0200
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-25 12:01 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 16:59 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-25 12:56 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 21:46 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-25 20:02 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 01:37 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-26 09:08 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 15:19 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-26 14:45 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 21:02 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-27 09:34 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 14:46 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-27 15:07 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 21:42 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-27 19:34 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 01:24 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-28 10:58 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 19:41 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-28 20:38 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-29 12:32 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-29 10:05 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-29 20:13 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-29 19:38 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-30 17:01 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-31 09:45 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 20:33 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-06-01 09:57 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 15:53 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 16:46 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 19:44 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 19:59 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 21:41 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 22:10 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:39 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 23:21 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:32 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-06-01 12:33 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 19:18 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 19:38 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 20:10 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 20:18 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:01 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 22:25 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:43 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-06-02 09:49 +1200
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 23:27 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 00:26 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-02 00:33 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 08:52 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-06-01 15:37 -0400
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-06-02 07:46 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 21:22 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-01 10:31 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:10 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-06-02 09:28 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:59 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 15:05 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:35 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-06-02 10:51 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 00:28 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 16:33 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 09:03 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-02 01:23 -0700
Re: Problem with array objects Miles Bader <miles@gnu.org> - 2011-06-02 17:31 +0900
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-02 01:39 -0700
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-01 11:28 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:54 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-01 12:08 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:41 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 14:56 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:17 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:17 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 15:32 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:58 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 16:31 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 08:50 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 21:05 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-06-01 16:38 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:20 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 14:42 -0700
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-27 17:44 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 03:11 +0100
Re: Problem with array objects Öö Tiib <ootiib@hot.ee> - 2011-05-28 19:21 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-29 12:50 +0100
Re: Problem with array objects Öö Tiib <ootiib@hot.ee> - 2011-05-29 07:21 -0700
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-29 15:30 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-29 20:43 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-29 21:51 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 03:08 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-05-30 17:39 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 06:05 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-05-31 09:38 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 20:50 +0100
Re: Problem with array objects SG <s.gesemann@gmail.com> - 2011-05-31 02:23 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 13:29 +0100
Re: Problem with array objects "Fred Zwarts \(KVI\)" <F.Zwarts@KVI.nl> - 2011-05-31 15:17 +0200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 20:43 +0100
Re: Problem with array objects Michael Doubez <michael.doubez@free.fr> - 2011-05-31 02:43 -0700
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-31 14:38 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 20:45 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-31 21:11 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 10:23 +0100
Re: Problem with array objects gwowen <gwowen@gmail.com> - 2011-06-01 03:08 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 15:59 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 13:45 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 14:23 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 16:02 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 16:33 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 19:52 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 20:02 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-01 09:16 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 21:00 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-01 10:09 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:31 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-01 11:58 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:21 +0100
Re: Problem with array objects crisgoogle <crisd@telus.net> - 2011-06-01 16:22 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 00:48 +0100
Re: Problem with array objects crisgoogle <crisd@telus.net> - 2011-06-02 11:06 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 19:58 +0100
Re: Problem with array objects crisgoogle <crisd@telus.net> - 2011-06-02 13:28 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-03 01:16 +0100
Re: Problem with array objects crisgoogle <crisd@telus.net> - 2011-06-02 18:51 -0700
Re: Problem with array objects PaulR <pchristor@yahoo.co.uk> - 2011-06-03 04:59 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:21 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 14:46 -0700
Re: Problem with array objects Michael Doubez <michael.doubez@free.fr> - 2011-06-01 00:46 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-29 20:29 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-29 23:11 -0700
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-25 08:15 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-24 22:23 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-24 17:01 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 11:48 +0100
Re: Problem with array objects gwowen <gwowen@gmail.com> - 2011-05-25 04:06 -0700
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-25 13:50 -0700
Re: Problem with array objects "io_x" <a@b.c.invalid> - 2011-05-25 19:03 +0200
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-25 12:44 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 21:04 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-25 22:20 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 11:00 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-26 12:07 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 13:09 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-26 09:32 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 11:10 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-26 23:07 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 13:22 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-26 14:14 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 15:27 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-26 15:52 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 16:45 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-26 17:04 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 17:41 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-27 07:44 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 21:10 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-27 09:05 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 00:15 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-27 11:32 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 01:39 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 01:56 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-27 13:18 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 11:06 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-27 22:28 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 12:51 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-27 13:58 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 14:34 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-27 15:14 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-27 15:18 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 15:24 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-27 15:31 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 15:53 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-27 16:18 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 20:35 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-27 21:23 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 22:04 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-27 22:15 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 00:40 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 00:53 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 01:32 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 01:49 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-28 13:17 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 03:29 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-28 15:35 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 12:24 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-29 08:21 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 22:04 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-29 09:17 +1200
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-29 09:32 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 22:58 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-29 10:06 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 23:51 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 03:20 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 12:34 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 12:56 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 13:49 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 14:48 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 15:10 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 19:35 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 19:59 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 20:17 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 20:44 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 21:00 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 22:07 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-26 14:38 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 21:15 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-27 12:43 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 20:20 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-28 11:41 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 19:10 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-31 12:26 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 20:49 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-01 12:46 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 20:26 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-02 12:36 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 20:23 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-02 10:34 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-03 01:41 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-02 16:06 -1000
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-02 16:12 -1000
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-02 16:21 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-03 14:17 +0100
Re: Problem with array objects hanukas <jukka@liimatta.org> - 2011-06-04 10:34 -0700
Re: Problem with array objects hanukas <jukka@liimatta.org> - 2011-06-04 10:45 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-04 21:02 +0100
Re: Problem with array objects hanukas <jukka@liimatta.org> - 2011-06-04 14:11 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-04 22:35 +0100
Re: Problem with array objects hanukas <jukka@liimatta.org> - 2011-06-04 15:43 -0700
Re: Problem with array objects "io_x" <a@b.c.invalid> - 2011-06-05 06:39 +0200
Re: Problem with array objects "io_x" <a@b.c.invalid> - 2011-06-05 07:55 +0200
Re: Problem with array objects "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-06-03 11:14 +0200
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-06-03 21:08 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-03 14:25 +0100
Re: Problem with array objects hanukas <jukka@liimatta.org> - 2011-06-04 10:52 -0700
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-04 19:52 -0700
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-05 13:48 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-05 14:52 +0100
Re: Problem with array objects "Thomas J. Gritzan" <phygon_antispam@gmx.de> - 2011-06-05 18:03 +0200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-05 19:23 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-05 14:49 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-03 12:37 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-03 19:49 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-04 11:46 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-04 18:42 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-06 14:27 -0500
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-06 14:04 -0700
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-06 14:04 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-07 02:26 +0100
Re: Problem with array objects hanukas <jukka@liimatta.org> - 2011-06-06 23:30 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-07 13:13 +0100
Re: Problem with array objects hanukas <jukka@liimatta.org> - 2011-06-08 01:20 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-08 11:39 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-08 17:03 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-08 23:51 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-11 11:41 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-12 00:56 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-14 13:44 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-14 23:01 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-16 13:41 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-16 23:01 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-18 12:23 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-18 19:50 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-21 13:38 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-22 00:29 +0100
Re: Problem with array objects Keith H Duggar <duggar@alum.mit.edu> - 2011-06-18 12:58 -0700
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-21 13:40 -0500
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-10 15:56 -0700
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-11 12:25 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-11 10:56 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-11 14:09 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-12 13:31 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-04-11 14:27 -0700
Page 1 of 21 [1] 2 3 … 21 Next page →
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-03-29 12:27 -0500 |
| Subject | Re: Problem with array objects |
| Message-ID | <slrnip45kk.2kgi.aggedor@earl-grey.cloud9.net> |
On 2011-03-28, Paul <pchristor@yahoo.co.uk> wrote: > > "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message > news:slrnip1s22.1g5p.aggedor@earl-grey.cloud9.net... >> On 2011-03-28, Paul <pchristor@yahoo.co.uk> wrote: >> >> If the pointer to a 1-dimensional array of were the same type as a pointer >> to a single int, then given the declaration >> >> int *i, ai[4]; >> >> Then the following assignment of a pointer to a 1-dimensional array of int >> to a pointer to an int would be allowed >> >> i = &ai; > No this would yield a pointer type of a different level of indirection. Applying the unary & operator results in a pointer to its operand. In the example the operand (ai) is a 1-dimensional array, making the result of applying the & operator a pointer to a 1-dimensional array. >> >> but it is not allowed. > > When you take the address of something you introduce another level of > indirection. > int x =5; > int* px = &x; > int** ppx = &px; > int*** pppx = &ppx; > > If you try to take the address of an arrayobject you get a pointer type > which is different in levels of indirection. Right, taking the address of an array gives a pointer to the array. > int arr[6][6]; /*This is an array-object*/ > int (*parr)[6] = arr; /*This is a pointer to THE array*/ It is a pointer to the first element of an array of 6 int[6] elements. > int (*pparr)[6][6] = &arr; /*This is a pointer to an array-object*/ It is a pointer to a 2-dimensional (6 by 6) array of int. > std::cout<< arr << std::endl << parr << std::endl << pparr; > All point to the same thing. Right, the addresses are all the same value, but each pointer is a different type. If you increment parr, the byte address increases by 6*sizeof(int). If you increment pparr, the byte address increases by 6*6*sizeof(int). > Each identifier points to the same array, but they are different levels of > indirection. Each identifier points to the same address, but parr is a pointer to a 1-dimensional array and pparr is a pointer to a 2-dimensional array. > The same applies to 1dim arrays: > int arr[6]; /*array object*/ > int* parr= arr; /*pointer to THE array*/ It points to the first element of the array. When the initialization expression is evaluated, the standard array-to-pointer conversion occurs, resulting in a pointer to the first element of the array, not a pointer to the array. > int (*pparr) =&arr; /*pointer to array object*/ It is a pointer to a 1-dimensional array of 6 ints. > This C++ standard confirms, in section 8.3.4 para 7, that a dereferenced > array object is always (n-1) dimensions of the pointed to array. > If you don't accpet what's in the standards I don't know what more I can > say. I accept what is written in the C++ standard. In an earlier followup I gave an example where that paragraph applied. I also accept what is written in paragraph 1 of section 4.2: An lvalue or rvalue of type "array of N T" or "array of unknown bound of T" can be converted to an rvalue of type "pointer to T." The result is a pointer to the first element of the array. An example where the paragraph applies is the initialization expression in the second of the following two declarations. int arr[6]; int *parr = arr; According to the standard, the result of the conversion is a "pointer to the first element of the array" not a "pointer to the array".
[toc] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-30 00:03 +0100 |
| Message-ID | <eztkp.84$_c3.5@newsfe26.ams2> |
| In reply to | #2800 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message news:slrnip45kk.2kgi.aggedor@earl-grey.cloud9.net... > On 2011-03-28, Paul <pchristor@yahoo.co.uk> wrote: >> >> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message >> news:slrnip1s22.1g5p.aggedor@earl-grey.cloud9.net... >>> On 2011-03-28, Paul <pchristor@yahoo.co.uk> wrote: >>> >>> If the pointer to a 1-dimensional array of were the same type as a >>> pointer >>> to a single int, then given the declaration >>> >>> int *i, ai[4]; >>> >>> Then the following assignment of a pointer to a 1-dimensional array of >>> int >>> to a pointer to an int would be allowed >>> >>> i = &ai; >> No this would yield a pointer type of a different level of indirection. > > Applying the unary & operator results in a pointer to its operand. In the > example the operand (ai) is a 1-dimensional array, making the result of > applying the & operator a pointer to a 1-dimensional array. > Exactly what I said , you are making a pointer to the array object, its value is no different. It points to exactly the same place. >>> >>> but it is not allowed. >> >> When you take the address of something you introduce another level of >> indirection. >> int x =5; >> int* px = &x; >> int** ppx = &px; >> int*** pppx = &ppx; >> >> If you try to take the address of an arrayobject you get a pointer type >> which is different in levels of indirection. > > Right, taking the address of an array gives a pointer to the array. Yes but you don't seem to accept what I was explaining, that is..It introduces another level of indirection. > >> int arr[6][6]; /*This is an array-object*/ >> int (*parr)[6] = arr; /*This is a pointer to THE array*/ > > It is a pointer to the first element of an array of 6 int[6] elements. Its a pointer to the array, It can point to any part of the array becuase its an l-value. > >> int (*pparr)[6][6] = &arr; /*This is a pointer to an array-object*/ > > It is a pointer to a 2-dimensional (6 by 6) array of int. This is a different level of indirection. If I dereference this I get an array-object , not the actual array data. . > >> std::cout<< arr << std::endl << parr << std::endl << pparr; >> All point to the same thing. > > Right, the addresses are all the same value, but each pointer is a > different type. They all point to arrays of int-type. They are different levels of indirection. > If you increment parr, the byte address increases by > 6*sizeof(int). If you increment pparr, the byte address increases by > 6*6*sizeof(int). > >> Each identifier points to the same array, but they are different levels >> of >> indirection. > > Each identifier points to the same address, but parr is a pointer to a > 1-dimensional array and pparr is a pointer to a 2-dimensional array. No its not par is a pointer to THE array (the data that is the array), pparr is not: par[0][0]; /*returns array data*/ pparr[0][0] /*Is a complete pile of bollocks*/ > >> The same applies to 1dim arrays: >> int arr[6]; /*array object*/ >> int* parr= arr; /*pointer to THE array*/ > > It points to the first element of the array. When the initialization > expression is evaluated, the standard array-to-pointer conversion occurs, > resulting in a pointer to the first element of the array, not a pointer > to the array. What don't you understand about the fact that they all initially point to the same address? Why you seem to think that parr is some kind of r-value is beyond me, what don't you understand about the fact that it can point to any element of the array? > >> int (*pparr) =&arr; /*pointer to array object*/ > > It is a pointer to a 1-dimensional array of 6 ints. > >> This C++ standard confirms, in section 8.3.4 para 7, that a dereferenced >> array object is always (n-1) dimensions of the pointed to array. >> If you don't accpet what's in the standards I don't know what more I can >> say. > > I accept what is written in the C++ standard. In an earlier followup I > gave an example where that paragraph applied. I also accept what is > written in paragraph 1 of section 4.2: No you don't accept it , you said it wasn't relevant. > > An lvalue or rvalue of type "array of N T" or "array of unknown > bound of T" can be converted to an rvalue of type "pointer to T." > The result is a pointer to the first element of the array. > > An example where the paragraph applies is the initialization expression > in the second of the following two declarations. > > int arr[6]; > int *parr = arr; > > According to the standard, the result of the conversion is a "pointer to > the > first element of the array" not a "pointer to the array". Why do you think, with three pointers to exactly the same place, they point to different things? Its exactly the opposite of what you say because: int arr[6]; /*r-value , can only point to the first element*/ int* parr=arr; /*l-value , can point to any element*/ int (*pparr)[6] = &arr; /*l-value, can only point to 1st element or 1 past end.*/ You obviously have very strange ideas about pointers and arrays, I have already posted information about array types from experts and the C++ standard, if you refuse to accept this thats up to you. Please stop making statements as if they are statements of factual correctness that are actually wrong, particularly the one I quote: <quote> According to the standard, the result of the conversion is a "pointer to the first element of the array" not a "pointer to the array". </quote> This is a complete misinterpretation of the standards, and incorrect..
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-03-30 12:39 -0500 |
| Message-ID | <slrnip6qm7.14ro.aggedor@earl-grey.cloud9.net> |
| In reply to | #2808 |
On 2011-03-29, Paul <pchristor@yahoo.co.uk> wrote: > > "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message > news:slrnip45kk.2kgi.aggedor@earl-grey.cloud9.net... >> On 2011-03-28, Paul <pchristor@yahoo.co.uk> wrote: >>> int arr[6][6]; /*This is an array-object*/ >>> int (*parr)[6] = arr; /*This is a pointer to THE array*/ >>> int (*pparr)[6][6] = &arr; /*This is a pointer to an array-object*/ [snip] >> Each identifier points to the same address, but parr is a pointer to a >> 1-dimensional array and pparr is a pointer to a 2-dimensional array. > No its not par is a pointer to THE array (the data that is the array), pparr > is not: > par[0][0]; /*returns array data*/ > pparr[0][0] /*Is a complete pile of bollocks*/ I wrote: "pparr is a pointer to a 2-dimensional array". To get the same value that arr[0][0] gives, use the expression (*pparr)[0][0]. That is, dereference the pointer to the array before applying subscript operators. >>> The same applies to 1dim arrays: >>> int arr[6]; /*array object*/ >>> int* parr= arr; /*pointer to THE array*/ >> >> It points to the first element of the array. When the initialization >> expression is evaluated, the standard array-to-pointer conversion occurs, >> resulting in a pointer to the first element of the array, not a pointer >> to the array. > > What don't you understand about the fact that they all initially point to > the same address? I never stated that they didn't point to the same address. What I wrote was about the type of the expression arr. Your comment with the declaration was "pointer to THE array". I wrote that it was a pointer to the first element of the array, not a pointer to the array. In the example, the former is of type int* and the latter is of type int(*)[6]. > Why you seem to think that parr is some kind of r-value is beyond me, what > don't you understand about the fact that it can point to any element of the > array? I never stated that the value of parr is some king of rvalue. It is a non-const identifier. Its value can be changed to point to any int. [snip] >>> This C++ standard confirms, in section 8.3.4 para 7, that a dereferenced >>> array object is always (n-1) dimensions of the pointed to array. >>> If you don't accpet what's in the standards I don't know what more I can >>> say. >> >> I accept what is written in the C++ standard. In an earlier followup I >> gave an example where that paragraph applied. I also accept what is >> written in paragraph 1 of section 4.2: > No you don't accept it , you said it wasn't relevant. I wrote in a previous followup (message <slrnip1h84.1bkf.aggedor@earl-grey.cloud9.net>) that what your wrote about section 8.3.4 wasn't relevant to the declaration int *p = new int[4] because the declaration did not dereference an array. I accept the quote I posted from section 4.2 that you silently snipped. [snip] > Why do you think, with three pointers to exactly the same place, they point > to different things? > Its exactly the opposite of what you say because: > int arr[6]; /*r-value , can only point to the first element*/ > int* parr=arr; /*l-value , can point to any element*/ > int (*pparr)[6] = &arr; /*l-value, can only point to 1st element or 1 past > end.*/ They all initially point to the same address, but they have different types. arr has type array of 6 int. parr has type pointer to int. pparr has type pointer to array of 6 int. Incrementing parr adds sizeof(int) to the byte address. Incrementing pparr adds 6*sizeof(int) to the byte address > You obviously have very strange ideas about pointers and arrays, I have > already posted information about array types from experts and the C++ > standard, if you refuse to accept this thats up to you. Please stop making > statements as if they are statements of factual correctness that are > actually wrong, particularly the one I quote: ><quote> > According to the standard, the result of the conversion is a "pointer to the > first element of the array" not a "pointer to the array". ></quote> > This is a complete misinterpretation of the standards, and incorrect.. The ideas I have about pointers and arrays are from the standard. Here is paragraph 1 of section 4.2 of the standard (you silently snipped the copy that was in my previous post): An lvalue or rvalue of type "array of N T" or "array of unknown bound of T" can be converted to an rvalue of type "pointer to T." The result is a pointer to the first element of the array. A pointer to the first element of the array is not the same as a pointer to the array. The former has type pointer to T, that latter has type pointer to array of N T. If they were the same, given the declaration int *pi, (*pai)[1]; the assignment pi = pai; would be allowed, but it is not allowed.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-30 20:42 +0100 |
| Message-ID | <IINkp.4162$jo4.3034@newsfe03.ams2> |
| In reply to | #2858 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message news:slrnip6qm7.14ro.aggedor@earl-grey.cloud9.net... > On 2011-03-29, Paul <pchristor@yahoo.co.uk> wrote: >> >> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message >> news:slrnip45kk.2kgi.aggedor@earl-grey.cloud9.net... >>> On 2011-03-28, Paul <pchristor@yahoo.co.uk> wrote: >>>> int arr[6][6]; /*This is an array-object*/ >>>> int (*parr)[6] = arr; /*This is a pointer to THE array*/ >>>> int (*pparr)[6][6] = &arr; /*This is a pointer to an array-object*/ > [snip] >>> Each identifier points to the same address, but parr is a pointer to a >>> 1-dimensional array and pparr is a pointer to a 2-dimensional array. >> No its not par is a pointer to THE array (the data that is the array), >> pparr >> is not: >> par[0][0]; /*returns array data*/ >> pparr[0][0] /*Is a complete pile of bollocks*/ > > I wrote: "pparr is a pointer to a 2-dimensional array". To get the > same value that arr[0][0] gives, use the expression (*pparr)[0][0]. That > is, dereference the pointer to the array before applying subscript > operators. > >>>> The same applies to 1dim arrays: >>>> int arr[6]; /*array object*/ >>>> int* parr= arr; /*pointer to THE array*/ >>> >>> It points to the first element of the array. When the initialization >>> expression is evaluated, the standard array-to-pointer conversion >>> occurs, >>> resulting in a pointer to the first element of the array, not a pointer >>> to the array. >> >> What don't you understand about the fact that they all initially point to >> the same address? > > I never stated that they didn't point to the same address. What I wrote > was about the type of the expression arr. Your comment with the > declaration > was "pointer to THE array". I wrote that it was a pointer to the first > element of the array, not a pointer to the array. In the example, the > former is of type int* and the latter is of type int(*)[6]. > >> Why you seem to think that parr is some kind of r-value is beyond me, >> what >> don't you understand about the fact that it can point to any element of >> the >> array? > > I never stated that the value of parr is some king of rvalue. It is a > non-const identifier. Its value can be changed to point to any int. > You are a liar you have been constantly stating it doesn't point to the array and it only points to only the first element. > [snip] >>>> This C++ standard confirms, in section 8.3.4 para 7, that a >>>> dereferenced >>>> array object is always (n-1) dimensions of the pointed to array. >>>> If you don't accpet what's in the standards I don't know what more I >>>> can >>>> say. >>> >>> I accept what is written in the C++ standard. In an earlier followup I >>> gave an example where that paragraph applied. I also accept what is >>> written in paragraph 1 of section 4.2: >> No you don't accept it , you said it wasn't relevant. > > I wrote in a previous followup (message > <slrnip1h84.1bkf.aggedor@earl-grey.cloud9.net>) that what your wrote about > section 8.3.4 wasn't relevant to the declaration > > int *p = new int[4] > > because the declaration did not dereference an array. I accept the > quote I posted from section 4.2 that you silently snipped. > > [snip] As I said you are trying to say the standards are not relevant when they are. > >> Why do you think, with three pointers to exactly the same place, they >> point >> to different things? >> Its exactly the opposite of what you say because: >> int arr[6]; /*r-value , can only point to the first element*/ >> int* parr=arr; /*l-value , can point to any element*/ >> int (*pparr)[6] = &arr; /*l-value, can only point to 1st element or 1 >> past >> end.*/ > > They all initially point to the same address, but they have different > types. > arr has type array of 6 int. parr has type pointer to int. pparr has > type > pointer to array of 6 int. > They are all int types arr[6]; /* returns int */ *parr; /*returns int */ *pparr; /*returns int[], which decays to int* */ The third is simply another level of indirection. So why do you not understand the parr points to the array? > Incrementing parr adds sizeof(int) to the byte address. Incrementing > pparr > adds 6*sizeof(int) to the byte address > >> You obviously have very strange ideas about pointers and arrays, I have >> already posted information about array types from experts and the C++ >> standard, if you refuse to accept this thats up to you. Please stop >> making >> statements as if they are statements of factual correctness that are >> actually wrong, particularly the one I quote: >><quote> >> According to the standard, the result of the conversion is a "pointer to >> the >> first element of the array" not a "pointer to the array". >></quote> >> This is a complete misinterpretation of the standards, and incorrect.. > > The ideas I have about pointers and arrays are from the standard. Here > is paragraph 1 of section 4.2 of the standard (you silently snipped > the copy that was in my previous post): > > An lvalue or rvalue of type "array of N T" or "array of unknown > bound of T" can be converted to an rvalue of type "pointer to T." > The result is a pointer to the first element of the array. > > A pointer to the first element of the array is not the same as a pointer > to > the array. WHere does the standard state this? Or it this your addition to the standard? If it points to the first element *OF THE ARRAY* then, by definition , it points to the array. <snip>
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-03-31 12:38 -0500 |
| Message-ID | <slrnip9f0p.26bu.aggedor@earl-grey.cloud9.net> |
| In reply to | #2878 |
On 2011-03-30, Paul <pchristor@yahoo.co.uk> wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrnip6qm7.14ro.aggedor@earl-grey.cloud9.net...
>> On 2011-03-29, Paul <pchristor@yahoo.co.uk> wrote:
>>>
>>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>>> news:slrnip45kk.2kgi.aggedor@earl-grey.cloud9.net...
>>>> On 2011-03-28, Paul <pchristor@yahoo.co.uk> wrote:
[snip]
> You are a liar you have been constantly stating it doesn't point to the
> array and it only points to only the first element.
What I have been stating is that it, that is, an rvalue or lvalue of
type array of T that undergoes array-to-pointer conversion, results in
a pointer to T that points to the first element of the array. If that
is a lie, then section 4.2 of the C++ specification contains a lie.
It does not point the array because a pointer to an array is a
different type of pointer than a pointer to an element of the array.
(More on this difference later in this followup.)
>>>>> This C++ standard confirms, in section 8.3.4 para 7, that a
>>>>> dereferenced
>>>>> array object is always (n-1) dimensions of the pointed to array.
>>>>> If you don't accpet what's in the standards I don't know what more I
>>>>> can
>>>>> say.
>>>>
>>>> I accept what is written in the C++ standard. In an earlier followup I
>>>> gave an example where that paragraph applied. I also accept what is
>>>> written in paragraph 1 of section 4.2:
>>> No you don't accept it , you said it wasn't relevant.
>>
>> I wrote in a previous followup (message
>> <slrnip1h84.1bkf.aggedor@earl-grey.cloud9.net>) that what your wrote about
>> section 8.3.4 wasn't relevant to the declaration
>>
>> int *p = new int[4]
>>
>> because the declaration did not dereference an array. I accept the
>> quote I posted from section 4.2 that you silently snipped.
>>
>> [snip]
>
> As I said you are trying to say the standards are not relevant when they
> are.
How is a part of the C++ standard that is about dereferencing an
array relevant to a C++ statement in which there is no dereferencing
of an array?
>>> Why do you think, with three pointers to exactly the same place, they
>>> point
>>> to different things?
>>> Its exactly the opposite of what you say because:
>>> int arr[6]; /*r-value , can only point to the first element*/
>>> int* parr=arr; /*l-value , can point to any element*/
>>> int (*pparr)[6] = &arr; /*l-value, can only point to 1st element or 1
>>> past
>>> end.*/
>>
>> They all initially point to the same address, but they have different
>> types.
>> arr has type array of 6 int. parr has type pointer to int. pparr has
>> type
>> pointer to array of 6 int.
>>
> They are all int types
> arr[6]; /* returns int */
> *parr; /*returns int */
> *pparr; /*returns int[], which decays to int* */
> The third is simply another level of indirection.
It is the variables parr and pparr that are being initialized, not
the result of dereferencing them. Those variables have different
types: pointer to int and pointer to array of 6 int, respectively.
Neither of those variables is type int.
> So why do you not understand the parr points to the array?
parr is a pointer to an int; it has type int*. A pointer to an array of
int has of the form int(*)[]. parr does not point to the array because
its type is not that of a pointer to an array.
>> Incrementing parr adds sizeof(int) to the byte address. Incrementing
>> pparr
>> adds 6*sizeof(int) to the byte address
>>
>>> You obviously have very strange ideas about pointers and arrays, I have
>>> already posted information about array types from experts and the C++
>>> standard, if you refuse to accept this thats up to you. Please stop
>>> making
>>> statements as if they are statements of factual correctness that are
>>> actually wrong, particularly the one I quote:
>>><quote>
>>> According to the standard, the result of the conversion is a "pointer to
>>> the
>>> first element of the array" not a "pointer to the array".
>>></quote>
>>> This is a complete misinterpretation of the standards, and incorrect..
>>
>> The ideas I have about pointers and arrays are from the standard. Here
>> is paragraph 1 of section 4.2 of the standard (you silently snipped
>> the copy that was in my previous post):
>>
>> An lvalue or rvalue of type "array of N T" or "array of unknown
>> bound of T" can be converted to an rvalue of type "pointer to T."
>> The result is a pointer to the first element of the array.
>>
>> A pointer to the first element of the array is not the same as a pointer
>> to
>> the array.
> WHere does the standard state this? Or it this your addition to the
> standard?
I demonstrated why they are not the same in lines that you sliently
snipped at this point. Here are the snipped lines:
A pointer to the first element of the array is not the same as a pointer to
the array. The former has type pointer to T, that latter has type pointer
to array of N T. If they were the same, given the declaration
int *pi, (*pai)[1];
the assignment
pi = pai;
would be allowed, but it is not allowed.
The C++ standard allows the right operand of an assignment operator
to be implicitly converted to the type of the left operand. However,
converting from a pointer to an array of N T to a pointer to T is
not a conversion allowed by section 4 of the C++ standard, where
the implicit conversions are specified.
> If it points to the first element *OF THE ARRAY* then, by definition , it
> points to the array.
Such a definition ignores the fact that C++ pointers are typed. The
"it" that points is a pointer with a type. A pointer to an element of
an array and a pointer to an array are two different types of pointers.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-31 19:28 +0100 |
| Message-ID | <8J3lp.1091$9h6.223@newsfe02.ams2> |
| In reply to | #2932 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message news:slrnip9f0p.26bu.aggedor@earl-grey.cloud9.net... > On 2011-03-30, Paul <pchristor@yahoo.co.uk> wrote: >> >> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message >> news:slrnip6qm7.14ro.aggedor@earl-grey.cloud9.net... >>> On 2011-03-29, Paul <pchristor@yahoo.co.uk> wrote: >>>> >>>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message >>>> news:slrnip45kk.2kgi.aggedor@earl-grey.cloud9.net... >>>>> On 2011-03-28, Paul <pchristor@yahoo.co.uk> wrote: > [snip] > >> You are a liar you have been constantly stating it doesn't point to the >> array and it only points to only the first element. > > What I have been stating is that it, that is, an rvalue or lvalue of > type array of T that undergoes array-to-pointer conversion, results in > a pointer to T that points to the first element of the array. If that > is a lie, then section 4.2 of the C++ specification contains a lie. > You are saying it points to the initial element of an array, yet it doesn't point to the array. Which does not make sense. > It does not point the array because a pointer to an array is a > different type of pointer than a pointer to an element of the array. > (More on this difference later in this followup.) > See there you go again ^^^^^^. >>>>>> This C++ standard confirms, in section 8.3.4 para 7, that a >>>>>> dereferenced >>>>>> array object is always (n-1) dimensions of the pointed to array. >>>>>> If you don't accpet what's in the standards I don't know what more I >>>>>> can >>>>>> say. >>>>> >>>>> I accept what is written in the C++ standard. In an earlier followup >>>>> I >>>>> gave an example where that paragraph applied. I also accept what is >>>>> written in paragraph 1 of section 4.2: >>>> No you don't accept it , you said it wasn't relevant. >>> >>> I wrote in a previous followup (message >>> <slrnip1h84.1bkf.aggedor@earl-grey.cloud9.net>) that what your wrote >>> about >>> section 8.3.4 wasn't relevant to the declaration >>> >>> int *p = new int[4] >>> >>> because the declaration did not dereference an array. I accept the >>> quote I posted from section 4.2 that you silently snipped. >>> >>> [snip] >> >> As I said you are trying to say the standards are not relevant when they >> are. > > How is a part of the C++ standard that is about dereferencing an > array relevant to a C++ statement in which there is no dereferencing > of an array? Because it explains that when you derefernece an array it returns a pointed to (n-1) dimensional array. > >>>> Why do you think, with three pointers to exactly the same place, they >>>> point >>>> to different things? >>>> Its exactly the opposite of what you say because: >>>> int arr[6]; /*r-value , can only point to the first element*/ >>>> int* parr=arr; /*l-value , can point to any element*/ >>>> int (*pparr)[6] = &arr; /*l-value, can only point to 1st element or 1 >>>> past >>>> end.*/ >>> >>> They all initially point to the same address, but they have different >>> types. >>> arr has type array of 6 int. parr has type pointer to int. pparr has >>> type >>> pointer to array of 6 int. >>> >> They are all int types >> arr[6]; /* returns int */ >> *parr; /*returns int */ >> *pparr; /*returns int[], which decays to int* */ >> The third is simply another level of indirection. > > It is the variables parr and pparr that are being initialized, not > the result of dereferencing them. Those variables have different > types: pointer to int and pointer to array of 6 int, respectively. > Neither of those variables is type int. It doesn't matter if its TYPE is int*****. Its just a different level of indirection. The type of the array is INT. > >> So why do you not understand the parr points to the array? > > parr is a pointer to an int; it has type int*. A pointer to an array of > int has of the form int(*)[]. No you are wrong , this is A pointer to an array , this is not THE ONLY type that points to an array. > parr does not point to the array because > its type is not that of a pointer to an array. They all point to the same array. How can you not understand that, do you have learning difficulties? > >>> Incrementing parr adds sizeof(int) to the byte address. Incrementing >>> pparr >>> adds 6*sizeof(int) to the byte address >>> >>>> You obviously have very strange ideas about pointers and arrays, I have >>>> already posted information about array types from experts and the C++ >>>> standard, if you refuse to accept this thats up to you. Please stop >>>> making >>>> statements as if they are statements of factual correctness that are >>>> actually wrong, particularly the one I quote: >>>><quote> >>>> According to the standard, the result of the conversion is a "pointer >>>> to >>>> the >>>> first element of the array" not a "pointer to the array". >>>></quote> >>>> This is a complete misinterpretation of the standards, and incorrect.. >>> >>> The ideas I have about pointers and arrays are from the standard. Here >>> is paragraph 1 of section 4.2 of the standard (you silently snipped >>> the copy that was in my previous post): >>> >>> An lvalue or rvalue of type "array of N T" or "array of unknown >>> bound of T" can be converted to an rvalue of type "pointer to T." >>> The result is a pointer to the first element of the array. >>> >>> A pointer to the first element of the array is not the same as a pointer >>> to >>> the array. >> WHere does the standard state this? Or it this your addition to the >> standard? > > I demonstrated why they are not the same in lines that you sliently > snipped at this point. Here are the snipped lines: > You have demonstrated nothing. > A pointer to the first element of the array is not the same as a pointer > to > the array. The former has type pointer to T, that latter has type > pointer > to array of N T. If they were the same, given the declaration A pointer to the first element of an array, is a pointer to the array. > > int *pi, (*pai)[1]; > > the assignment > > pi = pai; > > would be allowed, but it is not allowed. You obviously do not understand the difference in level sof indirection. > > The C++ standard allows the right operand of an assignment operator > to be implicitly converted to the type of the left operand. However, > converting from a pointer to an array of N T to a pointer to T is > not a conversion allowed by section 4 of the C++ standard, where > the implicit conversions are specified. You obviously dont know anything about the C++ standard if you cant understand the simple statement : points to the first element of an array, means by definition it points to the array. > >> If it points to the first element *OF THE ARRAY* then, by definition , it >> points to the array. > > Such a definition ignores the fact that C++ pointers are typed. The > "it" that points is a pointer with a type. A pointer to an element of > an array and a pointer to an array are two different types of pointers. No it ignores no facts, it acknowledges the relevant sections of the standards that you think are irrelevant. I fully understand the difference between the types: int(*)[size] and int*. I also understand that both can point to arrays, you cannot understand this though . You think only one type can point to an array which is ofc against the views of all the C++ experts.
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-04-01 12:40 -0500 |
| Message-ID | <slrnipc3gd.6l7.aggedor@earl-grey.cloud9.net> |
| In reply to | #2939 |
On 2011-03-31, Paul <pchristor@yahoo.co.uk> wrote: > > "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message > news:slrnip9f0p.26bu.aggedor@earl-grey.cloud9.net... >> On 2011-03-30, Paul <pchristor@yahoo.co.uk> wrote: >>> >>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message >>> news:slrnip6qm7.14ro.aggedor@earl-grey.cloud9.net... >>>> On 2011-03-29, Paul <pchristor@yahoo.co.uk> wrote: >>>>> >>>>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message >>>>> news:slrnip45kk.2kgi.aggedor@earl-grey.cloud9.net... >>>>>> On 2011-03-28, Paul <pchristor@yahoo.co.uk> wrote: >>>>>>> This C++ standard confirms, in section 8.3.4 para 7, that a >>>>>>> dereferenced >>>>>>> array object is always (n-1) dimensions of the pointed to array. >>>>>>> If you don't accpet what's in the standards I don't know what more I >>>>>>> can >>>>>>> say. >>>>>> >>>>>> I accept what is written in the C++ standard. In an earlier followup >>>>>> I >>>>>> gave an example where that paragraph applied. I also accept what is >>>>>> written in paragraph 1 of section 4.2: >>>>> No you don't accept it , you said it wasn't relevant. >>>> >>>> I wrote in a previous followup (message >>>> <slrnip1h84.1bkf.aggedor@earl-grey.cloud9.net>) that what your wrote >>>> about >>>> section 8.3.4 wasn't relevant to the declaration >>>> >>>> int *p = new int[4] >>>> >>>> because the declaration did not dereference an array. I accept the >>>> quote I posted from section 4.2 that you silently snipped. >>>> >>>> [snip] >>> >>> As I said you are trying to say the standards are not relevant when they >>> are. >> >> How is a part of the C++ standard that is about dereferencing an >> array relevant to a C++ statement in which there is no dereferencing >> of an array? > Because it explains that when you derefernece an array it returns a pointed > to (n-1) dimensional array. In order for a part of the C++ standard that is about a dereference of an array to be relevant to a C++ statement, the statement has to contain a dereference of an array. The statement int *p = new int[4] does not dereference an array. There are many other sections of the C++ standard that are not relevant to that statement, such section 5.7 about Additive Operators. There are some sections that are relevant, such as section 5.3.4 about New. >>>>> Why do you think, with three pointers to exactly the same place, they >>>>> point >>>>> to different things? >>>>> Its exactly the opposite of what you say because: >>>>> int arr[6]; /*r-value , can only point to the first element*/ >>>>> int* parr=arr; /*l-value , can point to any element*/ >>>>> int (*pparr)[6] = &arr; /*l-value, can only point to 1st element or 1 >>>>> past >>>>> end.*/ >>>> >>>> They all initially point to the same address, but they have different >>>> types. >>>> arr has type array of 6 int. parr has type pointer to int. pparr has >>>> type >>>> pointer to array of 6 int. >>>> >>> They are all int types >>> arr[6]; /* returns int */ >>> *parr; /*returns int */ >>> *pparr; /*returns int[], which decays to int* */ >>> The third is simply another level of indirection. >> >> It is the variables parr and pparr that are being initialized, not >> the result of dereferencing them. Those variables have different >> types: pointer to int and pointer to array of 6 int, respectively. >> Neither of those variables is type int. > > It doesn't matter if its TYPE is int*****. > Its just a different level of indirection. The type of the array is INT. The type int***** is not the same as type int. Values with different levels of indirection to the same type have different types. >>> So why do you not understand the parr points to the array? >> >> parr is a pointer to an int; it has type int*. A pointer to an array of >> int has of the form int(*)[]. > No you are wrong , this is A pointer to an array , this is not THE ONLY type > that points to an array. > >> parr does not point to the array because >> its type is not that of a pointer to an array. > > They all point to the same array. How can you not understand that, do you > have learning difficulties? I don't have any learning difficulties. However, I do understand that in C++ a pointer to an int points to an int; it does not point to an array. A pointer to an int and an pointer to an array of int are different types. A pointer to an int may point to any int, including one that is an element of an array of int. However, when pointing to an element of an array of int it is pointing to an int, not an array. When you dereference the pointer the result is an int, not an array. [snip] >>>> The ideas I have about pointers and arrays are from the standard. Here >>>> is paragraph 1 of section 4.2 of the standard (you silently snipped >>>> the copy that was in my previous post): >>>> >>>> An lvalue or rvalue of type "array of N T" or "array of unknown >>>> bound of T" can be converted to an rvalue of type "pointer to T." >>>> The result is a pointer to the first element of the array. >>>> >>>> A pointer to the first element of the array is not the same as a pointer >>>> to >>>> the array. >>> WHere does the standard state this? Or it this your addition to the >>> standard? >> >> I demonstrated why they are not the same in lines that you sliently >> snipped at this point. Here are the snipped lines: >> > You have demonstrated nothing. It appears that you think I have demonstrated nothing even before reading the sliently snipped lines that were restored. That is about as useful as write-only memory. >> A pointer to the first element of the array is not the same as a pointer >> to >> the array. The former has type pointer to T, that latter has type >> pointer >> to array of N T. If they were the same, given the declaration > A pointer to the first element of an array, is a pointer to the array. > >> int *pi, (*pai)[1]; >> >> the assignment >> >> pi = pai; >> >> would be allowed, but it is not allowed. > You obviously do not understand the difference in level sof indirection. What C++ compiler have you used that does not give a diagnostic message about the assignment statement? >> The C++ standard allows the right operand of an assignment operator >> to be implicitly converted to the type of the left operand. However, >> converting from a pointer to an array of N T to a pointer to T is >> not a conversion allowed by section 4 of the C++ standard, where >> the implicit conversions are specified. > You obviously dont know anything about the C++ standard if you cant > understand the simple statement : > points to the first element of an array, means by definition it points to > the array. I know enough about the C++ standard to have quoted or referred to parts of it that are relevant to C++ statements discussed in this thread of posts. >>> If it points to the first element *OF THE ARRAY* then, by definition , it >>> points to the array. >> >> Such a definition ignores the fact that C++ pointers are typed. The >> "it" that points is a pointer with a type. A pointer to an element of >> an array and a pointer to an array are two different types of pointers. > > No it ignores no facts, it acknowledges the relevant sections of the > standards that you think are irrelevant. The relevant sections of the standard for the statement pi = pai; where pi and pai are declared with int *pi, (*pai)[1]; are the one about assignment operators (5.17) and the one about implict conversions (4) that it refers to. According to those sections, that assignment, which tries have a pointer to int point to an array, is not allowed. If pi and pai had the same type, the assignment would be allowed. > I fully understand the difference between the types: > int(*)[size] and int*. > I also understand that both can point to arrays, you cannot understand this > though . You think only one type can point to an array which is ofc against > the views of all the C++ experts. If you fully understood the difference between those types in C++, you would understand that a pointer to int cannot point to an array of int. A term, such as "point to", used in the context of a a programming language does not necessarily have the same meaning that it has in other contexts. Exactly where in the C++ standard is a statement that a pointer of another type can "point to an array", as opposed to a pointer whose type is the same as an array element type being able to point to an element of that array?
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-02 02:33 +0100 |
| Message-ID | <I1vlp.2519$9h6.283@newsfe02.ams2> |
| In reply to | #2978 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message news:slrnipc3gd.6l7.aggedor@earl-grey.cloud9.net... > On 2011-03-31, Paul <pchristor@yahoo.co.uk> wrote: >>>>>>>> This C++ standard confirms, in section 8.3.4 para 7, that a >>>>>>>> dereferenced >>>>>>>> array object is always (n-1) dimensions of the pointed to array. >>>>>>>> If you don't accpet what's in the standards I don't know what more >>>>>>>> I >>>>>>>> can >>>>>>>> say. >>>>>>> >>>>>>> I accept what is written in the C++ standard. In an earlier >>>>>>> followup >>>>>>> I >>>>>>> gave an example where that paragraph applied. I also accept what is >>>>>>> written in paragraph 1 of section 4.2: >>>>>> No you don't accept it , you said it wasn't relevant. >>>>> >>>>> I wrote in a previous followup (message >>>>> <slrnip1h84.1bkf.aggedor@earl-grey.cloud9.net>) that what your wrote >>>>> about >>>>> section 8.3.4 wasn't relevant to the declaration >>>>> >>>>> int *p = new int[4] >>>>> >>>>> because the declaration did not dereference an array. I accept the >>>>> quote I posted from section 4.2 that you silently snipped. >>>>> >>>>> [snip] >>>> >>>> As I said you are trying to say the standards are not relevant when >>>> they >>>> are. >>> >>> How is a part of the C++ standard that is about dereferencing an >>> array relevant to a C++ statement in which there is no dereferencing >>> of an array? >> Because it explains that when you derefernece an array it returns a >> pointed >> to (n-1) dimensional array. > > In order for a part of the C++ standard that is about a dereference > of an array to be relevant to a C++ statement, the statement has to > contain a dereference of an array. The statement > > int *p = new int[4] > > does not dereference an array. > > There are many other sections of the C++ standard that are not > relevant to that statement, such section 5.7 about Additive > Operators. There are some sections that are relevant, such as > section 5.3.4 about New. The argument is not simply about this statement, it is about what a pointer to an array is. Therefore the section of the C++ standards that defines pointers to arrays is very releveant. > >>>>>> Why do you think, with three pointers to exactly the same place, they >>>>>> point >>>>>> to different things? >>>>>> Its exactly the opposite of what you say because: >>>>>> int arr[6]; /*r-value , can only point to the first element*/ >>>>>> int* parr=arr; /*l-value , can point to any element*/ >>>>>> int (*pparr)[6] = &arr; /*l-value, can only point to 1st element or 1 >>>>>> past >>>>>> end.*/ >>>>> >>>>> They all initially point to the same address, but they have different >>>>> types. >>>>> arr has type array of 6 int. parr has type pointer to int. pparr has >>>>> type >>>>> pointer to array of 6 int. >>>>> >>>> They are all int types >>>> arr[6]; /* returns int */ >>>> *parr; /*returns int */ >>>> *pparr; /*returns int[], which decays to int* */ >>>> The third is simply another level of indirection. >>> >>> It is the variables parr and pparr that are being initialized, not >>> the result of dereferencing them. Those variables have different >>> types: pointer to int and pointer to array of 6 int, respectively. >>> Neither of those variables is type int. >> >> It doesn't matter if its TYPE is int*****. >> Its just a different level of indirection. The type of the array is INT. > > The type int***** is not the same as type int. Values with different > levels of indirection to the same type have different types. Why would anyone suggest it was the same type? This is only your ludicrous suggestion. We are talking about arrays and different levels of indirection, the typeof the array is int, not int*** or int(*)[x][y][z]. An array of int* is not the same as a 2d array of int. > >>>> So why do you not understand the parr points to the array? >>> >>> parr is a pointer to an int; it has type int*. A pointer to an array of >>> int has of the form int(*)[]. >> No you are wrong , this is A pointer to an array , this is not THE ONLY >> type >> that points to an array. >> >>> parr does not point to the array because >>> its type is not that of a pointer to an array. >> >> They all point to the same array. How can you not understand that, do you >> have learning difficulties? > > I don't have any learning difficulties. However, I do understand that > in C++ a pointer to an int points to an int; it does not point to an > array. A pointer to an int and an pointer to an array of int are > different types. But you obviously don't understand that an int* can point to a single int, or an array of int's. Thus it seems you have have some difficulties with understanding common sense. A pointer type does not define what is pointed to, what is pointed to is defined by allocation. > > A pointer to an int may point to any int, including one that is an > element of an array of int. However, when pointing to an element of > an array of int it is pointing to an int, not an array. When you > dereference the pointer the result is an int, not an array. This is where you lose all sense of logic, a pointer to an entity points exactly to that entity. The pointer type does not define the pointed to entity. > > [snip] > >>>>> The ideas I have about pointers and arrays are from the standard. >>>>> Here >>>>> is paragraph 1 of section 4.2 of the standard (you silently snipped >>>>> the copy that was in my previous post): >>>>> >>>>> An lvalue or rvalue of type "array of N T" or "array of unknown >>>>> bound of T" can be converted to an rvalue of type "pointer to T." >>>>> The result is a pointer to the first element of the array. >>>>> >>>>> A pointer to the first element of the array is not the same as a >>>>> pointer >>>>> to >>>>> the array. >>>> WHere does the standard state this? Or it this your addition to the >>>> standard? >>> >>> I demonstrated why they are not the same in lines that you sliently >>> snipped at this point. Here are the snipped lines: >>> >> You have demonstrated nothing. > > It appears that you think I have demonstrated nothing even before > reading the sliently snipped lines that were restored. That is > about as useful as write-only memory. What exactly does SILENTLY snipped mean? Does snipping produce sound on your PC? > >>> A pointer to the first element of the array is not the same as a >>> pointer >>> to >>> the array. The former has type pointer to T, that latter has type >>> pointer >>> to array of N T. If they were the same, given the declaration >> A pointer to the first element of an array, is a pointer to the array. >> >>> int *pi, (*pai)[1]; >>> >>> the assignment >>> >>> pi = pai; >>> >>> would be allowed, but it is not allowed. >> You obviously do not understand the difference in level sof indirection. > > What C++ compiler have you used that does not give a diagnostic > message about the assignment statement? Your code is just wrong. I don't know what its supposed to do. > >>> The C++ standard allows the right operand of an assignment operator >>> to be implicitly converted to the type of the left operand. However, >>> converting from a pointer to an array of N T to a pointer to T is >>> not a conversion allowed by section 4 of the C++ standard, where >>> the implicit conversions are specified. >> You obviously dont know anything about the C++ standard if you cant >> understand the simple statement : >> points to the first element of an array, means by definition it points to >> the array. > > I know enough about the C++ standard to have quoted or referred to > parts of it that are relevant to C++ statements discussed in this > thread of posts. You don't accept what is relevant , the part of the C++ standards that defines arrays are relevant but you seem to think not. > >>>> If it points to the first element *OF THE ARRAY* then, by definition , >>>> it >>>> points to the array. >>> >>> Such a definition ignores the fact that C++ pointers are typed. The >>> "it" that points is a pointer with a type. A pointer to an element of >>> an array and a pointer to an array are two different types of pointers. >> >> No it ignores no facts, it acknowledges the relevant sections of the >> standards that you think are irrelevant. > > The relevant sections of the standard for the statement > > pi = pai; > > where pi and pai are declared with > > int *pi, (*pai)[1]; > > are the one about assignment operators (5.17) and the one about > implict conversions (4) that it refers to. According to those > sections, that assignment, which tries have a pointer to int point > to an array, is not allowed. If pi and pai had the same type, the > assignment would be allowed. What is this nonsense about , your code is trash dude and you can't even accept what is really the relevant sections of the standard, the sections about arrays. > >> I fully understand the difference between the types: >> int(*)[size] and int*. >> I also understand that both can point to arrays, you cannot understand >> this >> though . You think only one type can point to an array which is ofc >> against >> the views of all the C++ experts. > > If you fully understood the difference between those types in C++, > you would understand that a pointer to int cannot point to an array > of int. A term, such as "point to", used in the context of a > a programming language does not necessarily have the same meaning > that it has in other contexts. As you refuse to accept all reason and common sense I can only appeal to authority. If people like Bjarne Stroustrup say that an int* can point to a single int or an array of int, and you say otherwise, who are we to believe is correct? You or Bjarne Stroustrup? If the C++ standard states that , when dereferenced, an array(or pointer to an array) returns the pointed to (n-1)dimension array. Then who are we to believe, you or the C++ standard? > > Exactly where in the C++ standard is a statement that a pointer of > another type can "point to an array", as opposed to a pointer whose > type is the same as an array element type being able to point to an > element of that array? You refuse to accept what the C++ standard says about arrays, you said it was irrelevant because the statement: int* p = new int[7]; does not contain any dereference.
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-04-04 12:42 -0500 |
| Message-ID | <slrnipk0n8.260.aggedor@earl-grey.cloud9.net> |
| In reply to | #2986 |
On 2011-04-02, Paul <pchristor@yahoo.co.uk> wrote: > > "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message > news:slrnipc3gd.6l7.aggedor@earl-grey.cloud9.net... >> On 2011-03-31, Paul <pchristor@yahoo.co.uk> wrote: [snip] >>>> How is a part of the C++ standard that is about dereferencing an >>>> array relevant to a C++ statement in which there is no dereferencing >>>> of an array? >>> Because it explains that when you derefernece an array it returns a >>> pointed >>> to (n-1) dimensional array. >> >> In order for a part of the C++ standard that is about a dereference >> of an array to be relevant to a C++ statement, the statement has to >> contain a dereference of an array. The statement >> >> int *p = new int[4] >> >> does not dereference an array. >> >> There are many other sections of the C++ standard that are not >> relevant to that statement, such section 5.7 about Additive >> Operators. There are some sections that are relevant, such as >> section 5.3.4 about New. > The argument is not simply about this statement, it is about what a pointer > to an array is. Therefore the section of the C++ standards that defines > pointers to arrays is very releveant. My comment was simply about a C++ statement. I wrote that part of the C++ standard about dereferencing an array is not relevant to the statement int *p = new int[4]; because that statement does not dereference an array. In addition, the statement does not involve a pointer to an array. The statement declares a pointer to an int. That pointer is initialized with a C++ expression that according to the C++ standard returns a pointer to an int (see paragraph 5 of section 5.3.4 of the standard about New, which I quoted it in my first post in this thread of posts). >>>>>>> Why do you think, with three pointers to exactly the same place, they >>>>>>> point >>>>>>> to different things? >>>>>>> Its exactly the opposite of what you say because: >>>>>>> int arr[6]; /*r-value , can only point to the first element*/ >>>>>>> int* parr=arr; /*l-value , can point to any element*/ >>>>>>> int (*pparr)[6] = &arr; /*l-value, can only point to 1st element or 1 >>>>>>> past >>>>>>> end.*/ >>>>>> >>>>>> They all initially point to the same address, but they have different >>>>>> types. >>>>>> arr has type array of 6 int. parr has type pointer to int. pparr has >>>>>> type >>>>>> pointer to array of 6 int. >>>>>> >>>>> They are all int types >>>>> arr[6]; /* returns int */ >>>>> *parr; /*returns int */ >>>>> *pparr; /*returns int[], which decays to int* */ >>>>> The third is simply another level of indirection. >>>> >>>> It is the variables parr and pparr that are being initialized, not >>>> the result of dereferencing them. Those variables have different >>>> types: pointer to int and pointer to array of 6 int, respectively. >>>> Neither of those variables is type int. >>> >>> It doesn't matter if its TYPE is int*****. >>> Its just a different level of indirection. The type of the array is INT. >> >> The type int***** is not the same as type int. Values with different >> levels of indirection to the same type have different types. > Why would anyone suggest it was the same type? This is only your ludicrous > suggestion. We are talking about arrays and different levels of indirection, > the typeof the array is int, not int*** or int(*)[x][y][z]. > An array of int* is not the same as a 2d array of int. You are the one who suggested that they were the same type by writing: "They all are int types" and "It doesn't matter if the TYPE is int*****." [snip] >>>> parr does not point to the array because >>>> its type is not that of a pointer to an array. >>> >>> They all point to the same array. How can you not understand that, do you >>> have learning difficulties? >> >> I don't have any learning difficulties. However, I do understand that >> in C++ a pointer to an int points to an int; it does not point to an >> array. A pointer to an int and an pointer to an array of int are >> different types. > But you obviously don't understand that an int* can point to a single int, > or an array of int's. Thus it seems you have have some difficulties with > understanding common sense. > A pointer type does not define what is pointed to, what is pointed to is > defined by allocation. What I understand is that in C++ a pointer to an int points to an int and not to an array of int. A pointer to an int and a pointer to an array of int are different types. It is not a matter of common sense; it is a matter of what the term "points to" means in C++. Here is paragraph 1 of section 5.3.1 of the C++ standard: The unary * operator performs indirection: the expression to which it is applied shall be a pointer to an object type, or a pointer to a function type and the result is an lvalue referring to the object or function to which the expression points. If the type of the expression is pointer to T, the type of the result is T. [Note: a pointer to an incomplete type (other than cv void ) can be dereferenced. The lvalue thus obtained can be used in limited ways (to initialize a reference, for example); this lvalue must not be converted to an rvalue, see 4.1.] According to the C++ standard, the pointer type determines the type of the result of dereferencing the pointer. >> A pointer to an int may point to any int, including one that is an >> element of an array of int. However, when pointing to an element of >> an array of int it is pointing to an int, not an array. When you >> dereference the pointer the result is an int, not an array. > This is where you lose all sense of logic, a pointer to an entity points > exactly to that entity. The pointer type does not define the pointed to > entity. According the the C++ standard, see the preceeding quote from the standard, the type of the result of dereferencing a pointer depends on the type of the pointer. The result type does not depend on the type used when the object was allocated. [snip] >>>>>> The ideas I have about pointers and arrays are from the standard. >>>>>> Here >>>>>> is paragraph 1 of section 4.2 of the standard (you silently snipped >>>>>> the copy that was in my previous post): >>>>>> >>>>>> An lvalue or rvalue of type "array of N T" or "array of unknown >>>>>> bound of T" can be converted to an rvalue of type "pointer to T." >>>>>> The result is a pointer to the first element of the array. >>>>>> >>>>>> A pointer to the first element of the array is not the same as a >>>>>> pointer >>>>>> to >>>>>> the array. >>>>> WHere does the standard state this? Or it this your addition to the >>>>> standard? >>>> >>>> I demonstrated why they are not the same in lines that you sliently >>>> snipped at this point. Here are the snipped lines: >>>> >>> You have demonstrated nothing. >> >> It appears that you think I have demonstrated nothing even before >> reading the sliently snipped lines that were restored. That is >> about as useful as write-only memory. > What exactly does SILENTLY snipped mean? Does snipping produce sound on your > PC? Silently snipped means removing lines of the post being followed-up to without indicating that the lines have been removed, such as by including "[snip]" in the followup. >>>> A pointer to the first element of the array is not the same as a >>>> pointer >>>> to >>>> the array. The former has type pointer to T, that latter has type >>>> pointer >>>> to array of N T. If they were the same, given the declaration >>> A pointer to the first element of an array, is a pointer to the array. >>> >>>> int *pi, (*pai)[1]; >>>> >>>> the assignment >>>> >>>> pi = pai; >>>> >>>> would be allowed, but it is not allowed. >>> You obviously do not understand the difference in level sof indirection. >> >> What C++ compiler have you used that does not give a diagnostic >> message about the assignment statement? > Your code is just wrong. I don't know what its supposed to do. What it tries to do is assign a pointer to an array of int to a pointer to an int. The fact that it is not allowed by the C++ standard demonstrates that a pointer to an int cannot not point to an array of int. It can point to an element of an array of int. The statement pi = &((*pai)[0]); is allowed. It assigns a pointer to an element of an array of int to a pointer to an int. [snip] >>>>> If it points to the first element *OF THE ARRAY* then, by definition , >>>>> it >>>>> points to the array. >>>> >>>> Such a definition ignores the fact that C++ pointers are typed. The >>>> "it" that points is a pointer with a type. A pointer to an element of >>>> an array and a pointer to an array are two different types of pointers. >>> >>> No it ignores no facts, it acknowledges the relevant sections of the >>> standards that you think are irrelevant. >> >> The relevant sections of the standard for the statement >> >> pi = pai; >> >> where pi and pai are declared with >> >> int *pi, (*pai)[1]; >> >> are the one about assignment operators (5.17) and the one about >> implict conversions (4) that it refers to. According to those >> sections, that assignment, which tries have a pointer to int point >> to an array, is not allowed. If pi and pai had the same type, the >> assignment would be allowed. > What is this nonsense about , your code is trash dude and you can't even > accept what is really the relevant sections of the standard, the sections > about arrays. The fact that C++ compilers reject the code demonstrates that a pointer to an array of int cannot be assigned to a pointer to int. In other words, a pointer to int cannot point to an array of int. What paragraph of the C++ standard states otherwise? >>> I fully understand the difference between the types: >>> int(*)[size] and int*. >>> I also understand that both can point to arrays, you cannot understand >>> this >>> though . You think only one type can point to an array which is ofc >>> against >>> the views of all the C++ experts. >> >> If you fully understood the difference between those types in C++, >> you would understand that a pointer to int cannot point to an array >> of int. A term, such as "point to", used in the context of a >> a programming language does not necessarily have the same meaning >> that it has in other contexts. > As you refuse to accept all reason and common sense I can only appeal to > authority. If people like Bjarne Stroustrup say that an int* can point to a > single int or an array of int, and you say otherwise, who are we to believe > is correct? You or Bjarne Stroustrup? No one needs to believe anything that is not supported by what is in the C++ standard or by compliers that comply to the standard. Given the declaraion int *pi, (*pai)[1]; the statement pi = pai; which attempts to have a pointer to an int point to the array of int (pointed to by the variable pai) is not allowed. C++ compilers will issue a diagnosic message for the assignment statement. > If the C++ standard states that , when dereferenced, an array(or pointer to > an array) returns the pointed to (n-1)dimension array. Then who are we to > believe, you or the C++ standard? Right, in the statement int a2i[3][5], (*pa1i)[5] = a2i; evaluating a2i in the initialization expression returns a pointer to a 1-dimensional array. After the initialization pa1i points to that 1-dimensional array, not to a 2-dimensional array. >> Exactly where in the C++ standard is a statement that a pointer of >> another type can "point to an array", as opposed to a pointer whose >> type is the same as an array element type being able to point to an >> element of that array? > > You refuse to accept what the C++ standard says about arrays, you said it > was irrelevant because the statement: > int* p = new int[7]; > does not contain any dereference. I accept what the C++ standard says about arrays. I said that parts of the C++ standard about *dereferencing* are not relevant to a statement that does not contain dereferencing (I have emphasized the word *dereferencing* because you omitted it). I have answered your questions and cited parts of the C++ standard relevant to example C++ statements. I don't know why you don't similarly answer my questions, including the one immediately before the last lines of your post.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-04 20:12 +0100 |
| Message-ID | <RKomp.2860$9h6.80@newsfe02.ams2> |
| In reply to | #3088 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message news:slrnipk0n8.260.aggedor@earl-grey.cloud9.net... > On 2011-04-02, Paul <pchristor@yahoo.co.uk> wrote: >> >> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message >> news:slrnipc3gd.6l7.aggedor@earl-grey.cloud9.net... >>> On 2011-03-31, Paul <pchristor@yahoo.co.uk> wrote: > [snip] >>>>> How is a part of the C++ standard that is about dereferencing an >>>>> array relevant to a C++ statement in which there is no dereferencing >>>>> of an array? >>>> Because it explains that when you derefernece an array it returns a >>>> pointed >>>> to (n-1) dimensional array. >>> >>> In order for a part of the C++ standard that is about a dereference >>> of an array to be relevant to a C++ statement, the statement has to >>> contain a dereference of an array. The statement >>> >>> int *p = new int[4] >>> >>> does not dereference an array. >>> >>> There are many other sections of the C++ standard that are not >>> relevant to that statement, such section 5.7 about Additive >>> Operators. There are some sections that are relevant, such as >>> section 5.3.4 about New. >> The argument is not simply about this statement, it is about what a >> pointer >> to an array is. Therefore the section of the C++ standards that defines >> pointers to arrays is very releveant. > > My comment was simply about a C++ statement. I wrote that part of > the C++ standard about dereferencing an array is not relevant to the > statement > > int *p = new int[4]; > > because that statement does not dereference an array. > > In addition, the statement does not involve a pointer to an array. > The statement declares a pointer to an int. That pointer is > initialized with a C++ expression that according to the C++ > standard returns a pointer to an int (see paragraph 5 of section > 5.3.4 of the standard about New, which I quoted it in my first post > in this thread of posts). > Nonsense that pointer simply does point to an array. Obviously its type is pointer to int, but this does not mean it cannot point to an array of int. Since you have stated that a pointer of type int* cannot point to an array the rellevant sections of the standards, that address dereferencing pointers to arrays, are applicable. >>>>>>>> Why do you think, with three pointers to exactly the same place, >>>>>>>> they >>>>>>>> point >>>>>>>> to different things? >>>>>>>> Its exactly the opposite of what you say because: >>>>>>>> int arr[6]; /*r-value , can only point to the first element*/ >>>>>>>> int* parr=arr; /*l-value , can point to any element*/ >>>>>>>> int (*pparr)[6] = &arr; /*l-value, can only point to 1st element or >>>>>>>> 1 >>>>>>>> past >>>>>>>> end.*/ >>>>>>> >>>>>>> They all initially point to the same address, but they have >>>>>>> different >>>>>>> types. >>>>>>> arr has type array of 6 int. parr has type pointer to int. pparr >>>>>>> has >>>>>>> type >>>>>>> pointer to array of 6 int. >>>>>>> >>>>>> They are all int types >>>>>> arr[6]; /* returns int */ >>>>>> *parr; /*returns int */ >>>>>> *pparr; /*returns int[], which decays to int* */ >>>>>> The third is simply another level of indirection. >>>>> >>>>> It is the variables parr and pparr that are being initialized, not >>>>> the result of dereferencing them. Those variables have different >>>>> types: pointer to int and pointer to array of 6 int, respectively. >>>>> Neither of those variables is type int. >>>> >>>> It doesn't matter if its TYPE is int*****. >>>> Its just a different level of indirection. The type of the array is >>>> INT. >>> >>> The type int***** is not the same as type int. Values with different >>> levels of indirection to the same type have different types. >> Why would anyone suggest it was the same type? This is only your >> ludicrous >> suggestion. We are talking about arrays and different levels of >> indirection, >> the typeof the array is int, not int*** or int(*)[x][y][z]. >> An array of int* is not the same as a 2d array of int. > > You are the one who suggested that they were the same type by > writing: "They all are int types" and "It doesn't matter if the > TYPE is int*****." > I'm saying they are all arrays of the same type i.e: int arr1[3][4]; /*Array of int type*/ int arr2[6]; /*Array of int*/ int* p1 = new int[5]; /*Array of int*/ int (*p2)[6] = new int[5][6]; /*Array of int*/ They are all int-type arrays and the identifier in each case, no matter what type that is, points to an array of int. > [snip] > >>>>> parr does not point to the array because >>>>> its type is not that of a pointer to an array. >>>> >>>> They all point to the same array. How can you not understand that, do >>>> you >>>> have learning difficulties? >>> >>> I don't have any learning difficulties. However, I do understand that >>> in C++ a pointer to an int points to an int; it does not point to an >>> array. A pointer to an int and an pointer to an array of int are >>> different types. >> But you obviously don't understand that an int* can point to a single >> int, >> or an array of int's. Thus it seems you have have some difficulties with >> understanding common sense. >> A pointer type does not define what is pointed to, what is pointed to is >> defined by allocation. > > What I understand is that in C++ a pointer to an int points to an int > and not to an array of int. This is wrong. An int* can point to an array of ints. It can actually point to almost anything but within reason its either uninitialised, null , points to int or points to array of int. > A pointer to an int and a pointer to an > array of int are different types. No they're not. Your thinking about pointer types, not what is pointed to. I have already said a pointer type doesn't define what is pointed to but I will repeat it. > It is not a matter of common sense; > it is a matter of what the term "points to" means in C++. Here is > paragraph 1 of section 5.3.1 of the C++ standard: I know what points to means I dont need to reference the standard to find out. > > The unary * operator performs indirection: the expression to which > it is applied shall be a pointer to an object type, or a pointer > to a function type and the result is an lvalue referring to the > object or function to which the expression points. If the type of > the expression is pointer to T, the type of the result is T. > [Note: a pointer to an incomplete type (other than cv void ) can > be dereferenced. The lvalue thus obtained can be used in limited > ways (to initialize a reference, for example); this lvalue must > not be converted to an rvalue, see 4.1.] > > According to the C++ standard, the pointer type determines the > type of the result of dereferencing the pointer > So the C++ standards are relevant now when talking about dereferencing pointers? If you read the above in conjuction with the relevant section on arrays you will understand. >>> A pointer to an int may point to any int, including one that is an >>> element of an array of int. However, when pointing to an element of >>> an array of int it is pointing to an int, not an array. When you >>> dereference the pointer the result is an int, not an array. >> This is where you lose all sense of logic, a pointer to an entity points >> exactly to that entity. The pointer type does not define the pointed to >> entity. > > According the the C++ standard, see the preceeding quote from the > standard, the type of the result of dereferencing a pointer depends > on the type of the pointer. The result type does not depend on the > type used when the object was allocated. > This does not mean the an int* cannot point to an array, If you read the standards properly you will understand why a pointer to an array must point to , the pointed to (n-1) diemnsional array. And I though you said the standards were irellevant because we were not talking aobut dereferencing a pointer. > [snip] > >>>>>>> The ideas I have about pointers and arrays are from the standard. >>>>>>> Here >>>>>>> is paragraph 1 of section 4.2 of the standard (you silently snipped >>>>>>> the copy that was in my previous post): >>>>>>> >>>>>>> An lvalue or rvalue of type "array of N T" or "array of unknown >>>>>>> bound of T" can be converted to an rvalue of type "pointer to T." >>>>>>> The result is a pointer to the first element of the array. >>>>>>> >>>>>>> A pointer to the first element of the array is not the same as a >>>>>>> pointer >>>>>>> to >>>>>>> the array. >>>>>> WHere does the standard state this? Or it this your addition to the >>>>>> standard? >>>>> >>>>> I demonstrated why they are not the same in lines that you sliently >>>>> snipped at this point. Here are the snipped lines: >>>>> >>>> You have demonstrated nothing. >>> >>> It appears that you think I have demonstrated nothing even before >>> reading the sliently snipped lines that were restored. That is >>> about as useful as write-only memory. >> What exactly does SILENTLY snipped mean? Does snipping produce sound on >> your >> PC? > > Silently snipped means removing lines of the post being followed-up > to without indicating that the lines have been removed, such as by > including "[snip]" in the followup. > >>>>> A pointer to the first element of the array is not the same as a >>>>> pointer >>>>> to >>>>> the array. The former has type pointer to T, that latter has type >>>>> pointer >>>>> to array of N T. If they were the same, given the declaration >>>> A pointer to the first element of an array, is a pointer to the array. >>>> >>>>> int *pi, (*pai)[1]; >>>>> >>>>> the assignment >>>>> >>>>> pi = pai; >>>>> >>>>> would be allowed, but it is not allowed. >>>> You obviously do not understand the difference in level sof >>>> indirection. >>> >>> What C++ compiler have you used that does not give a diagnostic >>> message about the assignment statement? >> Your code is just wrong. I don't know what its supposed to do. > > What it tries to do is assign a pointer to an array of int to a > pointer to an int. Well thats just wrong because the pointer types are different levels if indirection. You convert an array into a pointer like so : int arr[5]; int* p = arr; You don't take the address of an array , unless you want a different level of indirection. Arrays are implicitly converted to pointers. > The fact that it is not allowed by the C++ > standard demonstrates that a pointer to an int cannot not point > to an array of int. It is allowed but it needs a cast. > It can point to an element of an array of int. > The statement > > pi = &((*pai)[0]); > > is allowed. It assigns a pointer to an element of an array of int > to a pointer to an int. > You are either deliberately or unknowingly writing bad code. > [snip] > >>>>>> If it points to the first element *OF THE ARRAY* then, by definition >>>>>> , >>>>>> it >>>>>> points to the array. >>>>> >>>>> Such a definition ignores the fact that C++ pointers are typed. The >>>>> "it" that points is a pointer with a type. A pointer to an element of >>>>> an array and a pointer to an array are two different types of >>>>> pointers. >>>> >>>> No it ignores no facts, it acknowledges the relevant sections of the >>>> standards that you think are irrelevant. >>> >>> The relevant sections of the standard for the statement >>> >>> pi = pai; >>> >>> where pi and pai are declared with >>> >>> int *pi, (*pai)[1]; >>> >>> are the one about assignment operators (5.17) and the one about >>> implict conversions (4) that it refers to. According to those >>> sections, that assignment, which tries have a pointer to int point >>> to an array, is not allowed. If pi and pai had the same type, the >>> assignment would be allowed. >> What is this nonsense about , your code is trash dude and you can't even >> accept what is really the relevant sections of the standard, the sections >> about arrays. > > The fact that C++ compilers reject the code demonstrates that a > pointer to an array of int cannot be assigned to a pointer to int. > In other words, a pointer to int cannot point to an array of int. > What paragraph of the C++ standard states otherwise? > Its your code that is rejected by compilers so its your understanding that must be wrong. >>>> I fully understand the difference between the types: >>>> int(*)[size] and int*. >>>> I also understand that both can point to arrays, you cannot understand >>>> this >>>> though . You think only one type can point to an array which is ofc >>>> against >>>> the views of all the C++ experts. >>> >>> If you fully understood the difference between those types in C++, >>> you would understand that a pointer to int cannot point to an array >>> of int. A term, such as "point to", used in the context of a >>> a programming language does not necessarily have the same meaning >>> that it has in other contexts. >> As you refuse to accept all reason and common sense I can only appeal to >> authority. If people like Bjarne Stroustrup say that an int* can point to >> a >> single int or an array of int, and you say otherwise, who are we to >> believe >> is correct? You or Bjarne Stroustrup? > > No one needs to believe anything that is not supported by what is > in the C++ standard or by compliers that comply to the standard. > Given the declaraion > > int *pi, (*pai)[1]; > > the statement > > pi = pai; > > which attempts to have a pointer to an int point to the array of int > (pointed to by the variable pai) is not allowed. C++ compilers will > issue a diagnosic message for the assignment statement. That piece of bad code you have produced somehow suggests that Bjarne Stroustrup is wrong does it? > > >> If the C++ standard states that , when dereferenced, an array(or pointer >> to >> an array) returns the pointed to (n-1)dimension array. Then who are we >> to >> believe, you or the C++ standard? > > Right, in the statement > > int a2i[3][5], (*pa1i)[5] = a2i; > > evaluating a2i in the initialization expression returns a pointer to > a 1-dimensional array. After the initialization pa1i points to that > 1-dimensional array, not to a 2-dimensional array. a2i is implicitly converted to a pointer. The pointed to array is a 2d array, not a 1dim array. Where the above standards quote applies is if you derefernece either a2i or pa1i, eg: *pa1i; or pa1i[0]; This is dereferencing the pointer to the array, and the results of this dereference is an array of (n-1) dimensions , eg: int[5]; As you can see the standard agrees perfectly with my interpretation. If you take pa1i and consider it a pointer to a 1d array, this fails because *pa1i does not produce the pointed to (n-1) dimensional array, which would be a single int( a zero dim array). You are creating another level of indirection, because arr already is(or converts to) a pointer, under the hood. You compare this with a pointer to a non array object, eg: int arr[6]; int (*p)[6] = &arr; /*Taking address of a pointer.*/ int x =5; int* p_x=&x; /*Creating a pointer */ You think the above is the same but its not, what you are doing is similar to this: int** pp = &p_x; /*Taking address of a pointer*/ > >>> Exactly where in the C++ standard is a statement that a pointer of >>> another type can "point to an array", as opposed to a pointer whose >>> type is the same as an array element type being able to point to an >>> element of that array? >> >> You refuse to accept what the C++ standard says about arrays, you said it >> was irrelevant because the statement: >> int* p = new int[7]; >> does not contain any dereference. > > I accept what the C++ standard says about arrays. I said that parts > of the C++ standard about *dereferencing* are not relevant to a > statement that does not contain dereferencing (I have emphasized the > word *dereferencing* because you omitted it). Well you have posted stuff from the standards about dereferencing pointers. > > I have answered your questions and cited parts of the C++ standard > relevant to example C++ statements. I don't know why you don't > similarly answer my questions, including the one immediately before > the last lines of your post. I have answered any questins you have asked.
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2011-04-04 16:31 -0400 |
| Message-ID | <7b8kp6p968ejg904j3g6lv714tn3mdhsiq@4ax.com> |
| In reply to | #3097 |
On Mon, 4 Apr 2011 20:12:38 +0100, "Paul" <pchristor@yahoo.co.uk> wrote: > >"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message >news:slrnipk0n8.260.aggedor@earl-grey.cloud9.net... >> On 2011-04-02, Paul <pchristor@yahoo.co.uk> wrote: >>> >>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message >>> news:slrnipc3gd.6l7.aggedor@earl-grey.cloud9.net... >>>> On 2011-03-31, Paul <pchristor@yahoo.co.uk> wrote: >> [snip] >>>>>> How is a part of the C++ standard that is about dereferencing an >>>>>> array relevant to a C++ statement in which there is no dereferencing >>>>>> of an array? >>>>> Because it explains that when you derefernece an array it returns a >>>>> pointed >>>>> to (n-1) dimensional array. >>>> >>>> In order for a part of the C++ standard that is about a dereference >>>> of an array to be relevant to a C++ statement, the statement has to >>>> contain a dereference of an array. The statement >>>> >>>> int *p = new int[4] >>>> >>>> does not dereference an array. >>>> >>>> There are many other sections of the C++ standard that are not >>>> relevant to that statement, such section 5.7 about Additive >>>> Operators. There are some sections that are relevant, such as >>>> section 5.3.4 about New. >>> The argument is not simply about this statement, it is about what a >>> pointer >>> to an array is. Therefore the section of the C++ standards that defines >>> pointers to arrays is very releveant. >> >> My comment was simply about a C++ statement. I wrote that part of >> the C++ standard about dereferencing an array is not relevant to the >> statement >> >> int *p = new int[4]; >> >> because that statement does not dereference an array. >> >> In addition, the statement does not involve a pointer to an array. >> The statement declares a pointer to an int. That pointer is >> initialized with a C++ expression that according to the C++ >> standard returns a pointer to an int (see paragraph 5 of section >> 5.3.4 of the standard about New, which I quoted it in my first post >> in this thread of posts). >> >Nonsense that pointer simply does point to an array. Nonsense, it ONLY points to an int. > Obviously its type is >pointer to int, That is exactly what it is and ONLY what it points to by C++ definition. >but this does not mean it cannot point to an array of int. Technically speaking, it does mean that it does not point to an array. You sir, are miguided by what you think the Standard should say, versus what it does say. >Since you have stated that a pointer of type int* cannot point to an array After all of your threads you are still confused by the most simple terminology. First off, a "pointer of type int*" is a "pointer to a pointer to int." The example above is simply "pointer to int" It is amazing how you make false assertions to support your false statements. You are not even qualified to have a discussion about arrays, since discussing pointers is a prerequisite and you've just demonstrated that cannot even do that. This thread's subject title is most appropriate, however: "Problem with array objects". You are having this "problem" because you are incapable of grasping the simple meaning of what a pointer is and what a pointer does. >the rellevant sections of the standards, that address dereferencing pointers >to arrays, are applicable. > > >>>>>>>>> Why do you think, with three pointers to exactly the same place, >>>>>>>>> they >>>>>>>>> point >>>>>>>>> to different things? >>>>>>>>> Its exactly the opposite of what you say because: >>>>>>>>> int arr[6]; /*r-value , can only point to the first element*/ >>>>>>>>> int* parr=arr; /*l-value , can point to any element*/ >>>>>>>>> int (*pparr)[6] = &arr; /*l-value, can only point to 1st element or >>>>>>>>> 1 >>>>>>>>> past >>>>>>>>> end.*/ >>>>>>>> >>>>>>>> They all initially point to the same address, but they have >>>>>>>> different >>>>>>>> types. >>>>>>>> arr has type array of 6 int. parr has type pointer to int. pparr >>>>>>>> has >>>>>>>> type >>>>>>>> pointer to array of 6 int. >>>>>>>> >>>>>>> They are all int types >>>>>>> arr[6]; /* returns int */ >>>>>>> *parr; /*returns int */ >>>>>>> *pparr; /*returns int[], which decays to int* */ >>>>>>> The third is simply another level of indirection. >>>>>> >>>>>> It is the variables parr and pparr that are being initialized, not >>>>>> the result of dereferencing them. Those variables have different >>>>>> types: pointer to int and pointer to array of 6 int, respectively. >>>>>> Neither of those variables is type int. >>>>> >>>>> It doesn't matter if its TYPE is int*****. >>>>> Its just a different level of indirection. The type of the array is >>>>> INT. >>>> >>>> The type int***** is not the same as type int. Values with different >>>> levels of indirection to the same type have different types. >>> Why would anyone suggest it was the same type? This is only your >>> ludicrous >>> suggestion. We are talking about arrays and different levels of >>> indirection, >>> the typeof the array is int, not int*** or int(*)[x][y][z]. >>> An array of int* is not the same as a 2d array of int. >> >> You are the one who suggested that they were the same type by >> writing: "They all are int types" and "It doesn't matter if the >> TYPE is int*****." >> >I'm saying they are all arrays of the same type i.e: >int arr1[3][4]; /*Array of int type*/ >int arr2[6]; /*Array of int*/ >int* p1 = new int[5]; /*Array of int*/ >int (*p2)[6] = new int[5][6]; /*Array of int*/ Once again, your proof here is invalid given the poor choice of terminology in your comments. I am all too happy to help. int arr1[3][4]; // arrays of int arrays int arr2[6]; // array of int int* p1 = new int[5]; // pointer to a single int element int (*p2)[6] = new int[5][6]; // pointer to a single array of int Regardless of the storage allocated by both new expressions, the pointer initialized is of the type returned by new. In the first case the type is int so the pointer points to a single int. In the latter case, the type is int array so the pointer points to a single array of int. These two types are different types and in a technical discussion regarding what a pointer points to, the type is everything. Paul <pchristor@yahoo.co.uk> wrote: > "I'm saying they are all arrays of the same type" and I am saying that you are indeed fractally wrong. It has been said, but your ability to properly describe types is inadequate and your inability to hold a proper technical discussion about C++ is visible in each and every one of your posts. This most recent post of yours shows that you are so wrong with your supporting assertions that it is not possible to even debate with you on a level meaningful enough to classify as a proper technical C++ discussion. > >They are all int-type arrays and the identifier in each case, no matter what >type that is, points to an array of int. so replete with fail.. <snip, too many false assertions used as a foundation for Paul's trolling>
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-04-05 12:39 -0500 |
| Message-ID | <slrnipmktl.1eov.aggedor@earl-grey.cloud9.net> |
| In reply to | #3097 |
On 2011-04-04, Paul <pchristor@yahoo.co.uk> wrote: > > "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message > news:slrnipk0n8.260.aggedor@earl-grey.cloud9.net... >> On 2011-04-02, Paul <pchristor@yahoo.co.uk> wrote: >>> >>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message >>> news:slrnipc3gd.6l7.aggedor@earl-grey.cloud9.net... >>>> On 2011-03-31, Paul <pchristor@yahoo.co.uk> wrote: [snip] > I'm saying they are all arrays of the same type i.e: > int arr1[3][4]; /*Array of int type*/ > int arr2[6]; /*Array of int*/ > int* p1 = new int[5]; /*Array of int*/ > int (*p2)[6] = new int[5][6]; /*Array of int*/ > > They are all int-type arrays and the identifier in each case, no matter what > type that is, points to an array of int. Actually, arr1 is a 2-dimensional array of int, p1 is a pointer to int, new int[5] returns a pointer to an int, p2 is a pointer to an array of int, and new int[5][6] returns a pointer to a 1-dimensional array of int. p1 and p2 are pointers, not arrays. Here is a example from section 8.1 (Type Names) of the C++ standard int // int i int * // int *pi int *[3] // int *p[3] int (*)[3] // int (*p3i)[3] int *() // int *f() int (*)(double) // int (*pf)(double) name respectively the types "int," "pointer to int," "array of 3 pointers to int," "pointer to array of 3 int," "function of (no parameters) returning pointer to int," and "pointer to a function of (double) returning int. Here is a note from paragraph 5 of section 5.3.4 (New) of the C++ standard: "Note: both new int and new int[10] have type int* and the type of new int[i][10] is int (*)[10]." [snip] >> A pointer to an int and a pointer to an >> array of int are different types. > No they're not. Your thinking about pointer types, not what is pointed to. I > have already said a pointer type doesn't define what is pointed to but I > will repeat it. If a pointer to an int and a pointer to an array of int were the same type, then the statement int (*pai)[1], *pa = pai; would be allowed, but it isn't. A compiler I use gives the message "error: cannot convert 'int (*)[1]' to 'int*' in initialization". An attempt is being made to convert a pointer to an array of int to a pointer to an int. >> It is not a matter of common sense; >> it is a matter of what the term "points to" means in C++. Here is >> paragraph 1 of section 5.3.1 of the C++ standard: > I know what points to means I dont need to reference the standard to find > out. You need to reference the C++ standard to understand what a term means in the C++ programming language. >> The unary * operator performs indirection: the expression to which >> it is applied shall be a pointer to an object type, or a pointer >> to a function type and the result is an lvalue referring to the >> object or function to which the expression points. If the type of >> the expression is pointer to T, the type of the result is T. >> [Note: a pointer to an incomplete type (other than cv void ) can >> be dereferenced. The lvalue thus obtained can be used in limited >> ways (to initialize a reference, for example); this lvalue must >> not be converted to an rvalue, see 4.1.] >> >> According to the C++ standard, the pointer type determines the >> type of the result of dereferencing the pointer >> > So the C++ standards are relevant now when talking about dereferencing > pointers? > If you read the above in conjuction with the relevant section on arrays you > will understand. A section of the C++ standard about dereferencing a pointer is relevant to a statement in which a pointer is dereferenced. The same section is not relevant to a statement in which a pointer is not dereferenced. >>>> A pointer to an int may point to any int, including one that is an >>>> element of an array of int. However, when pointing to an element of >>>> an array of int it is pointing to an int, not an array. When you >>>> dereference the pointer the result is an int, not an array. >>> This is where you lose all sense of logic, a pointer to an entity points >>> exactly to that entity. The pointer type does not define the pointed to >>> entity. >> >> According the the C++ standard, see the preceeding quote from the >> standard, the type of the result of dereferencing a pointer depends >> on the type of the pointer. The result type does not depend on the >> type used when the object was allocated. >> > This does not mean the an int* cannot point to an array, If you read the > standards properly you will understand why a pointer to an array must point > to , the pointed to (n-1) diemnsional array. That's right, the quote from the standard is about the unary * operator It is not relevant to whether an int* can point to an array. A pointer to an array points to an array of the number of dimensions in the pointer type, not to an array of one fewer dimensions. For example, int (*p2i)[3][5] declares a pointer to a 2-dimensional array, not to a 1-dimensional array. > And I though you said the standards were irellevant because we were not > talking aobut dereferencing a pointer. I said that a part of the standard about dereferencing is not relevant to a statement, such as int *p = new int[4]; in which there is no dereferencing. A part of the standard about dereferencing is relevant to a statement in which there is a dereference operation. >>>>>> A pointer to the first element of the array is not the same as a >>>>>> pointer >>>>>> to >>>>>> the array. The former has type pointer to T, that latter has type >>>>>> pointer >>>>>> to array of N T. If they were the same, given the declaration >>>>> A pointer to the first element of an array, is a pointer to the array. >>>>> >>>>>> int *pi, (*pai)[1]; >>>>>> >>>>>> the assignment >>>>>> >>>>>> pi = pai; >>>>>> >>>>>> would be allowed, but it is not allowed. >>>>> You obviously do not understand the difference in level sof >>>>> indirection. >>>> >>>> What C++ compiler have you used that does not give a diagnostic >>>> message about the assignment statement? >>> Your code is just wrong. I don't know what its supposed to do. >> >> What it tries to do is assign a pointer to an array of int to a >> pointer to an int. > Well thats just wrong because the pointer types are different levels if > indirection. You convert an array into a pointer like so : > int arr[5]; > int* p = arr; It is good to see that you now understand that trying assign a pointer to an array of int to a pointer to an int is wrong. When the array name in the initialization expression is converted to is a pointer to an int, not a pointer to an array of int. > You don't take the address of an array , unless you want a different level > of indirection. Arrays are implicitly converted to pointers. You take the address of an array when you want a pointer to that array. >> The fact that it is not allowed by the C++ >> standard demonstrates that a pointer to an int cannot not point >> to an array of int. > It is allowed but it needs a cast. Using a cast changes the type of a value. If the cast is to something other than a pointer to an array of int, the value on the left hand side of the assignment is no longer from a pointer to an array of int. >> It can point to an element of an array of int. >> The statement >> >> pi = &((*pai)[0]); >> >> is allowed. It assigns a pointer to an element of an array of int >> to a pointer to an int. >> > You are either deliberately or unknowingly writing bad code. There is nothing bad about the statement, it assigns a pointer to the first element of an array of int to a pointer to an int. Evaluating it starts with pai, a pointer to an array; (*pai) is that array; (*pai)[0] is the first element of that array; &((*pai)[0]) is a pointer to the element; pi = &((*pai)[0]) sets pi to that pointer. >>>> The relevant sections of the standard for the statement >>>> >>>> pi = pai; >>>> >>>> where pi and pai are declared with >>>> >>>> int *pi, (*pai)[1]; >>>> >>>> are the one about assignment operators (5.17) and the one about >>>> implict conversions (4) that it refers to. According to those >>>> sections, that assignment, which tries have a pointer to int point >>>> to an array, is not allowed. If pi and pai had the same type, the >>>> assignment would be allowed. >>> What is this nonsense about , your code is trash dude and you can't even >>> accept what is really the relevant sections of the standard, the sections >>> about arrays. >> >> The fact that C++ compilers reject the code demonstrates that a >> pointer to an array of int cannot be assigned to a pointer to int. >> In other words, a pointer to int cannot point to an array of int. >> What paragraph of the C++ standard states otherwise? >> > Its your code that is rejected by compilers so its your understanding that > must be wrong. As far as I can tell my understanding is correct. pi is a pointer an int and pai is a pointer to an array of int. If a pointer to an int could point to a pointer to an array of int, the statement would be allowed. >>>>> I fully understand the difference between the types: >>>>> int(*)[size] and int*. >>>>> I also understand that both can point to arrays, you cannot understand >>>>> this >>>>> though . You think only one type can point to an array which is ofc >>>>> against >>>>> the views of all the C++ experts. >>>> >>>> If you fully understood the difference between those types in C++, >>>> you would understand that a pointer to int cannot point to an array >>>> of int. A term, such as "point to", used in the context of a >>>> a programming language does not necessarily have the same meaning >>>> that it has in other contexts. >>> As you refuse to accept all reason and common sense I can only appeal to >>> authority. If people like Bjarne Stroustrup say that an int* can point to >>> a >>> single int or an array of int, and you say otherwise, who are we to >>> believe >>> is correct? You or Bjarne Stroustrup? >> >> No one needs to believe anything that is not supported by what is >> in the C++ standard or by compliers that comply to the standard. >> Given the declaraion >> >> int *pi, (*pai)[1]; >> >> the statement >> >> pi = pai; >> >> which attempts to have a pointer to an int point to the array of int >> (pointed to by the variable pai) is not allowed. C++ compilers will >> issue a diagnosic message for the assignment statement. > > That piece of bad code you have produced somehow suggests that Bjarne > Stroustrup is wrong does it? It does not suggest that Bjarne Stroustrup is wrong, unless he said that assigning a pointer to array of int to a pointer to int is allowed in C++. As far as I know, he has never said that. >>> If the C++ standard states that , when dereferenced, an array(or pointer >>> to >>> an array) returns the pointed to (n-1)dimension array. Then who are we >>> to >>> believe, you or the C++ standard? >> >> Right, in the statement >> >> int a2i[3][5], (*pa1i)[5] = a2i; >> >> evaluating a2i in the initialization expression returns a pointer to >> a 1-dimensional array. After the initialization pa1i points to that >> 1-dimensional array, not to a 2-dimensional array. > > a2i is implicitly converted to a pointer. The pointed to array is a 2d > array, not a 1dim array. Where the above standards quote applies is if you > derefernece either a2i or pa1i, eg: > *pa1i; > or > pa1i[0]; > This is dereferencing the pointer to the array, and the results of this > dereference is an array of (n-1) dimensions , eg: > int[5]; > As you can see the standard agrees perfectly with my interpretation. According to the standard, a2i in the initialization expression is converted to a pointer to a 1-dimension array, not a 2-dimensional array. Paragraph 7 of section 8.3.4 of the standard is: A consistent rule is followed for multidimensional arrays. If E is an n-dimensional array of rank ixjx...xk, then E appearing in an expression is converted to a pointer to an (n - 1)-dimensional array with rank jx...xk. If the * operator, either explicitly or implicitly as a result of subscripting, is applied to this pointer, the result is the pointed to (n - 1)-dimensional array, which itself is immediately converted into a pointer. > If you take pa1i and consider it a pointer to a 1d array, this fails > because *pa1i does not produce the pointed to (n-1) dimensional array, which > would be a single int( a zero dim array). Nothing fails here by considering pa1i to be a pointer to a 1-dimensional array, which is what it is. Evaluating *pa1i results in a 1-dimensional array, which is implicitly converted to a pointer to the first element of that array. > You are creating another level of indirection, because arr already is(or > converts to) a pointer, under the hood. You compare this with a pointer to a > non array object, eg: > int arr[6]; > int (*p)[6] = &arr; /*Taking address of a pointer.*/ > int x =5; > int* p_x=&x; /*Creating a pointer */ > You think the above is the same but its not, what you are doing is similar > to this: > int** pp = &p_x; /*Taking address of a pointer*/ The only difference between the initialization of p and p_x are their types. Due to the initializatons, the expression (*p)[i] is equivalent to arr[i]; the expression *p_x is equivalent to x. All those expressions evaluate to an int. Taking the address of something of type T results in a pointer to type T. Dereferencing that pointer results in the thing whose address was taken. With pp there is another level of indirection from an int. The expression *pp evaluates to a pointer to an int. The expression **pp evaluates to an int. p_x is an additional object between pp and the int that is the result of evaluating x. There is no corresponding additional object with p. Just because the name of an array when used in an expression evaluates to a pointer to the first element of the array does not mean that an array is a pointer. An external declaration of *arr in one file does not correctly refer to an external definition of arr[] in another file. [snip] > I have answered any questins you have asked. You have not answered the question: exactly where in the C++ standard is a statement that a pointer of another type can "point to an array", as opposed to a pointer whose type is the same as an array element type being able to point to an element of that array? What paragraph of what section?
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-05 19:13 +0100 |
| Message-ID | <YZImp.2816$Ir.2646@newsfe13.ams2> |
| In reply to | #3175 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message news:slrnipmktl.1eov.aggedor@earl-grey.cloud9.net... > On 2011-04-04, Paul <pchristor@yahoo.co.uk> wrote: >> >> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message >> news:slrnipk0n8.260.aggedor@earl-grey.cloud9.net... >>> On 2011-04-02, Paul <pchristor@yahoo.co.uk> wrote: >>>> >>>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message >>>> news:slrnipc3gd.6l7.aggedor@earl-grey.cloud9.net... >>>>> On 2011-03-31, Paul <pchristor@yahoo.co.uk> wrote: > > [snip] > >> I'm saying they are all arrays of the same type i.e: >> int arr1[3][4]; /*Array of int type*/ >> int arr2[6]; /*Array of int*/ >> int* p1 = new int[5]; /*Array of int*/ >> int (*p2)[6] = new int[5][6]; /*Array of int*/ >> >> They are all int-type arrays and the identifier in each case, no matter >> what >> type that is, points to an array of int. > > Actually, arr1 is a 2-dimensional array of int, p1 is a pointer to > int, new int[5] returns a pointer to an int, p2 is a pointer to an > array of int, and new int[5][6] returns a pointer to a > 1-dimensional array of int. p1 and p2 are pointers, not arrays. > > Here is a example from section 8.1 (Type Names) of the C++ standard > > int // int i > int * // int *pi > int *[3] // int *p[3] > int (*)[3] // int (*p3i)[3] > int *() // int *f() > int (*)(double) // int (*pf)(double) > > name respectively the types "int," "pointer to int," "array of 3 > pointers to int," "pointer to array of 3 int," "function of (no > parameters) returning pointer to int," and "pointer to a function > of (double) returning int. > > Here is a note from paragraph 5 of section 5.3.4 (New) of the C++ > standard: "Note: both new int and new int[10] have type int* and > the type of new int[i][10] is int (*)[10]." > > [snip] >>> A pointer to an int and a pointer to an >>> array of int are different types. >> No they're not. Your thinking about pointer types, not what is pointed >> to. I >> have already said a pointer type doesn't define what is pointed to but I >> will repeat it. > > If a pointer to an int and a pointer to an array of int were the > same type, then the statement > > int (*pai)[1], *pa = pai; > > would be allowed, but it isn't. A compiler I use gives the message > "error: cannot convert 'int (*)[1]' to 'int*' in initialization". > An attempt is being made to convert a pointer to an array of int to > a pointer to an int. > >>> It is not a matter of common sense; >>> it is a matter of what the term "points to" means in C++. Here is >>> paragraph 1 of section 5.3.1 of the C++ standard: >> I know what points to means I dont need to reference the standard to find >> out. > > You need to reference the C++ standard to understand what a term > means in the C++ programming language. > >>> The unary * operator performs indirection: the expression to which >>> it is applied shall be a pointer to an object type, or a pointer >>> to a function type and the result is an lvalue referring to the >>> object or function to which the expression points. If the type of >>> the expression is pointer to T, the type of the result is T. >>> [Note: a pointer to an incomplete type (other than cv void ) can >>> be dereferenced. The lvalue thus obtained can be used in limited >>> ways (to initialize a reference, for example); this lvalue must >>> not be converted to an rvalue, see 4.1.] >>> >>> According to the C++ standard, the pointer type determines the >>> type of the result of dereferencing the pointer >>> >> So the C++ standards are relevant now when talking about dereferencing >> pointers? >> If you read the above in conjuction with the relevant section on arrays >> you >> will understand. > > A section of the C++ standard about dereferencing a pointer is > relevant to a statement in which a pointer is dereferenced. The > same section is not relevant to a statement in which a pointer is > not dereferenced. > >>>>> A pointer to an int may point to any int, including one that is an >>>>> element of an array of int. However, when pointing to an element of >>>>> an array of int it is pointing to an int, not an array. When you >>>>> dereference the pointer the result is an int, not an array. >>>> This is where you lose all sense of logic, a pointer to an entity >>>> points >>>> exactly to that entity. The pointer type does not define the pointed to >>>> entity. >>> >>> According the the C++ standard, see the preceeding quote from the >>> standard, the type of the result of dereferencing a pointer depends >>> on the type of the pointer. The result type does not depend on the >>> type used when the object was allocated. >>> >> This does not mean the an int* cannot point to an array, If you read the >> standards properly you will understand why a pointer to an array must >> point >> to , the pointed to (n-1) diemnsional array. > > That's right, the quote from the standard is about the unary * > operator It is not relevant to whether an int* can point to > an array. A pointer to an array points to an array of the number > of dimensions in the pointer type, not to an array of one fewer > dimensions. For example, > > int (*p2i)[3][5] > > declares a pointer to a 2-dimensional array, not to a 1-dimensional > array. > >> And I though you said the standards were irellevant because we were not >> talking aobut dereferencing a pointer. > > I said that a part of the standard about dereferencing is not > relevant to a statement, such as > > int *p = new int[4]; > > in which there is no dereferencing. A part of the standard about > dereferencing is relevant to a statement in which there is a > dereference operation. > >>>>>>> A pointer to the first element of the array is not the same as a >>>>>>> pointer >>>>>>> to >>>>>>> the array. The former has type pointer to T, that latter has type >>>>>>> pointer >>>>>>> to array of N T. If they were the same, given the declaration >>>>>> A pointer to the first element of an array, is a pointer to the >>>>>> array. >>>>>> >>>>>>> int *pi, (*pai)[1]; >>>>>>> >>>>>>> the assignment >>>>>>> >>>>>>> pi = pai; >>>>>>> >>>>>>> would be allowed, but it is not allowed. >>>>>> You obviously do not understand the difference in level sof >>>>>> indirection. >>>>> >>>>> What C++ compiler have you used that does not give a diagnostic >>>>> message about the assignment statement? >>>> Your code is just wrong. I don't know what its supposed to do. >>> >>> What it tries to do is assign a pointer to an array of int to a >>> pointer to an int. >> Well thats just wrong because the pointer types are different levels if >> indirection. You convert an array into a pointer like so : >> int arr[5]; >> int* p = arr; > > It is good to see that you now understand that trying assign a > pointer to an array of int to a pointer to an int is wrong. When > the array name in the initialization expression is converted to is > a pointer to an int, not a pointer to an array of int. > >> You don't take the address of an array , unless you want a different >> level >> of indirection. Arrays are implicitly converted to pointers. > > You take the address of an array when you want a pointer to that array. > >>> The fact that it is not allowed by the C++ >>> standard demonstrates that a pointer to an int cannot not point >>> to an array of int. >> It is allowed but it needs a cast. > > Using a cast changes the type of a value. If the cast is to > something other than a pointer to an array of int, the value on > the left hand side of the assignment is no longer from a > pointer to an array of int. > >>> It can point to an element of an array of int. >>> The statement >>> >>> pi = &((*pai)[0]); >>> >>> is allowed. It assigns a pointer to an element of an array of int >>> to a pointer to an int. >>> >> You are either deliberately or unknowingly writing bad code. > > There is nothing bad about the statement, it assigns a pointer to > the first element of an array of int to a pointer to an int. > Evaluating it starts with pai, a pointer to an array; (*pai) is > that array; (*pai)[0] is the first element of that array; > &((*pai)[0]) is a pointer to the element; pi = &((*pai)[0]) sets > pi to that pointer. > >>>>> The relevant sections of the standard for the statement >>>>> >>>>> pi = pai; >>>>> >>>>> where pi and pai are declared with >>>>> >>>>> int *pi, (*pai)[1]; >>>>> >>>>> are the one about assignment operators (5.17) and the one about >>>>> implict conversions (4) that it refers to. According to those >>>>> sections, that assignment, which tries have a pointer to int point >>>>> to an array, is not allowed. If pi and pai had the same type, the >>>>> assignment would be allowed. >>>> What is this nonsense about , your code is trash dude and you can't >>>> even >>>> accept what is really the relevant sections of the standard, the >>>> sections >>>> about arrays. >>> >>> The fact that C++ compilers reject the code demonstrates that a >>> pointer to an array of int cannot be assigned to a pointer to int. >>> In other words, a pointer to int cannot point to an array of int. >>> What paragraph of the C++ standard states otherwise? >>> >> Its your code that is rejected by compilers so its your understanding >> that >> must be wrong. > > As far as I can tell my understanding is correct. pi is a pointer > an int and pai is a pointer to an array of int. If a pointer to an > int could point to a pointer to an array of int, the statement would > be allowed. > >>>>>> I fully understand the difference between the types: >>>>>> int(*)[size] and int*. >>>>>> I also understand that both can point to arrays, you cannot >>>>>> understand >>>>>> this >>>>>> though . You think only one type can point to an array which is ofc >>>>>> against >>>>>> the views of all the C++ experts. >>>>> >>>>> If you fully understood the difference between those types in C++, >>>>> you would understand that a pointer to int cannot point to an array >>>>> of int. A term, such as "point to", used in the context of a >>>>> a programming language does not necessarily have the same meaning >>>>> that it has in other contexts. >>>> As you refuse to accept all reason and common sense I can only appeal >>>> to >>>> authority. If people like Bjarne Stroustrup say that an int* can point >>>> to >>>> a >>>> single int or an array of int, and you say otherwise, who are we to >>>> believe >>>> is correct? You or Bjarne Stroustrup? >>> >>> No one needs to believe anything that is not supported by what is >>> in the C++ standard or by compliers that comply to the standard. >>> Given the declaraion >>> >>> int *pi, (*pai)[1]; >>> >>> the statement >>> >>> pi = pai; >>> >>> which attempts to have a pointer to an int point to the array of int >>> (pointed to by the variable pai) is not allowed. C++ compilers will >>> issue a diagnosic message for the assignment statement. >> >> That piece of bad code you have produced somehow suggests that Bjarne >> Stroustrup is wrong does it? > > It does not suggest that Bjarne Stroustrup is wrong, unless he > said that assigning a pointer to array of int to a pointer to int > is allowed in C++. As far as I know, he has never said that. > >>>> If the C++ standard states that , when dereferenced, an array(or >>>> pointer >>>> to >>>> an array) returns the pointed to (n-1)dimension array. Then who are we >>>> to >>>> believe, you or the C++ standard? >>> >>> Right, in the statement >>> >>> int a2i[3][5], (*pa1i)[5] = a2i; >>> >>> evaluating a2i in the initialization expression returns a pointer to >>> a 1-dimensional array. After the initialization pa1i points to that >>> 1-dimensional array, not to a 2-dimensional array. >> >> a2i is implicitly converted to a pointer. The pointed to array is a 2d >> array, not a 1dim array. Where the above standards quote applies is if >> you >> derefernece either a2i or pa1i, eg: >> *pa1i; >> or >> pa1i[0]; >> This is dereferencing the pointer to the array, and the results of this >> dereference is an array of (n-1) dimensions , eg: >> int[5]; >> As you can see the standard agrees perfectly with my interpretation. > > According to the standard, a2i in the initialization expression is > converted to a pointer to a 1-dimension array, not a 2-dimensional > array. Paragraph 7 of section 8.3.4 of the standard is: > > A consistent rule is followed for multidimensional arrays. If E > is an n-dimensional array of rank ixjx...xk, then E appearing in > an expression is converted to a pointer to an (n - 1)-dimensional > array with rank jx...xk. If the * operator, either explicitly or > implicitly as a result of subscripting, is applied to this pointer, > the result is the pointed to (n - 1)-dimensional array, which > itself is immediately converted into a pointer. > >> If you take pa1i and consider it a pointer to a 1d array, this fails >> because *pa1i does not produce the pointed to (n-1) dimensional array, >> which >> would be a single int( a zero dim array). > > Nothing fails here by considering pa1i to be a pointer to a > 1-dimensional array, which is what it is. Evaluating *pa1i results > in a 1-dimensional array, which is implicitly converted to a pointer > to the first element of that array. > >> You are creating another level of indirection, because arr already is(or >> converts to) a pointer, under the hood. You compare this with a pointer >> to a >> non array object, eg: >> int arr[6]; >> int (*p)[6] = &arr; /*Taking address of a pointer.*/ >> int x =5; >> int* p_x=&x; /*Creating a pointer */ >> You think the above is the same but its not, what you are doing is >> similar >> to this: >> int** pp = &p_x; /*Taking address of a pointer*/ > > The only difference between the initialization of p and p_x are > their types. Due to the initializatons, the expression (*p)[i] > is equivalent to arr[i]; the expression *p_x is equivalent to x. > All those expressions evaluate to an int. > > Taking the address of something of type T results in a pointer to > type T. Dereferencing that pointer results in the thing whose > address was taken. > > With pp there is another level of indirection from an int. The > expression *pp evaluates to a pointer to an int. The expression > **pp evaluates to an int. p_x is an additional object between > pp and the int that is the result of evaluating x. There is no > corresponding additional object with p. > > Just because the name of an array when used in an expression > evaluates to a pointer to the first element of the array does not > mean that an array is a pointer. An external declaration of *arr > in one file does not correctly refer to an external definition of > arr[] in another file. > > [snip] > >> I have answered any questins you have asked. > > You have not answered the question: exactly where in the C++ > standard is a statement that a pointer of another type can > "point to an array", as opposed to a pointer whose type is the > same as an array element type being able to point to an > element of that array? What paragraph of what section? I've already explained how it works if you don't understand then thats your issue. GL. I can't be bothered arguing abvout anymore especially when you refuse to accept the relevent quotes from standards
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-05 20:16 +0100 |
| Message-ID | <BUJmp.23172$Hl6.11021@newsfe23.ams2> |
| In reply to | #3175 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message news:slrnipmktl.1eov.aggedor@earl-grey.cloud9.net... > On 2011-04-04, Paul <pchristor@yahoo.co.uk> wrote: >> >> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message >> news:slrnipk0n8.260.aggedor@earl-grey.cloud9.net... >>> On 2011-04-02, Paul <pchristor@yahoo.co.uk> wrote: >>>> >>>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message >>>> news:slrnipc3gd.6l7.aggedor@earl-grey.cloud9.net... >>>>> On 2011-03-31, Paul <pchristor@yahoo.co.uk> wrote: > > [snip] > >> I'm saying they are all arrays of the same type i.e: >> int arr1[3][4]; /*Array of int type*/ >> int arr2[6]; /*Array of int*/ >> int* p1 = new int[5]; /*Array of int*/ >> int (*p2)[6] = new int[5][6]; /*Array of int*/ >> >> They are all int-type arrays and the identifier in each case, no matter >> what >> type that is, points to an array of int. > > Actually, arr1 is a 2-dimensional array of int, p1 is a pointer to > int, new int[5] returns a pointer to an int, p2 is a pointer to an > array of int, and new int[5][6] returns a pointer to a > 1-dimensional array of int. p1 and p2 are pointers, not arrays. > > Here is a example from section 8.1 (Type Names) of the C++ standard > > int // int i > int * // int *pi > int *[3] // int *p[3] > int (*)[3] // int (*p3i)[3] > int *() // int *f() > int (*)(double) // int (*pf)(double) > > name respectively the types "int," "pointer to int," "array of 3 > pointers to int," "pointer to array of 3 int," "function of (no > parameters) returning pointer to int," and "pointer to a function > of (double) returning int. > > Here is a note from paragraph 5 of section 5.3.4 (New) of the C++ > standard: "Note: both new int and new int[10] have type int* and > the type of new int[i][10] is int (*)[10]." > > [snip] >>> A pointer to an int and a pointer to an >>> array of int are different types. >> No they're not. Your thinking about pointer types, not what is pointed >> to. I >> have already said a pointer type doesn't define what is pointed to but I >> will repeat it. > > If a pointer to an int and a pointer to an array of int were the > same type, then the statement > > int (*pai)[1], *pa = pai; > > would be allowed, but it isn't. A compiler I use gives the message > "error: cannot convert 'int (*)[1]' to 'int*' in initialization". > An attempt is being made to convert a pointer to an array of int to > a pointer to an int. > >>> It is not a matter of common sense; >>> it is a matter of what the term "points to" means in C++. Here is >>> paragraph 1 of section 5.3.1 of the C++ standard: >> I know what points to means I dont need to reference the standard to find >> out. > > You need to reference the C++ standard to understand what a term > means in the C++ programming language. > >>> The unary * operator performs indirection: the expression to which >>> it is applied shall be a pointer to an object type, or a pointer >>> to a function type and the result is an lvalue referring to the >>> object or function to which the expression points. If the type of >>> the expression is pointer to T, the type of the result is T. >>> [Note: a pointer to an incomplete type (other than cv void ) can >>> be dereferenced. The lvalue thus obtained can be used in limited >>> ways (to initialize a reference, for example); this lvalue must >>> not be converted to an rvalue, see 4.1.] >>> >>> According to the C++ standard, the pointer type determines the >>> type of the result of dereferencing the pointer >>> >> So the C++ standards are relevant now when talking about dereferencing >> pointers? >> If you read the above in conjuction with the relevant section on arrays >> you >> will understand. > > A section of the C++ standard about dereferencing a pointer is > relevant to a statement in which a pointer is dereferenced. The > same section is not relevant to a statement in which a pointer is > not dereferenced. > >>>>> A pointer to an int may point to any int, including one that is an >>>>> element of an array of int. However, when pointing to an element of >>>>> an array of int it is pointing to an int, not an array. When you >>>>> dereference the pointer the result is an int, not an array. >>>> This is where you lose all sense of logic, a pointer to an entity >>>> points >>>> exactly to that entity. The pointer type does not define the pointed to >>>> entity. >>> >>> According the the C++ standard, see the preceeding quote from the >>> standard, the type of the result of dereferencing a pointer depends >>> on the type of the pointer. The result type does not depend on the >>> type used when the object was allocated. >>> >> This does not mean the an int* cannot point to an array, If you read the >> standards properly you will understand why a pointer to an array must >> point >> to , the pointed to (n-1) diemnsional array. > > That's right, the quote from the standard is about the unary * > operator It is not relevant to whether an int* can point to > an array. A pointer to an array points to an array of the number > of dimensions in the pointer type, not to an array of one fewer > dimensions. For example, > > int (*p2i)[3][5] > > declares a pointer to a 2-dimensional array, not to a 1-dimensional > array. > >> And I though you said the standards were irellevant because we were not >> talking aobut dereferencing a pointer. > > I said that a part of the standard about dereferencing is not > relevant to a statement, such as > > int *p = new int[4]; > > in which there is no dereferencing. A part of the standard about > dereferencing is relevant to a statement in which there is a > dereference operation. > >>>>>>> A pointer to the first element of the array is not the same as a >>>>>>> pointer >>>>>>> to >>>>>>> the array. The former has type pointer to T, that latter has type >>>>>>> pointer >>>>>>> to array of N T. If they were the same, given the declaration >>>>>> A pointer to the first element of an array, is a pointer to the >>>>>> array. >>>>>> >>>>>>> int *pi, (*pai)[1]; >>>>>>> >>>>>>> the assignment >>>>>>> >>>>>>> pi = pai; >>>>>>> >>>>>>> would be allowed, but it is not allowed. >>>>>> You obviously do not understand the difference in level sof >>>>>> indirection. >>>>> >>>>> What C++ compiler have you used that does not give a diagnostic >>>>> message about the assignment statement? >>>> Your code is just wrong. I don't know what its supposed to do. >>> >>> What it tries to do is assign a pointer to an array of int to a >>> pointer to an int. >> Well thats just wrong because the pointer types are different levels if >> indirection. You convert an array into a pointer like so : >> int arr[5]; >> int* p = arr; > > It is good to see that you now understand that trying assign a > pointer to an array of int to a pointer to an int is wrong. When > the array name in the initialization expression is converted to is > a pointer to an int, not a pointer to an array of int. > >> You don't take the address of an array , unless you want a different >> level >> of indirection. Arrays are implicitly converted to pointers. > > You take the address of an array when you want a pointer to that array. > >>> The fact that it is not allowed by the C++ >>> standard demonstrates that a pointer to an int cannot not point >>> to an array of int. >> It is allowed but it needs a cast. > > Using a cast changes the type of a value. If the cast is to > something other than a pointer to an array of int, the value on > the left hand side of the assignment is no longer from a > pointer to an array of int. > >>> It can point to an element of an array of int. >>> The statement >>> >>> pi = &((*pai)[0]); >>> >>> is allowed. It assigns a pointer to an element of an array of int >>> to a pointer to an int. >>> >> You are either deliberately or unknowingly writing bad code. > > There is nothing bad about the statement, it assigns a pointer to > the first element of an array of int to a pointer to an int. > Evaluating it starts with pai, a pointer to an array; (*pai) is > that array; (*pai)[0] is the first element of that array; > &((*pai)[0]) is a pointer to the element; pi = &((*pai)[0]) sets > pi to that pointer. > >>>>> The relevant sections of the standard for the statement >>>>> >>>>> pi = pai; >>>>> >>>>> where pi and pai are declared with >>>>> >>>>> int *pi, (*pai)[1]; >>>>> >>>>> are the one about assignment operators (5.17) and the one about >>>>> implict conversions (4) that it refers to. According to those >>>>> sections, that assignment, which tries have a pointer to int point >>>>> to an array, is not allowed. If pi and pai had the same type, the >>>>> assignment would be allowed. >>>> What is this nonsense about , your code is trash dude and you can't >>>> even >>>> accept what is really the relevant sections of the standard, the >>>> sections >>>> about arrays. >>> >>> The fact that C++ compilers reject the code demonstrates that a >>> pointer to an array of int cannot be assigned to a pointer to int. >>> In other words, a pointer to int cannot point to an array of int. >>> What paragraph of the C++ standard states otherwise? >>> >> Its your code that is rejected by compilers so its your understanding >> that >> must be wrong. > > As far as I can tell my understanding is correct. pi is a pointer > an int and pai is a pointer to an array of int. If a pointer to an > int could point to a pointer to an array of int, the statement would > be allowed. > >>>>>> I fully understand the difference between the types: >>>>>> int(*)[size] and int*. >>>>>> I also understand that both can point to arrays, you cannot >>>>>> understand >>>>>> this >>>>>> though . You think only one type can point to an array which is ofc >>>>>> against >>>>>> the views of all the C++ experts. >>>>> >>>>> If you fully understood the difference between those types in C++, >>>>> you would understand that a pointer to int cannot point to an array >>>>> of int. A term, such as "point to", used in the context of a >>>>> a programming language does not necessarily have the same meaning >>>>> that it has in other contexts. >>>> As you refuse to accept all reason and common sense I can only appeal >>>> to >>>> authority. If people like Bjarne Stroustrup say that an int* can point >>>> to >>>> a >>>> single int or an array of int, and you say otherwise, who are we to >>>> believe >>>> is correct? You or Bjarne Stroustrup? >>> >>> No one needs to believe anything that is not supported by what is >>> in the C++ standard or by compliers that comply to the standard. >>> Given the declaraion >>> >>> int *pi, (*pai)[1]; >>> >>> the statement >>> >>> pi = pai; >>> >>> which attempts to have a pointer to an int point to the array of int >>> (pointed to by the variable pai) is not allowed. C++ compilers will >>> issue a diagnosic message for the assignment statement. >> >> That piece of bad code you have produced somehow suggests that Bjarne >> Stroustrup is wrong does it? > > It does not suggest that Bjarne Stroustrup is wrong, unless he > said that assigning a pointer to array of int to a pointer to int > is allowed in C++. As far as I know, he has never said that. > >>>> If the C++ standard states that , when dereferenced, an array(or >>>> pointer >>>> to >>>> an array) returns the pointed to (n-1)dimension array. Then who are we >>>> to >>>> believe, you or the C++ standard? >>> >>> Right, in the statement >>> >>> int a2i[3][5], (*pa1i)[5] = a2i; >>> >>> evaluating a2i in the initialization expression returns a pointer to >>> a 1-dimensional array. After the initialization pa1i points to that >>> 1-dimensional array, not to a 2-dimensional array. >> >> a2i is implicitly converted to a pointer. The pointed to array is a 2d >> array, not a 1dim array. Where the above standards quote applies is if >> you >> derefernece either a2i or pa1i, eg: >> *pa1i; >> or >> pa1i[0]; >> This is dereferencing the pointer to the array, and the results of this >> dereference is an array of (n-1) dimensions , eg: >> int[5]; >> As you can see the standard agrees perfectly with my interpretation. > > According to the standard, a2i in the initialization expression is > converted to a pointer to a 1-dimension array, not a 2-dimensional > array. Paragraph 7 of section 8.3.4 of the standard is: > > A consistent rule is followed for multidimensional arrays. If E > is an n-dimensional array of rank ixjx...xk, then E appearing in > an expression is converted to a pointer to an (n - 1)-dimensional > array with rank jx...xk. If the * operator, either explicitly or > implicitly as a result of subscripting, is applied to this pointer, > the result is the pointed to (n - 1)-dimensional array, which > itself is immediately converted into a pointer. > >> If you take pa1i and consider it a pointer to a 1d array, this fails >> because *pa1i does not produce the pointed to (n-1) dimensional array, >> which >> would be a single int( a zero dim array). > > Nothing fails here by considering pa1i to be a pointer to a > 1-dimensional array, which is what it is. Evaluating *pa1i results > in a 1-dimensional array, One final thing , that does fail because it doesn'tt comply with the rules. A pointed to (n-1) dim array, cannot be the same for a 1dim and 2dim array. (2-1) != (1-1) <snip> <snip>
[toc] | [prev] | [next] | [standalone]
| From | Garrett Hartshaw <ghartshaw@gmail.com> |
|---|---|
| Date | 2011-04-06 01:36 -0400 |
| Message-ID | <almarsoft.8616384651225967946@nntp.aioe.org> |
| In reply to | #3184 |
On Tue, 5 Apr 2011 20:16:29 +0100, "Paul" <pchristor@yahoo.co.uk> wrote: > "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message > news:slrnipmktl.1eov.aggedor@earl-grey.cloud9.net... > > On 2011-04-04, Paul <pchristor@yahoo.co.uk> wrote: > >> > >> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message > >> news:slrnipk0n8.260.aggedor@earl-grey.cloud9.net... > >>> On 2011-04-02, Paul <pchristor@yahoo.co.uk> wrote: > >>>> > >>>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message > >>>> news:slrnipc3gd.6l7.aggedor@earl-grey.cloud9.net... > >>>>> On 2011-03-31, Paul <pchristor@yahoo.co.uk> wrote: > > > > [snip] > > > >> I'm saying they are all arrays of the same type i.e: > >> int arr1[3][4]; /*Array of int type*/ > >> int arr2[6]; /*Array of int*/ > >> int* p1 = new int[5]; /*Array of int*/ > >> int (*p2)[6] = new int[5][6]; /*Array of int*/ > >> > >> They are all int-type arrays and the identifier in each case, no matter > >> what > >> type that is, points to an array of int. > > > > Actually, arr1 is a 2-dimensional array of int, p1 is a pointer to > > int, new int[5] returns a pointer to an int, p2 is a pointer to an > > array of int, and new int[5][6] returns a pointer to a > > 1-dimensional array of int. p1 and p2 are pointers, not arrays. > > > > Here is a example from section 8.1 (Type Names) of the C++ standard > > > > int // int i > > int * // int *pi > > int *[3] // int *p[3] > > int (*)[3] // int (*p3i)[3] > > int *() // int *f() > > int (*)(double) // int (*pf)(double) > > > > name respectively the types "int," "pointer to int," "array of 3 > > pointers to int," "pointer to array of 3 int," "function of (no > > parameters) returning pointer to int," and "pointer to a function > > of (double) returning int. > > > > Here is a note from paragraph 5 of section 5.3.4 (New) of the C++ > > standard: "Note: both new int and new int[10] have type int* and > > the type of new int[i][10] is int (*)[10]." > > > > [snip] > >>> A pointer to an int and a pointer to an > >>> array of int are different types. > >> No they're not. Your thinking about pointer types, not what is pointed > >> to. I > >> have already said a pointer type doesn't define what is pointed to but I > >> will repeat it. > > > > If a pointer to an int and a pointer to an array of int were the > > same type, then the statement > > > > int (*pai)[1], *pa = pai; > > > > would be allowed, but it isn't. A compiler I use gives the message > > "error: cannot convert 'int (*)[1]' to 'int*' in initialization". > > An attempt is being made to convert a pointer to an array of int to > > a pointer to an int. > > > >>> It is not a matter of common sense; > >>> it is a matter of what the term "points to" means in C++. Here is > >>> paragraph 1 of section 5.3.1 of the C++ standard: > >> I know what points to means I dont need to reference the standard to find > >> out. > > > > You need to reference the C++ standard to understand what a term > > means in the C++ programming language. > > > >>> The unary * operator performs indirection: the expression to which > >>> it is applied shall be a pointer to an object type, or a pointer > >>> to a function type and the result is an lvalue referring to the > >>> object or function to which the expression points. If the type of > >>> the expression is pointer to T, the type of the result is T. > >>> [Note: a pointer to an incomplete type (other than cv void ) can > >>> be dereferenced. The lvalue thus obtained can be used in limited > >>> ways (to initialize a reference, for example); this lvalue must > >>> not be converted to an rvalue, see 4.1.] > >>> > >>> According to the C++ standard, the pointer type determines the > >>> type of the result of dereferencing the pointer > >>> > >> So the C++ standards are relevant now when talking about dereferencing > >> pointers? > >> If you read the above in conjuction with the relevant section on arrays > >> you > >> will understand. > > > > A section of the C++ standard about dereferencing a pointer is > > relevant to a statement in which a pointer is dereferenced. The > > same section is not relevant to a statement in which a pointer is > > not dereferenced. > > > >>>>> A pointer to an int may point to any int, including one that is an > >>>>> element of an array of int. However, when pointing to an element of > >>>>> an array of int it is pointing to an int, not an array. When you > >>>>> dereference the pointer the result is an int, not an array. > >>>> This is where you lose all sense of logic, a pointer to an entity > >>>> points > >>>> exactly to that entity. The pointer type does not define the pointed to > >>>> entity. > >>> > >>> According the the C++ standard, see the preceeding quote from the > >>> standard, the type of the result of dereferencing a pointer depends > >>> on the type of the pointer. The result type does not depend on the > >>> type used when the object was allocated. > >>> > >> This does not mean the an int* cannot point to an array, If you read the > >> standards properly you will understand why a pointer to an array must > >> point > >> to , the pointed to (n-1) diemnsional array. > > > > That's right, the quote from the standard is about the unary * > > operator It is not relevant to whether an int* can point to > > an array. A pointer to an array points to an array of the number > > of dimensions in the pointer type, not to an array of one fewer > > dimensions. For example, > > > > int (*p2i)[3][5] > > > > declares a pointer to a 2-dimensional array, not to a 1-dimensional > > array. > > > >> And I though you said the standards were irellevant because we were not > >> talking aobut dereferencing a pointer. > > > > I said that a part of the standard about dereferencing is not > > relevant to a statement, such as > > > > int *p = new int[4]; > > > > in which there is no dereferencing. A part of the standard about > > dereferencing is relevant to a statement in which there is a > > dereference operation. > > > >>>>>>> A pointer to the first element of the array is not the same as a > >>>>>>> pointer > >>>>>>> to > >>>>>>> the array. The former has type pointer to T, that latter has type > >>>>>>> pointer > >>>>>>> to array of N T. If they were the same, given the declaration > >>>>>> A pointer to the first element of an array, is a pointer to the > >>>>>> array. > >>>>>> > >>>>>>> int *pi, (*pai)[1]; > >>>>>>> > >>>>>>> the assignment > >>>>>>> > >>>>>>> pi = pai; > >>>>>>> > >>>>>>> would be allowed, but it is not allowed. > >>>>>> You obviously do not understand the difference in level sof > >>>>>> indirection. > >>>>> > >>>>> What C++ compiler have you used that does not give a diagnostic > >>>>> message about the assignment statement? > >>>> Your code is just wrong. I don't know what its supposed to do. > >>> > >>> What it tries to do is assign a pointer to an array of int to a > >>> pointer to an int. > >> Well thats just wrong because the pointer types are different levels if > >> indirection. You convert an array into a pointer like so : > >> int arr[5]; > >> int* p = arr; > > > > It is good to see that you now understand that trying assign a > > pointer to an array of int to a pointer to an int is wrong. When > > the array name in the initialization expression is converted to is > > a pointer to an int, not a pointer to an array of int. > > > >> You don't take the address of an array , unless you want a different > >> level > >> of indirection. Arrays are implicitly converted to pointers. > > > > You take the address of an array when you want a pointer to that array. > > > >>> The fact that it is not allowed by the C++ > >>> standard demonstrates that a pointer to an int cannot not point > >>> to an array of int. > >> It is allowed but it needs a cast. > > > > Using a cast changes the type of a value. If the cast is to > > something other than a pointer to an array of int, the value on > > the left hand side of the assignment is no longer from a > > pointer to an array of int. > > > >>> It can point to an element of an array of int. > >>> The statement > >>> > >>> pi = &((*pai)[0]); > >>> > >>> is allowed. It assigns a pointer to an element of an array of int > >>> to a pointer to an int. > >>> > >> You are either deliberately or unknowingly writing bad code. > > > > There is nothing bad about the statement, it assigns a pointer to > > the first element of an array of int to a pointer to an int. > > Evaluating it starts with pai, a pointer to an array; (*pai) is > > that array; (*pai)[0] is the first element of that array; > > &((*pai)[0]) is a pointer to the element; pi = &((*pai)[0]) sets > > pi to that pointer. > > > >>>>> The relevant sections of the standard for the statement > >>>>> > >>>>> pi = pai; > >>>>> > >>>>> where pi and pai are declared with > >>>>> > >>>>> int *pi, (*pai)[1]; > >>>>> > >>>>> are the one about assignment operators (5.17) and the one about > >>>>> implict conversions (4) that it refers to. According to those > >>>>> sections, that assignment, which tries have a pointer to int point > >>>>> to an array, is not allowed. If pi and pai had the same type, the > >>>>> assignment would be allowed. > >>>> What is this nonsense about , your code is trash dude and you can't > >>>> even > >>>> accept what is really the relevant sections of the standard, the > >>>> sections > >>>> about arrays. > >>> > >>> The fact that C++ compilers reject the code demonstrates that a > >>> pointer to an array of int cannot be assigned to a pointer to int. > >>> In other words, a pointer to int cannot point to an array of int. > >>> What paragraph of the C++ standard states otherwise? > >>> > >> Its your code that is rejected by compilers so its your understanding > >> that > >> must be wrong. > > > > As far as I can tell my understanding is correct. pi is a pointer > > an int and pai is a pointer to an array of int. If a pointer to an > > int could point to a pointer to an array of int, the statement would > > be allowed. > > > >>>>>> I fully understand the difference between the types: > >>>>>> int(*)[size] and int*. > >>>>>> I also understand that both can point to arrays, you cannot > >>>>>> understand > >>>>>> this > >>>>>> though . You think only one type can point to an array which is ofc > >>>>>> against > >>>>>> the views of all the C++ experts. > >>>>> > >>>>> If you fully understood the difference between those types in C++, > >>>>> you would understand that a pointer to int cannot point to an array > >>>>> of int. A term, such as "point to", used in the context of a > >>>>> a programming language does not necessarily have the same meaning > >>>>> that it has in other contexts. > >>>> As you refuse to accept all reason and common sense I can only appeal > >>>> to > >>>> authority. If people like Bjarne Stroustrup say that an int* can point > >>>> to > >>>> a > >>>> single int or an array of int, and you say otherwise, who are we to > >>>> believe > >>>> is correct? You or Bjarne Stroustrup? > >>> > >>> No one needs to believe anything that is not supported by what is > >>> in the C++ standard or by compliers that comply to the standard. > >>> Given the declaraion > >>> > >>> int *pi, (*pai)[1]; > >>> > >>> the statement > >>> > >>> pi = pai; > >>> > >>> which attempts to have a pointer to an int point to the array of int > >>> (pointed to by the variable pai) is not allowed. C++ compilers will > >>> issue a diagnosic message for the assignment statement. > >> > >> That piece of bad code you have produced somehow suggests that Bjarne > >> Stroustrup is wrong does it? > > > > It does not suggest that Bjarne Stroustrup is wrong, unless he > > said that assigning a pointer to array of int to a pointer to int > > is allowed in C++. As far as I know, he has never said that. > > > >>>> If the C++ standard states that , when dereferenced, an array(or > >>>> pointer > >>>> to > >>>> an array) returns the pointed to (n-1)dimension array. Then who are we > >>>> to > >>>> believe, you or the C++ standard? > >>> > >>> Right, in the statement > >>> > >>> int a2i[3][5], (*pa1i)[5] = a2i; > >>> > >>> evaluating a2i in the initialization expression returns a pointer to > >>> a 1-dimensional array. After the initialization pa1i points to that > >>> 1-dimensional array, not to a 2-dimensional array. > >> > >> a2i is implicitly converted to a pointer. The pointed to array is a 2d > >> array, not a 1dim array. Where the above standards quote applies is if > >> you > >> derefernece either a2i or pa1i, eg: > >> *pa1i; > >> or > >> pa1i[0]; > >> This is dereferencing the pointer to the array, and the results of this > >> dereference is an array of (n-1) dimensions , eg: > >> int[5]; > >> As you can see the standard agrees perfectly with my interpretation. > > > > According to the standard, a2i in the initialization expression is > > converted to a pointer to a 1-dimension array, not a 2-dimensional > > array. Paragraph 7 of section 8.3.4 of the standard is: > > > > A consistent rule is followed for multidimensional arrays. If E > > is an n-dimensional array of rank ixjx...xk, then E appearing in > > an expression is converted to a pointer to an (n - 1)-dimensional > > array with rank jx...xk. If the * operator, either explicitly or > > implicitly as a result of subscripting, is applied to this pointer, > > the result is the pointed to (n - 1)-dimensional array, which > > itself is immediately converted into a pointer. > > > >> If you take pa1i and consider it a pointer to a 1d array, this fails > >> because *pa1i does not produce the pointed to (n-1) dimensional array, > >> which > >> would be a single int( a zero dim array). > > > > Nothing fails here by considering pa1i to be a pointer to a > > 1-dimensional array, which is what it is. Evaluating *pa1i results > > in a 1-dimensional array, > One final thing , that does fail because it doesn'tt comply with the rules. > A pointed to (n-1) dim array, cannot be the same for a 1dim and 2dim array. > (2-1) != (1-1) > <snip> > <snip> int a2[3][5]; //a2 is a two dimensional array. int (*pa1)[5] = a2; //When a2 is used in an expression, it is converted to a pointer to a one dimensional array. (N = 2, 2 - 1 = 1) int a4[3][4][5][7]; //a4 is a 4 dimensional array. int (*pa3)[4][5][7] = a4; //When a4 is used in an expression, it is converted to a pointer to a 3 dimensional array. (N = 4, 4 - 1 = 3)
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-06 10:32 +0100 |
| Message-ID | <1rWmp.2902$Ir.711@newsfe13.ams2> |
| In reply to | #3196 |
"Garrett Hartshaw" <ghartshaw@gmail.com> wrote in message news:almarsoft.8616384651225967946@nntp.aioe.org... > On Tue, 5 Apr 2011 20:16:29 +0100, "Paul" <pchristor@yahoo.co.uk> >> > [snip] >> > >> >> I'm saying they are all arrays of the same type i.e: >> >> int arr1[3][4]; /*Array of int type*/ >> >> int arr2[6]; /*Array of int*/ >> >> int* p1 = new int[5]; /*Array of int*/ >> >> int (*p2)[6] = new int[5][6]; /*Array of int*/ >> >> >> >> They are all int-type arrays and the identifier in each case, no > matter >> >> what >> >> type that is, points to an array of int. >> > >> > Actually, arr1 is a 2-dimensional array of int, p1 is a pointer to >> > int, new int[5] returns a pointer to an int, p2 is a pointer to an >> > array of int, and new int[5][6] returns a pointer to a >> > 1-dimensional array of int. p1 and p2 are pointers, not arrays. >> > >> > Here is a example from section 8.1 (Type Names) of the C++ > standard >> > >> > int // int i >> > int * // int *pi >> > int *[3] // int *p[3] >> > int (*)[3] // int (*p3i)[3] >> > int *() // int *f() >> > int (*)(double) // int (*pf)(double) >> > >> > name respectively the types "int," "pointer to int," "array of 3 >> > pointers to int," "pointer to array of 3 int," "function of (no >> > parameters) returning pointer to int," and "pointer to a function >> > of (double) returning int. >> > >> > Here is a note from paragraph 5 of section 5.3.4 (New) of the C++ >> > standard: "Note: both new int and new int[10] have type int* and >> > the type of new int[i][10] is int (*)[10]." >> > >> > [snip] >> >>> A pointer to an int and a pointer to an >> >>> array of int are different types. >> >> No they're not. Your thinking about pointer types, not what is > pointed >> >> to. I >> >> have already said a pointer type doesn't define what is pointed > to but I >> >> will repeat it. >> > >> > If a pointer to an int and a pointer to an array of int were the >> > same type, then the statement >> > >> > int (*pai)[1], *pa = pai; >> > >> > would be allowed, but it isn't. A compiler I use gives the > message >> > "error: cannot convert 'int (*)[1]' to 'int*' in initialization". >> > An attempt is being made to convert a pointer to an array of int > to >> > a pointer to an int. >> > >> >>> It is not a matter of common sense; >> >>> it is a matter of what the term "points to" means in C++. Here > is >> >>> paragraph 1 of section 5.3.1 of the C++ standard: >> >> I know what points to means I dont need to reference the > standard to find >> >> out. >> > >> > You need to reference the C++ standard to understand what a term >> > means in the C++ programming language. >> > >> >>> The unary * operator performs indirection: the expression to > which >> >>> it is applied shall be a pointer to an object type, or a > pointer >> >>> to a function type and the result is an lvalue referring to the >> >>> object or function to which the expression points. If the type > of >> >>> the expression is pointer to T, the type of the result is T. >> >>> [Note: a pointer to an incomplete type (other than cv void ) > can >> >>> be dereferenced. The lvalue thus obtained can be used in > limited >> >>> ways (to initialize a reference, for example); this lvalue must >> >>> not be converted to an rvalue, see 4.1.] >> >>> >> >>> According to the C++ standard, the pointer type determines the >> >>> type of the result of dereferencing the pointer >> >>> >> >> So the C++ standards are relevant now when talking about > dereferencing >> >> pointers? >> >> If you read the above in conjuction with the relevant section on > arrays >> >> you >> >> will understand. >> > >> > A section of the C++ standard about dereferencing a pointer is >> > relevant to a statement in which a pointer is dereferenced. The >> > same section is not relevant to a statement in which a pointer is >> > not dereferenced. >> > >> >>>>> A pointer to an int may point to any int, including one that > is an >> >>>>> element of an array of int. However, when pointing to an > element of >> >>>>> an array of int it is pointing to an int, not an array. When > you >> >>>>> dereference the pointer the result is an int, not an array. >> >>>> This is where you lose all sense of logic, a pointer to an > entity >> >>>> points >> >>>> exactly to that entity. The pointer type does not define the > pointed to >> >>>> entity. >> >>> >> >>> According the the C++ standard, see the preceeding quote from > the >> >>> standard, the type of the result of dereferencing a pointer > depends >> >>> on the type of the pointer. The result type does not depend on > the >> >>> type used when the object was allocated. >> >>> >> >> This does not mean the an int* cannot point to an array, If you > read the >> >> standards properly you will understand why a pointer to an array > must >> >> point >> >> to , the pointed to (n-1) diemnsional array. >> > >> > That's right, the quote from the standard is about the unary * >> > operator It is not relevant to whether an int* can point to >> > an array. A pointer to an array points to an array of the number >> > of dimensions in the pointer type, not to an array of one fewer >> > dimensions. For example, >> > >> > int (*p2i)[3][5] >> > >> > declares a pointer to a 2-dimensional array, not to a > 1-dimensional >> > array. >> > >> >> And I though you said the standards were irellevant because we > were not >> >> talking aobut dereferencing a pointer. >> > >> > I said that a part of the standard about dereferencing is not >> > relevant to a statement, such as >> > >> > int *p = new int[4]; >> > >> > in which there is no dereferencing. A part of the standard about >> > dereferencing is relevant to a statement in which there is a >> > dereference operation. >> > >> >>>>>>> A pointer to the first element of the array is not the > same as a >> >>>>>>> pointer >> >>>>>>> to >> >>>>>>> the array. The former has type pointer to T, that latter > has type >> >>>>>>> pointer >> >>>>>>> to array of N T. If they were the same, given the > declaration >> >>>>>> A pointer to the first element of an array, is a pointer to > the >> >>>>>> array. >> >>>>>> >> >>>>>>> int *pi, (*pai)[1]; >> >>>>>>> >> >>>>>>> the assignment >> >>>>>>> >> >>>>>>> pi = pai; >> >>>>>>> >> >>>>>>> would be allowed, but it is not allowed. >> >>>>>> You obviously do not understand the difference in level sof >> >>>>>> indirection. >> >>>>> >> >>>>> What C++ compiler have you used that does not give a > diagnostic >> >>>>> message about the assignment statement? >> >>>> Your code is just wrong. I don't know what its supposed to do. >> >>> >> >>> What it tries to do is assign a pointer to an array of int to a >> >>> pointer to an int. >> >> Well thats just wrong because the pointer types are different > levels if >> >> indirection. You convert an array into a pointer like so : >> >> int arr[5]; >> >> int* p = arr; >> > >> > It is good to see that you now understand that trying assign a >> > pointer to an array of int to a pointer to an int is wrong. When >> > the array name in the initialization expression is converted to is >> > a pointer to an int, not a pointer to an array of int. >> > >> >> You don't take the address of an array , unless you want a > different >> >> level >> >> of indirection. Arrays are implicitly converted to pointers. >> > >> > You take the address of an array when you want a pointer to that > array. >> > >> >>> The fact that it is not allowed by the C++ >> >>> standard demonstrates that a pointer to an int cannot not point >> >>> to an array of int. >> >> It is allowed but it needs a cast. >> > >> > Using a cast changes the type of a value. If the cast is to >> > something other than a pointer to an array of int, the value on >> > the left hand side of the assignment is no longer from a >> > pointer to an array of int. >> > >> >>> It can point to an element of an array of int. >> >>> The statement >> >>> >> >>> pi = &((*pai)[0]); >> >>> >> >>> is allowed. It assigns a pointer to an element of an array of > int >> >>> to a pointer to an int. >> >>> >> >> You are either deliberately or unknowingly writing bad code. >> > >> > There is nothing bad about the statement, it assigns a pointer to >> > the first element of an array of int to a pointer to an int. >> > Evaluating it starts with pai, a pointer to an array; (*pai) is >> > that array; (*pai)[0] is the first element of that array; >> > &((*pai)[0]) is a pointer to the element; pi = &((*pai)[0]) sets >> > pi to that pointer. >> > >> >>>>> The relevant sections of the standard for the statement >> >>>>> >> >>>>> pi = pai; >> >>>>> >> >>>>> where pi and pai are declared with >> >>>>> >> >>>>> int *pi, (*pai)[1]; >> >>>>> >> >>>>> are the one about assignment operators (5.17) and the one > about >> >>>>> implict conversions (4) that it refers to. According to those >> >>>>> sections, that assignment, which tries have a pointer to int > point >> >>>>> to an array, is not allowed. If pi and pai had the same > type, the >> >>>>> assignment would be allowed. >> >>>> What is this nonsense about , your code is trash dude and you > can't >> >>>> even >> >>>> accept what is really the relevant sections of the standard, > the >> >>>> sections >> >>>> about arrays. >> >>> >> >>> The fact that C++ compilers reject the code demonstrates that a >> >>> pointer to an array of int cannot be assigned to a pointer to > int. >> >>> In other words, a pointer to int cannot point to an array of > int. >> >>> What paragraph of the C++ standard states otherwise? >> >>> >> >> Its your code that is rejected by compilers so its your > understanding >> >> that >> >> must be wrong. >> > >> > As far as I can tell my understanding is correct. pi is a pointer >> > an int and pai is a pointer to an array of int. If a pointer to > an >> > int could point to a pointer to an array of int, the statement > would >> > be allowed. >> > >> >>>>>> I fully understand the difference between the types: >> >>>>>> int(*)[size] and int*. >> >>>>>> I also understand that both can point to arrays, you cannot >> >>>>>> understand >> >>>>>> this >> >>>>>> though . You think only one type can point to an array which > is ofc >> >>>>>> against >> >>>>>> the views of all the C++ experts. >> >>>>> >> >>>>> If you fully understood the difference between those types in > C++, >> >>>>> you would understand that a pointer to int cannot point to an > array >> >>>>> of int. A term, such as "point to", used in the context of a >> >>>>> a programming language does not necessarily have the same > meaning >> >>>>> that it has in other contexts. >> >>>> As you refuse to accept all reason and common sense I can only > appeal >> >>>> to >> >>>> authority. If people like Bjarne Stroustrup say that an int* > can point >> >>>> to >> >>>> a >> >>>> single int or an array of int, and you say otherwise, who are > we to >> >>>> believe >> >>>> is correct? You or Bjarne Stroustrup? >> >>> >> >>> No one needs to believe anything that is not supported by what > is >> >>> in the C++ standard or by compliers that comply to the standard. >> >>> Given the declaraion >> >>> >> >>> int *pi, (*pai)[1]; >> >>> >> >>> the statement >> >>> >> >>> pi = pai; >> >>> >> >>> which attempts to have a pointer to an int point to the array > of int >> >>> (pointed to by the variable pai) is not allowed. C++ compilers > will >> >>> issue a diagnosic message for the assignment statement. >> >> >> >> That piece of bad code you have produced somehow suggests that > Bjarne >> >> Stroustrup is wrong does it? >> > >> > It does not suggest that Bjarne Stroustrup is wrong, unless he >> > said that assigning a pointer to array of int to a pointer to int >> > is allowed in C++. As far as I know, he has never said that. >> > >> >>>> If the C++ standard states that , when dereferenced, an > array(or >> >>>> pointer >> >>>> to >> >>>> an array) returns the pointed to (n-1)dimension array. Then > who are we >> >>>> to >> >>>> believe, you or the C++ standard? >> >>> >> >>> Right, in the statement >> >>> >> >>> int a2i[3][5], (*pa1i)[5] = a2i; >> >>> >> >>> evaluating a2i in the initialization expression returns a > pointer to >> >>> a 1-dimensional array. After the initialization pa1i points to > that >> >>> 1-dimensional array, not to a 2-dimensional array. >> >> >> >> a2i is implicitly converted to a pointer. The pointed to array > is a 2d >> >> array, not a 1dim array. Where the above standards quote applies > is if >> >> you >> >> derefernece either a2i or pa1i, eg: >> >> *pa1i; >> >> or >> >> pa1i[0]; >> >> This is dereferencing the pointer to the array, and the results > of this >> >> dereference is an array of (n-1) dimensions , eg: >> >> int[5]; >> >> As you can see the standard agrees perfectly with my > interpretation. >> > >> > According to the standard, a2i in the initialization expression is >> > converted to a pointer to a 1-dimension array, not a 2-dimensional >> > array. Paragraph 7 of section 8.3.4 of the standard is: >> > >> > A consistent rule is followed for multidimensional arrays. If E >> > is an n-dimensional array of rank ixjx...xk, then E appearing in >> > an expression is converted to a pointer to an (n - 1)-dimensional >> > array with rank jx...xk. If the * operator, either explicitly or >> > implicitly as a result of subscripting, is applied to this > pointer, >> > the result is the pointed to (n - 1)-dimensional array, which >> > itself is immediately converted into a pointer. >> > >> >> If you take pa1i and consider it a pointer to a 1d array, this > fails >> >> because *pa1i does not produce the pointed to (n-1) dimensional > array, >> >> which >> >> would be a single int( a zero dim array). >> > >> > Nothing fails here by considering pa1i to be a pointer to a >> > 1-dimensional array, which is what it is. Evaluating *pa1i > results >> > in a 1-dimensional array, > > >> One final thing , that does fail because it doesn'tt comply with > the rules. >> A pointed to (n-1) dim array, cannot be the same for a 1dim and > 2dim array. >> (2-1) != (1-1) > > >> <snip> > > > > >> <snip> > int a2[3][5]; //a2 is a two dimensional array. > int (*pa1)[5] = a2; //When a2 is used in an expression, it is converted to > a pointer to a one dimensional array. (N = 2, 2 - 1 = 1) > The term "the ponted to (n-1) dimension array" means that n is the dimensional size of the pointed to array. In the above case the pointed to array is a 2d array. If the users of this newsgroup cannot understand how C++ uses pointers to arrays, thats their problem and I don't give a dam anymore. I'm fed up arguing with idiots, arseholes and queers.
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-04-06 12:20 -0500 |
| Message-ID | <slrnipp87c.2jvf.aggedor@earl-grey.cloud9.net> |
| In reply to | #3184 |
On 2011-04-05, Paul <pchristor@yahoo.co.uk> wrote: > > "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message > news:slrnipmktl.1eov.aggedor@earl-grey.cloud9.net... >> On 2011-04-04, Paul <pchristor@yahoo.co.uk> wrote: [snip] >>> If you take pa1i and consider it a pointer to a 1d array, this fails >>> because *pa1i does not produce the pointed to (n-1) dimensional array, >>> which >>> would be a single int( a zero dim array). >> >> Nothing fails here by considering pa1i to be a pointer to a >> 1-dimensional array, which is what it is. Evaluating *pa1i results >> in a 1-dimensional array, > > One final thing , that does fail because it doesn'tt comply with the rules. > A pointed to (n-1) dim array, cannot be the same for a 1dim and 2dim array. > (2-1) != (1-1) I never claimed that a pointed to (n-1) dim array was the same for a 1dim and 2dim array. With the omitted part of a sentence restored, what I wrote was Nothing fails here by considering pa1i to be a pointer to a 1-dimensional array, which is what it is. Evaluating *pa1i results in a 1-dimensional array, which is implicitly converted to a pointer to the first element of that array. The implicit coversion mentioned in the omitted part complies with paragraph 1 of section 4.2 (Array-to-pointer conversion) of the standard. That paragraph is An lvalue or rvalue of type "array of N T" or "array of unknown bound of T" can be converted to an rvalue of type "pointer to T." The result is a pointer to the first element of the array. Because pa1i was declared to be a pointer to an array of int, the pointer to the first element of the array that *pa1i evaluates to is a pointer to int.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-06 18:42 +0100 |
| Message-ID | <hC1np.13517$oP6.8836@newsfe19.ams2> |
| In reply to | #3215 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message news:slrnipp87c.2jvf.aggedor@earl-grey.cloud9.net... > On 2011-04-05, Paul <pchristor@yahoo.co.uk> wrote: >> >> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message >> news:slrnipmktl.1eov.aggedor@earl-grey.cloud9.net... >>> On 2011-04-04, Paul <pchristor@yahoo.co.uk> wrote: > > [snip] > >>>> If you take pa1i and consider it a pointer to a 1d array, this fails >>>> because *pa1i does not produce the pointed to (n-1) dimensional array, >>>> which >>>> would be a single int( a zero dim array). >>> >>> Nothing fails here by considering pa1i to be a pointer to a >>> 1-dimensional array, which is what it is. Evaluating *pa1i results >>> in a 1-dimensional array, >> >> One final thing , that does fail because it doesn'tt comply with the >> rules. >> A pointed to (n-1) dim array, cannot be the same for a 1dim and 2dim >> array. >> (2-1) != (1-1) > > I never claimed that a pointed to (n-1) dim array was the same for a > 1dim and 2dim array. With the omitted part of a sentence restored, > what I wrote was > > Nothing fails here by considering pa1i to be a pointer to a > 1-dimensional array, which is what it is. Evaluating *pa1i results > in a 1-dimensional array, which is implicitly converted to a pointer > to the first element of that array. pa1i was declared as a pointer to a 2d array with: int a2i[3][5], (*pa1i)[5] = a2i; Dereferencing pa1i returns a 1d array, which is fine if n==2 because (n-1) == 1 If you consider it to be 1d array then n==1, and (n-1) !=1. std::cout << typeid(*pa1i).name ; outputs int[5]. There is no implicit conversion to pointer unless it's further dereferenced i.e: pali[0][0]. > > The implicit coversion mentioned in the omitted part complies with > paragraph 1 of section 4.2 (Array-to-pointer conversion) of the > standard. That paragraph is > > An lvalue or rvalue of type "array of N T" or "array of unknown > bound of T" can be converted to an rvalue of type "pointer to T." > The result is a pointer to the first element of the array. > > Because pa1i was declared to be a pointer to an array of int, the > pointer to the first element of the array that *pa1i evaluates to is > a pointer to int. WTF are you talking about , the only thing ommited was the decalration of pa1i , which is obvious initialised to point to a 2d array.
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-04-06 14:47 -0500 |
| Message-ID | <slrnippgqs.2q59.aggedor@earl-grey.cloud9.net> |
| In reply to | #3217 |
On 2011-04-06, Paul <pchristor@yahoo.co.uk> wrote: > > "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message > news:slrnipp87c.2jvf.aggedor@earl-grey.cloud9.net... >> On 2011-04-05, Paul <pchristor@yahoo.co.uk> wrote: >>> >>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message >>> news:slrnipmktl.1eov.aggedor@earl-grey.cloud9.net... >>>> On 2011-04-04, Paul <pchristor@yahoo.co.uk> wrote: >> >> [snip] >> >>>>> If you take pa1i and consider it a pointer to a 1d array, this fails >>>>> because *pa1i does not produce the pointed to (n-1) dimensional array, >>>>> which >>>>> would be a single int( a zero dim array). >>>> >>>> Nothing fails here by considering pa1i to be a pointer to a >>>> 1-dimensional array, which is what it is. Evaluating *pa1i results >>>> in a 1-dimensional array, >>> >>> One final thing , that does fail because it doesn'tt comply with the >>> rules. >>> A pointed to (n-1) dim array, cannot be the same for a 1dim and 2dim >>> array. >>> (2-1) != (1-1) >> >> I never claimed that a pointed to (n-1) dim array was the same for a >> 1dim and 2dim array. With the omitted part of a sentence restored, >> what I wrote was >> >> Nothing fails here by considering pa1i to be a pointer to a >> 1-dimensional array, which is what it is. Evaluating *pa1i results >> in a 1-dimensional array, which is implicitly converted to a pointer >> to the first element of that array. > > pa1i was declared as a pointer to a 2d array with: > int a2i[3][5], (*pa1i)[5] = a2i; In that declaration pa1i is declared as a pointer to a 1-dimensional array. Here is an example from section 8.1 (Type Names) of the C++ standard. int // int i int * // int *pi int *[3] // int *p[3] int (*)[3] // int (*p3i)[3] int *() // int *f() int (*)(double) // int (*pf)(double) name respectively the types "int," "pointer to int," "array of 3 pointers to int," "pointer to array of 3 int," "function of (no parameters) returning pointer to int," and "pointer to a function of (double) returning int. According to the C++ standard, "int (*p3i)[3]" declares a "pointer to an array of 3 int". That array has one dimension. > Dereferencing pa1i returns a 1d array, which is fine if n==2 because (n-1) >== 1 > If you consider it to be 1d array then n==1, and (n-1) !=1. > > std::cout << typeid(*pa1i).name ; > outputs int[5]. There is no implicit conversion to pointer unless it's > further dereferenced i.e: pali[0][0]. There is no implicit conversion in a typeid expression. According to paragraph 3 of section 5.2.8 (Type identification) of the C++ standard: When typeid is applied to an expression other than an lvalue of a polymorphic class type, the result refers to a type_info object representing the static type of the expression. Lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) conversions are not applied to the expression. If the type of the expression is a class type, the class shall be completely-defined. The expression is not evaluated. The output "int[5]" demonstrates that pali is a pointer to a 1-dimensional array. In a context where the expression *pa1i is evaluated, the resulting 1-dimensional array undergoes array-to-pointer conversion, resulting in a pointer to int. >> The implicit coversion mentioned in the omitted part complies with >> paragraph 1 of section 4.2 (Array-to-pointer conversion) of the >> standard. That paragraph is >> >> An lvalue or rvalue of type "array of N T" or "array of unknown >> bound of T" can be converted to an rvalue of type "pointer to T." >> The result is a pointer to the first element of the array. >> >> Because pa1i was declared to be a pointer to an array of int, the >> pointer to the first element of the array that *pa1i evaluates to is >> a pointer to int. > > WTF are you talking about , the only thing ommited was the decalration of > pa1i , which is obvious initialised to point to a 2d array. What you omitted from what I wrote was: "which is implicitly converted to a pointer to the first element of that array". The initial value in the declaration of pali is a pointer to a 1-dimensional array.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-06 23:51 +0100 |
| Message-ID | <Dtanp.8989$KZ7.6073@newsfe08.ams2> |
| In reply to | #3225 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message news:slrnippgqs.2q59.aggedor@earl-grey.cloud9.net... >>> [snip] >>> >>>>>> If you take pa1i and consider it a pointer to a 1d array, this fails >>>>>> because *pa1i does not produce the pointed to (n-1) dimensional >>>>>> array, >>>>>> which >>>>>> would be a single int( a zero dim array). >>>>> >>>>> Nothing fails here by considering pa1i to be a pointer to a >>>>> 1-dimensional array, which is what it is. Evaluating *pa1i results >>>>> in a 1-dimensional array, >>>> >>>> One final thing , that does fail because it doesn'tt comply with the >>>> rules. >>>> A pointed to (n-1) dim array, cannot be the same for a 1dim and 2dim >>>> array. >>>> (2-1) != (1-1) >>> >>> I never claimed that a pointed to (n-1) dim array was the same for a >>> 1dim and 2dim array. With the omitted part of a sentence restored, >>> what I wrote was >>> >>> Nothing fails here by considering pa1i to be a pointer to a >>> 1-dimensional array, which is what it is. Evaluating *pa1i results >>> in a 1-dimensional array, which is implicitly converted to a pointer >>> to the first element of that array. >> >> pa1i was declared as a pointer to a 2d array with: >> int a2i[3][5], (*pa1i)[5] = a2i; > > In that declaration pa1i is declared as a pointer to a 1-dimensional > array. Here is an example from section 8.1 (Type Names) of the C++ > standard. > > int // int i > int * // int *pi > int *[3] // int *p[3] > int (*)[3] // int (*p3i)[3] > int *() // int *f() > int (*)(double) // int (*pf)(double) > > name respectively the types "int," "pointer to int," "array of 3 > pointers to int," "pointer to array of 3 int," "function of (no > parameters) returning pointer to int," and "pointer to a function > of (double) returning int. Thats the pointer-types, not what it points to. If you interpret this as saying pa1i does not point to a 2d array then you have some serious intellectual problems. > > According to the C++ standard, "int (*p3i)[3]" declares a "pointer > to an array of 3 int". That array has one dimension. No it doesn't the standard clearly says that is a TYPE. The standard does not define that it points to a 1d array. The standard actually implies that type points to a 2d array, in the section about pointers to arrays.. > >> Dereferencing pa1i returns a 1d array, which is fine if n==2 because >> (n-1) >>== 1 >> If you consider it to be 1d array then n==1, and (n-1) !=1. >> >> std::cout << typeid(*pa1i).name ; >> outputs int[5]. There is no implicit conversion to pointer unless it's >> further dereferenced i.e: pali[0][0]. > > There is no implicit conversion in a typeid expression. According > to paragraph 3 of section 5.2.8 (Type identification) of the C++ > standard: > > When typeid is applied to an expression other than an lvalue of > a polymorphic class type, the result refers to a type_info object > representing the static type of the expression. Lvalue-to-rvalue > (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) > conversions are not applied to the expression. If the type of > the expression is a class type, the class shall be > completely-defined. The expression is not evaluated. > > The output "int[5]" demonstrates that pali is a pointer to a 1-dimensional > array. In a context where the expression *pa1i is evaluated, the > resulting > 1-dimensional array undergoes array-to-pointer conversion, resulting in a > pointer to int. The output demonstrates its an array , not a pointer. The type int[5] is not a pointer. As I said this is not implicitly converted to a pointer until its further dereferenced. And when it is converted to a pointer it will be pointer-type: int*, not int (*)[5]. > >>> The implicit coversion mentioned in the omitted part complies with >>> paragraph 1 of section 4.2 (Array-to-pointer conversion) of the >>> standard. That paragraph is >>> >>> An lvalue or rvalue of type "array of N T" or "array of unknown >>> bound of T" can be converted to an rvalue of type "pointer to T." >>> The result is a pointer to the first element of the array. >>> >>> Because pa1i was declared to be a pointer to an array of int, the >>> pointer to the first element of the array that *pa1i evaluates to is >>> a pointer to int. >> >> WTF are you talking about , the only thing ommited was the decalration of >> pa1i , which is obvious initialised to point to a 2d array. > > What you omitted from what I wrote was: "which is implicitly converted to > a > pointer to the first element of that array". The initial value in the > declaration of pali is a pointer to a 1-dimensional array. It is initialised to point to a 2d array, with: int a2i[3][5], (*pa1i)[5] = a2i; a2i is a 2d array , not a 1d array. An array is defined at allocation, not by a pointer that points to it.
[toc] | [prev] | [next] | [standalone]
Page 1 of 21 [1] 2 3 … 21 Next page →
Back to top | Article view | comp.lang.c++
csiph-web