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 5 of 21 — ← Prev page 1 … 3 4 [5] 6 7 … 21 Next page →
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-25 10:57 +0100 |
| Message-ID | <eAbtp.35072$KZ7.28396@newsfe08.ams2> |
| In reply to | #4331 |
"Ian Collins" <ian-news@hotmail.com> wrote in message news:91k66uF820U3@mid.individual.net... > On 04/25/11 03:01 PM, Alf P. Steinbach /Usenet wrote: >> * Ian Collins, on 25.04.2011 01:59: >>> On 04/25/11 11:46 AM, Paul wrote: >>> >>> Spot the self contradiction: >> >> Please stop. > > I had. > You were proved to be wrong. You had no choice.
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-04-26 12:36 -0500 |
| Message-ID | <slrnire0ks.gb4.aggedor@earl-grey.cloud9.net> |
| In reply to | #4289 |
On 2011-04-23, Paul <pchristor@yahoo.co.uk> wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrnir64sj.pso.aggedor@earl-grey.cloud9.net...
>> On 2011-04-20, Paul <pchristor@yahoo.co.uk> wrote:
>>>
>>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>>> news:slrniqrm4f.2usb.aggedor@earl-grey.cloud9.net...
[snip]
>>> You are dereferencing an array-type , not an array.
>>> For example:
>>>
>>> int arr[40] ={0};
>>> int* parr = arr;
>>> int (*pparr)[40] = &arr;
>>>
>>> std::cout<< "address of arr[0]:\t" << &arr[0] <<std::endl;
>>> std::cout<< "value of *parr:\t\t" << *parr <<std::endl;
>>> std::cout<< "value of *pparr\t\t" << *pparr <<std::endl;
>>>
>>> Dereferencing pparr does not access the array it accesses a temporary
>>> pointer.
>>> The pointer pparr does not reference the array, it references an
>>> array-type
>>> object.
>>
>> Dereferencing pparr accesses an array in the same sense that using
>> the name arr accesses an array.
> No it doesn't
> *arr =1; /*Accesses the array*/
> *pparr=1; /*Cannot do this*/
Derefencing pparr gets you arr. To get what you get by
dereferencing arr, you need to dereference what you get by
dereferencing pparr. The equivalent of
*arr = 1;
is
**pparr = 1;
What happens in both cases is that the array resulting from the
expressions arr and *pparr is treated as a pointer to the first
element of the array. The assginments made to *arr and **pparr
are made to the first elements of the array.
[snip]
>>>> The (implementation defined) values returned by typeid(a1i).name()
>>>> and typeid(*pa1i).name() are the same. The output indicates that
>>>> both ai1 and *pai1 are arrays of 4 ints.
>>>>
>>> No it outputs the type, not the pointed to object.
>>> *pa1i does not derefernece a pointer to the array, it dereferenes a
>>> pointer
>>> to a tempory object of array-type.
>>> Basically its a fancy pointer to a pointer.
>>
>> I never said that typeid outputs the pointed to object. The
>> declaration was
>>
>> int a1i[4], (*pa1i)[4] = &a1i;
>>
>> pa1i is a pointer to an array. *pa1i dereferences it resulting in
>> an array. The only objects here are an array (named a1i) and a
>> pointer to array (named pa1i). There is no pointer to a temporary
>> object here.
>>
> No there are four integer objects here, that you fail to acknowledge.
If you want to count the four subobjects of the array, keep in
mind that they are subobjects of the array rather than objects with
a lifetime independent of the array. The important point is that
there is no pointer to a temporary object here.
[snip]
>>> The following pointer-type
>>> int (*p)[4] =&a1i;
>>> Does not access the array when dereferenced, it accesses an array-type
>>> object. This object is bascially another pointer to the array.
>>> Pointing to an array-type object, is not the same as pointing to the
>>> array
>>> of ints. It points to AN array , yes an array-type object( which is
>>> basically another pointer under the hood), it doesn't point to THE array
>>> of
>>> ints.
>>
>> Here, the object named p is a pointer to the array named a1i.
>> Dereferencing it results that array. The expression
>>
> No it doesn't , dererencing this pointer results in a non modifiable object
> that cannot be used to access the array unless converted.
> So it results in something that can be converted to a pointer to the array.
The result of derefencing the pointer is the same as using the name
of the array that the pointer is pointing to. Both of the
expressions (*p) and a1i have the same result. (*p) needs to be
converted to access the array no more than a1i does.
>> (*p)[int_offset]
>>
>> access the int_offset element of that array.
[snip]
>>> When you dereference p1i, you create a temporary array-type object the
>>> value
>>> of which is another memory address. You do not get an array of 4 ints,
>>> example:
>>>
>>> int arr[4] = {1,2,3,4};
>>> int (*p)[4] = &arr;
>>>
>>> std::cout<< *p;
>>>
>>> The type of p is an array-type, this means it points to an object of
>>> array-type, not an array of int objects.
>>
>> There is no temporary array-type object the value of which is
>> another memory address. There are two objects: an array named arr
>> and a pointer to array named p. Due to the initialization, p points
>> the array of int named arr.
>
> Again you fail to acknoweldge the four integer objects.
> Where is this object that you describe as "the array named arr" strored?
As I wrote above, if you want to count the four subobjects of the
array, keep in mind that they are subobjects of the array rather
than objects with a lifetime independent of the array. The
important point is that there is no temporary object here.
The array named arr is stored wherever the C++ implementation decides
to store it, as long as the program behaves as specified by the C++
standard. The same is true of the pointer to array named p.
[snip]
>>>> According to the C++ standard an n-dimensional array is converted to
>>>> a pointer to an (n - 1)-dimensional array. The result of that
>>>> conversion on a 2d array is a pointer to 1d array. A pointer to a
>>>> 1d array points to a 1d array, not to a 2d array. You appear to be
>>>> confusing C++ with a programming language in which arrays are
>>>> polymorphic over dimensions.
>>>>
>>> You are confusing the whole context of the statement in the standard.
>>> It doesn't mean the array is converted to a pointer that no longer points
>>> to
>>> the array.
>>
>> I'm not confusing anything. I accept what the C++ standard states.
>> Here, it states that a conversion is done from an array to a pointer
>> to an element of the array. What is pointed to is an element of the
>> array, not the array.
>
> You must be pointing to the array , to point to an element. Where is this
> element stored if not witihin the array?
Elements of an array are stored in the region of storage created for
that array. In C++, a pointer to an array and a pointer to an
element of that array are not the same; they have different types.
The assignment
*p = 1
is allowed if p is a pointer to an element of an array of int but
not if p is a pointer to an array of int.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-26 22:42 +0100 |
| Message-ID | <y%Gtp.39557$o81.27663@newsfe28.ams2> |
| In reply to | #4375 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
news:slrnire0ks.gb4.aggedor@earl-grey.cloud9.net...
>>>> You are dereferencing an array-type , not an array.
>>>> For example:
>>>>
>>>> int arr[40] ={0};
>>>> int* parr = arr;
>>>> int (*pparr)[40] = &arr;
>>>>
>>>> std::cout<< "address of arr[0]:\t" << &arr[0] <<std::endl;
>>>> std::cout<< "value of *parr:\t\t" << *parr <<std::endl;
>>>> std::cout<< "value of *pparr\t\t" << *pparr <<std::endl;
>>>>
>>>> Dereferencing pparr does not access the array it accesses a temporary
>>>> pointer.
>>>> The pointer pparr does not reference the array, it references an
>>>> array-type
>>>> object.
>>>
>>> Dereferencing pparr accesses an array in the same sense that using
>>> the name arr accesses an array.
>> No it doesn't
>> *arr =1; /*Accesses the array*/
>> *pparr=1; /*Cannot do this*/
>
> Derefencing pparr gets you arr. To get what you get by
> dereferencing arr, you need to dereference what you get by
> dereferencing pparr. The equivalent of
>
> *arr = 1;
>
> is
>
> **pparr = 1;
>
> What happens in both cases is that the array resulting from the
> expressions arr and *pparr is treated as a pointer to the first
> element of the array. The assginments made to *arr and **pparr
> are made to the first elements of the array.
As I said pparr needs to be dereferenced twice to access the array,
derefernecing pparr once doesn't access the array. So it points to an
array-type object , that must be convereted before the array can be
accessed.
>
> [snip]
>
>>>>> The (implementation defined) values returned by typeid(a1i).name()
>>>>> and typeid(*pa1i).name() are the same. The output indicates that
>>>>> both ai1 and *pai1 are arrays of 4 ints.
>>>>>
>>>> No it outputs the type, not the pointed to object.
>>>> *pa1i does not derefernece a pointer to the array, it dereferenes a
>>>> pointer
>>>> to a tempory object of array-type.
>>>> Basically its a fancy pointer to a pointer.
>>>
>>> I never said that typeid outputs the pointed to object. The
>>> declaration was
>>>
>>> int a1i[4], (*pa1i)[4] = &a1i;
>>>
>>> pa1i is a pointer to an array. *pa1i dereferences it resulting in
>>> an array. The only objects here are an array (named a1i) and a
>>> pointer to array (named pa1i). There is no pointer to a temporary
>>> object here.
>>>
>> No there are four integer objects here, that you fail to acknowledge.
>
> If you want to count the four subobjects of the array, keep in
> mind that they are subobjects of the array rather than objects with
> a lifetime independent of the array. The important point is that
> there is no pointer to a temporary object here.
>
> [snip]
>
>>>> The following pointer-type
>>>> int (*p)[4] =&a1i;
>>>> Does not access the array when dereferenced, it accesses an array-type
>>>> object. This object is bascially another pointer to the array.
>>>> Pointing to an array-type object, is not the same as pointing to the
>>>> array
>>>> of ints. It points to AN array , yes an array-type object( which is
>>>> basically another pointer under the hood), it doesn't point to THE
>>>> array
>>>> of
>>>> ints.
>>>
>>> Here, the object named p is a pointer to the array named a1i.
>>> Dereferencing it results that array. The expression
>>>
>> No it doesn't , dererencing this pointer results in a non modifiable
>> object
>> that cannot be used to access the array unless converted.
>> So it results in something that can be converted to a pointer to the
>> array.
>
> The result of derefencing the pointer is the same as using the name
> of the array that the pointer is pointing to. Both of the
> expressions (*p) and a1i have the same result. (*p) needs to be
> converted to access the array no more than a1i does.
>
>>> (*p)[int_offset]
>>>
>>> access the int_offset element of that array.
>
> [snip]
>
>>>> When you dereference p1i, you create a temporary array-type object the
>>>> value
>>>> of which is another memory address. You do not get an array of 4 ints,
>>>> example:
>>>>
>>>> int arr[4] = {1,2,3,4};
>>>> int (*p)[4] = &arr;
>>>>
>>>> std::cout<< *p;
>>>>
>>>> The type of p is an array-type, this means it points to an object of
>>>> array-type, not an array of int objects.
>>>
>>> There is no temporary array-type object the value of which is
>>> another memory address. There are two objects: an array named arr
>>> and a pointer to array named p. Due to the initialization, p points
>>> the array of int named arr.
>>
>> Again you fail to acknoweldge the four integer objects.
>> Where is this object that you describe as "the array named arr" strored?
>
> As I wrote above, if you want to count the four subobjects of the
> array, keep in mind that they are subobjects of the array rather
> than objects with a lifetime independent of the array. The
> important point is that there is no temporary object here.
>
So where does the memory address value come from? Its not stored in the
array of integer objects.
> The array named arr is stored wherever the C++ implementation decides
> to store it, as long as the program behaves as specified by the C++
> standard. The same is true of the pointer to array named p.
Dereferencing pparr once , yields an object which has a value that is the
address of the array. This object must exist someplace prior to it getting
converted to a pointer.
>
> [snip]
>
>>>>> According to the C++ standard an n-dimensional array is converted to
>>>>> a pointer to an (n - 1)-dimensional array. The result of that
>>>>> conversion on a 2d array is a pointer to 1d array. A pointer to a
>>>>> 1d array points to a 1d array, not to a 2d array. You appear to be
>>>>> confusing C++ with a programming language in which arrays are
>>>>> polymorphic over dimensions.
>>>>>
>>>> You are confusing the whole context of the statement in the standard.
>>>> It doesn't mean the array is converted to a pointer that no longer
>>>> points
>>>> to
>>>> the array.
>>>
>>> I'm not confusing anything. I accept what the C++ standard states.
>>> Here, it states that a conversion is done from an array to a pointer
>>> to an element of the array. What is pointed to is an element of the
>>> array, not the array.
>>
>> You must be pointing to the array , to point to an element. Where is this
>> element stored if not witihin the array?
>
> Elements of an array are stored in the region of storage created for
> that array. In C++, a pointer to an array and a pointer to an
> element of that array are not the same; they have different types.
> The assignment
A pointer to an array of integers , is of type int*.
A pointer to an array, in your context, is a pointer to an array-type
object. Which must be dereferenced twice to access the array, the second
dereference will implicitly convert this object to an int*.
>
> *p = 1
>
> is allowed if p is a pointer to an element of an array of int but
> not if p is a pointer to an array of int.
A pointer to an array of integers can be 2 different tyes of pointer:
a) A pointer to integers.
b) A pointer to an array-type object.
A pointer to , for example a char array, is generally consider to be of type
char*. An array by nature can only be accesssed one element at a time.
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-04-27 12:53 -0500 |
| Message-ID | <slrnirgm0l.1f0l.aggedor@earl-grey.cloud9.net> |
| In reply to | #4388 |
On 2011-04-26, Paul <pchristor@yahoo.co.uk> wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrnire0ks.gb4.aggedor@earl-grey.cloud9.net...
>>>>> You are dereferencing an array-type , not an array.
>>>>> For example:
>>>>>
>>>>> int arr[40] ={0};
>>>>> int* parr = arr;
>>>>> int (*pparr)[40] = &arr;
>>>>>
>>>>> std::cout<< "address of arr[0]:\t" << &arr[0] <<std::endl;
>>>>> std::cout<< "value of *parr:\t\t" << *parr <<std::endl;
>>>>> std::cout<< "value of *pparr\t\t" << *pparr <<std::endl;
>>>>>
>>>>> Dereferencing pparr does not access the array it accesses a temporary
>>>>> pointer.
>>>>> The pointer pparr does not reference the array, it references an
>>>>> array-type
>>>>> object.
>>>>
>>>> Dereferencing pparr accesses an array in the same sense that using
>>>> the name arr accesses an array.
>>> No it doesn't
>>> *arr =1; /*Accesses the array*/
>>> *pparr=1; /*Cannot do this*/
>>
>> Derefencing pparr gets you arr. To get what you get by
>> dereferencing arr, you need to dereference what you get by
>> dereferencing pparr. The equivalent of
>>
>> *arr = 1;
>>
>> is
>>
>> **pparr = 1;
>>
>> What happens in both cases is that the array resulting from the
>> expressions arr and *pparr is treated as a pointer to the first
>> element of the array. The assginments made to *arr and **pparr
>> are made to the first elements of the array.
>
> As I said pparr needs to be dereferenced twice to access the array,
> derefernecing pparr once doesn't access the array. So it points to an
> array-type object , that must be convereted before the array can be
> accessed.
What you wrote was
No it doesn't
*arr =1; /*Accesses the array*/
*pparr=1; /*Cannot do this*/
in reply to "Dereferencing pparr accesses an array in the same
sense that using the name arr accesses an array."
Your example uses *arr and *pparr as if they were the same; they
are not the same. *arr refers to the first element of the array
while *pparr refers to the array. *pparr and arr both refer to
the array.
Because pparr is a pointer to an array, of course it has to be
dereference twice to get the same result as deferencing the array
once. In general, if X points to Y, **X is the same as *Y.
[snip]
>>>>> When you dereference p1i, you create a temporary array-type object the
>>>>> value
>>>>> of which is another memory address. You do not get an array of 4 ints,
>>>>> example:
>>>>>
>>>>> int arr[4] = {1,2,3,4};
>>>>> int (*p)[4] = &arr;
>>>>>
>>>>> std::cout<< *p;
>>>>>
>>>>> The type of p is an array-type, this means it points to an object of
>>>>> array-type, not an array of int objects.
>>>>
>>>> There is no temporary array-type object the value of which is
>>>> another memory address. There are two objects: an array named arr
>>>> and a pointer to array named p. Due to the initialization, p points
>>>> the array of int named arr.
>>>
>>> Again you fail to acknoweldge the four integer objects.
>>> Where is this object that you describe as "the array named arr" strored?
>>
>> As I wrote above, if you want to count the four subobjects of the
>> array, keep in mind that they are subobjects of the array rather
>> than objects with a lifetime independent of the array. The
>> important point is that there is no temporary object here.
>>
> So where does the memory address value come from? Its not stored in the
> array of integer objects.
Where the memory address comes from depends on where the
implementation decides to store the array. For example, an object
with automatic storage duration, such a non-static array declared
in a function, is allocated on the stack in an implementation that
uses a stack for automatic storage.
The compiler knows the compile-time constant offset in the stack
frame where it has decided to store the array. In places where a
program needs the memory address of the array, the compiler puts
in instructions to sum that compile-time constant offset and the
current value of the stack pointer.
>> The array named arr is stored wherever the C++ implementation decides
>> to store it, as long as the program behaves as specified by the C++
>> standard. The same is true of the pointer to array named p.
>
>
> Dereferencing pparr once , yields an object which has a value that is the
> address of the array. This object must exist someplace prior to it getting
> converted to a pointer.
pparr is a pointer to an array. The address of the array it points
to is stored in the C++ object allocated for pparr. Evaluating
*pparr loads that value from memory. In a context where
array-to-pointer conversion is done, there is no additional C++
object whose value is obtained to convert from the address of an
array to a pointer to the first element of the array.
[snip]
> A pointer to an array of integers , is of type int*.
> A pointer to an array, in your context, is a pointer to an array-type
> object. Which must be dereferenced twice to access the array, the second
> dereference will implicitly convert this object to an int*.
The type int* is a pointer to int. A pointer to an array of int is
type int(*)[N], where N is the number of array elements, if known.
A pointer to an array of int is dereferenced once to access the array.
It may be dereferenced twice to access the first int in the array.
Look at the output of the following program.
#include <iostream>
#include <typeinfo>
int main() {
int a1i[4], (*pa1i)[4]=&a1i;
std::cout<<"typeid( pa1i).name()="<<typeid(pa1i).name()<<std::endl;
std::cout<<"typeid( *pa1i).name()="<<typeid(*pa1i).name()<<std::endl;
std::cout<<"typeid(**pa1i).name()="<<typeid(**pa1i).name()<<std::endl;
}
pa1i is a pointer to an array of int; *pa1i an array of int (just
as a1i is); **pa1i is an int.
>>
>> *p = 1
>>
>> is allowed if p is a pointer to an element of an array of int but
>> not if p is a pointer to an array of int.
>
> A pointer to an array of integers can be 2 different tyes of pointer:
> a) A pointer to integers.
> b) A pointer to an array-type object.
A pointer to an array of integers is a single type of pointer,
int(*)[N], where N is the number of array elements, if known. A
pointer to an integer may point to an element of an array of
integers.
> A pointer to , for example a char array, is generally consider to be of type
> char*. An array by nature can only be accesssed one element at a time.
What something is generally considered to be is not necessarily what
it is according to the C++ standard. According to the C++ standard
char(*)[N] is a pointer to an array of char, while char* is a pointer
to a char.
In some contexts a char* is treated like a pointer to an element of
an array; in some contexts an array is treated like a pointer to its
first element. Because in some contexts a thing is treated as if
it were something else, does not the thing is the something else.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-04-27 19:06 +0100 |
| Message-ID | <a4CdnS4Ju4XexiXQnZ2dnUVZ8uadnZ2d@giganews.com> |
| In reply to | #4404 |
On 27/04/2011 18:53, A. Bolmarcich wrote:
> On 2011-04-26, Paul<pchristor@yahoo.co.uk> wrote:
>>>>>> When you dereference p1i, you create a temporary array-type object the
>>>>>> value
>>>>>> of which is another memory address. You do not get an array of 4 ints,
>>>>>> example:
>>>>>>
>>>>>> int arr[4] = {1,2,3,4};
>>>>>> int (*p)[4] =&arr;
>>>>>>
>>>>>> std::cout<< *p;
>>>>>>
>>>>>> The type of p is an array-type, this means it points to an object of
>>>>>> array-type, not an array of int objects.
>>>>>
>>>>> There is no temporary array-type object the value of which is
>>>>> another memory address. There are two objects: an array named arr
>>>>> and a pointer to array named p. Due to the initialization, p points
>>>>> the array of int named arr.
>>>>
>>>> Again you fail to acknoweldge the four integer objects.
>>>> Where is this object that you describe as "the array named arr" strored?
>>>
>>> As I wrote above, if you want to count the four subobjects of the
>>> array, keep in mind that they are subobjects of the array rather
>>> than objects with a lifetime independent of the array. The
>>> important point is that there is no temporary object here.
>>>
>> So where does the memory address value come from? Its not stored in the
>> array of integer objects.
>
> Where the memory address comes from depends on where the
> implementation decides to store the array. For example, an object
> with automatic storage duration, such a non-static array declared
> in a function, is allocated on the stack in an implementation that
> uses a stack for automatic storage.
>
> The compiler knows the compile-time constant offset in the stack
> frame where it has decided to store the array. In places where a
> program needs the memory address of the array, the compiler puts
> in instructions to sum that compile-time constant offset and the
> current value of the stack pointer.
>
I have already had this argument with Paul The Troll but he is too
stubborn to accept that he is wrong. Stop giving the dog bones.
/Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-27 20:09 +0100 |
| Message-ID | <O41up.44235$5t2.13002@newsfe06.ams2> |
| In reply to | #4404 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
news:slrnirgm0l.1f0l.aggedor@earl-grey.cloud9.net...
> On 2011-04-26, Paul <pchristor@yahoo.co.uk> wrote:
>>
>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>> news:slrnire0ks.gb4.aggedor@earl-grey.cloud9.net...
>>>>>> You are dereferencing an array-type , not an array.
>>>>>> For example:
>>>>>>
>>>>>> int arr[40] ={0};
>>>>>> int* parr = arr;
>>>>>> int (*pparr)[40] = &arr;
>>>>>>
>>>>>> std::cout<< "address of arr[0]:\t" << &arr[0] <<std::endl;
>>>>>> std::cout<< "value of *parr:\t\t" << *parr <<std::endl;
>>>>>> std::cout<< "value of *pparr\t\t" << *pparr <<std::endl;
>>>>>>
>>>>>> Dereferencing pparr does not access the array it accesses a temporary
>>>>>> pointer.
>>>>>> The pointer pparr does not reference the array, it references an
>>>>>> array-type
>>>>>> object.
>>>>>
>>>>> Dereferencing pparr accesses an array in the same sense that using
>>>>> the name arr accesses an array.
>>>> No it doesn't
>>>> *arr =1; /*Accesses the array*/
>>>> *pparr=1; /*Cannot do this*/
>>>
>>> Derefencing pparr gets you arr. To get what you get by
>>> dereferencing arr, you need to dereference what you get by
>>> dereferencing pparr. The equivalent of
>>>
>>> *arr = 1;
>>>
>>> is
>>>
>>> **pparr = 1;
>>>
>>> What happens in both cases is that the array resulting from the
>>> expressions arr and *pparr is treated as a pointer to the first
>>> element of the array. The assginments made to *arr and **pparr
>>> are made to the first elements of the array.
>>
>> As I said pparr needs to be dereferenced twice to access the array,
>> derefernecing pparr once doesn't access the array. So it points to an
>> array-type object , that must be convereted before the array can be
>> accessed.
>
> What you wrote was
>
> No it doesn't
> *arr =1; /*Accesses the array*/
> *pparr=1; /*Cannot do this*/
>
> in reply to "Dereferencing pparr accesses an array in the same
> sense that using the name arr accesses an array."
This statement is incorrect, dereferencing pparr does not access the array
in the same sense as arr.
>
> Your example uses *arr and *pparr as if they were the same; they
> are not the same. *arr refers to the first element of the array
> while *pparr refers to the array. *pparr and arr both refer to
> the array.
So does :
int* p = arr;
So p accesses the array in the same sense as arr.
pparr has another level of indirection.
>
> Because pparr is a pointer to an array, of course it has to be
> dereference twice to get the same result as deferencing the array
> once. In general, if X points to Y, **X is the same as *Y.
>
When you have a pointer to an integer you don't derefernece it twice to
access the integer.
So why do you say "of course it has to be dereferneced twice"?
A pointer to something should not have to be dereferenced twice to access
what it points to.
> [snip]
>
>>>>>> When you dereference p1i, you create a temporary array-type object
>>>>>> the
>>>>>> value
>>>>>> of which is another memory address. You do not get an array of 4
>>>>>> ints,
>>>>>> example:
>>>>>>
>>>>>> int arr[4] = {1,2,3,4};
>>>>>> int (*p)[4] = &arr;
>>>>>>
>>>>>> std::cout<< *p;
>>>>>>
>>>>>> The type of p is an array-type, this means it points to an object of
>>>>>> array-type, not an array of int objects.
>>>>>
>>>>> There is no temporary array-type object the value of which is
>>>>> another memory address. There are two objects: an array named arr
>>>>> and a pointer to array named p. Due to the initialization, p points
>>>>> the array of int named arr.
>>>>
>>>> Again you fail to acknoweldge the four integer objects.
>>>> Where is this object that you describe as "the array named arr"
>>>> strored?
>>>
>>> As I wrote above, if you want to count the four subobjects of the
>>> array, keep in mind that they are subobjects of the array rather
>>> than objects with a lifetime independent of the array. The
>>> important point is that there is no temporary object here.
>>>
>> So where does the memory address value come from? Its not stored in the
>> array of integer objects.
>
> Where the memory address comes from depends on where the
> implementation decides to store the array. For example, an object
> with automatic storage duration, such a non-static array declared
> in a function, is allocated on the stack in an implementation that
> uses a stack for automatic storage.
>
> The compiler knows the compile-time constant offset in the stack
> frame where it has decided to store the array. In places where a
> program needs the memory address of the array, the compiler puts
> in instructions to sum that compile-time constant offset and the
> current value of the stack pointer.
This is not a sutable answer , we are talking about array-type object. When
I asked where the memory address was stored I meant in what object, not in
what area of memory.
>
>>> The array named arr is stored wherever the C++ implementation decides
>>> to store it, as long as the program behaves as specified by the C++
>>> standard. The same is true of the pointer to array named p.
>>
>>
>> Dereferencing pparr once , yields an object which has a value that is the
>> address of the array. This object must exist someplace prior to it
>> getting
>> converted to a pointer.
>
> pparr is a pointer to an array. The address of the array it points
> to is stored in the C++ object allocated for pparr.
I'm not sure what you mean by this. The object allocated to ppparr is what
exactly?
> Evaluating
> *pparr loads that value from memory. In a context where
> array-to-pointer conversion is done, there is no additional C++
> object whose value is obtained to convert from the address of an
> array to a pointer to the first element of the array.
>
I don't think so , *pparr dereferences a pointer, there is no
array-to-pointer conversion here.
> [snip]
>
>> A pointer to an array of integers , is of type int*.
>> A pointer to an array, in your context, is a pointer to an array-type
>> object. Which must be dereferenced twice to access the array, the second
>> dereference will implicitly convert this object to an int*.
>
> The type int* is a pointer to int.
Yes the TYPE is "pointer to int". This type of pointer can point to int
object/s(singlular or plural).
> A pointer to an array of int is
> type int(*)[N], where N is the number of array elements, if known.
> A pointer to an array of int is dereferenced once to access the array.
No this is a poointer to array-type objects, not to integer type objects.
> It may be dereferenced twice to access the first int in the array.
It MUST be dereferenced twcie, and converted to an int* , to point to any of
the array elements.
> Look at the output of the following program.
>
> #include <iostream>
> #include <typeinfo>
> int main() {
> int a1i[4], (*pa1i)[4]=&a1i;
>
> std::cout<<"typeid( pa1i).name()="<<typeid(pa1i).name()<<std::endl;
> std::cout<<"typeid( *pa1i).name()="<<typeid(*pa1i).name()<<std::endl;
> std::cout<<"typeid(**pa1i).name()="<<typeid(**pa1i).name()<<std::endl;
> }
>
> pa1i is a pointer to an array of int; *pa1i an array of int (just
> as a1i is); **pa1i is an int.
>
You are confusing types with what is pointed to.
An array of T , is N x T objects
An array-type object is a different thing altogether.
>>>
>>> *p = 1
>>>
>>> is allowed if p is a pointer to an element of an array of int but
>>> not if p is a pointer to an array of int.
>>
>> A pointer to an array of integers can be 2 different tyes of pointer:
>> a) A pointer to integers.
>> b) A pointer to an array-type object.
>
> A pointer to an array of integers is a single type of pointer,
> int(*)[N], where N is the number of array elements, if known. A
> pointer to an integer may point to an element of an array of
> integers.
>
>> A pointer to , for example a char array, is generally consider to be of
>> type
>> char*. An array by nature can only be accesssed one element at a time.
>
> What something is generally considered to be is not necessarily what
> it is according to the C++ standard. According to the C++ standard
> char(*)[N] is a pointer to an array of char, while char* is a pointer
> to a char.
No a char(*)[N] is a TYPE pointer to an array.
Its all about types. An array of objects of type T, is pointed to by a T*.
A T(*)[] type pointer can also point to the array but indirectly.
>
> In some contexts a char* is treated like a pointer to an element of
> an array; in some contexts an array is treated like a pointer to its
> first element. Because in some contexts a thing is treated as if
> it were something else, does not the thing is the something else.
But you have things back to front , a pointer to an array of chars is
firstmost a char*, a char(*)[N] is a pointer to an array-type.
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-04-29 12:57 -0500 |
| Message-ID | <slrnirluvl.11b6.aggedor@earl-grey.cloud9.net> |
| In reply to | #4433 |
On 2011-04-27, Paul <pchristor@yahoo.co.uk> wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrnirgm0l.1f0l.aggedor@earl-grey.cloud9.net...
>> On 2011-04-26, Paul <pchristor@yahoo.co.uk> wrote:
>>>
>>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>>> news:slrnire0ks.gb4.aggedor@earl-grey.cloud9.net...
[snip]
>> What you wrote was
>>
>> No it doesn't
>> *arr =1; /*Accesses the array*/
>> *pparr=1; /*Cannot do this*/
>>
>> in reply to "Dereferencing pparr accesses an array in the same
>> sense that using the name arr accesses an array."
> This statement is incorrect, dereferencing pparr does not access the array
> in the same sense as arr.
In the snipped part, arr and pparr were declared with
int arr[40] = {0};
int (*pparr)[40] = &arr;
An expression that dereferencing pparr has the same result as using
arr; arr and *pparr in expressions have the same type and value. An
example is (*pparr)[3] and arr[3]; they both are the element of arr
3 after its first element.
What is an example where dereferencing pparr does not have the
same result as arr?
>> Your example uses *arr and *pparr as if they were the same; they
>> are not the same. *arr refers to the first element of the array
>> while *pparr refers to the array. *pparr and arr both refer to
>> the array.
> So does :
> int* p = arr;
> So p accesses the array in the same sense as arr.
> pparr has another level of indirection.
p does not access an array in the same sense as arr. p and arr are
different types: p is a pointer to int, while arr is an array of int.
An array and a pointer are not the same, although in some contexts,
such as that initialization, an array is implcitly converted to a
pointer to it first element.
pparr is a level of indirection from arr just as any pointer to
something in C++ is a level of indirection from what it points to.
>> Because pparr is a pointer to an array, of course it has to be
>> dereference twice to get the same result as deferencing the array
>> once. In general, if X points to Y, **X is the same as *Y.
>>
> When you have a pointer to an integer you don't derefernece it twice to
> access the integer.
> So why do you say "of course it has to be dereferneced twice"?
> A pointer to something should not have to be dereferenced twice to access
> what it points to.
I said pparr is dereferenced twice has the same result as
dereferencing arr (the name of the object that pparr points to).
Dereferencing pparr once has the same result as using arr.
With
int i, *pi = &i;
pi is a level of indirection from i. Dereferencing pi accesses an int
in the same sense that i does. Changing i to declare and array and pi
to declare a pointer to an array, changes the declaration to
int arr[40], (*pparr)[40] = &arr;
Given that declaration, dereferencing pparr accesses an array in the
same sense that arr does, just as prior to the change pi accesses an
int in the same sense that i does.
[snip]
>>> So where does the memory address value come from? Its not stored in the
>>> array of integer objects.
>>
>> Where the memory address comes from depends on where the
>> implementation decides to store the array. For example, an object
>> with automatic storage duration, such a non-static array declared
>> in a function, is allocated on the stack in an implementation that
>> uses a stack for automatic storage.
>>
>> The compiler knows the compile-time constant offset in the stack
>> frame where it has decided to store the array. In places where a
>> program needs the memory address of the array, the compiler puts
>> in instructions to sum that compile-time constant offset and the
>> current value of the stack pointer.
>
> This is not a sutable answer , we are talking about array-type object. When
> I asked where the memory address was stored I meant in what object, not in
> what area of memory.
Although it may not be a suitable answer to you, it is what C++
compilers do. You asked "where does the memory address value come
from", and I explained where it comes from.
In C++ an object is a region of storage. The snipped declarations
int arr[4] = {1,2,3,4};
int (*p)[4] = &arr;
allocate an object named arr (and four unmaned subobjects in it) and
an object named p. Because of the initialzation, the expressions **p
and *arr have the same result. The expression **p access only one
stored memory address: the one stored in the object named p. There
is no other object between p and **p.
>>>> The array named arr is stored wherever the C++ implementation decides
>>>> to store it, as long as the program behaves as specified by the C++
>>>> standard. The same is true of the pointer to array named p.
>>>
>>>
>>> Dereferencing pparr once , yields an object which has a value that is the
>>> address of the array. This object must exist someplace prior to it
>>> getting
>>> converted to a pointer.
>>
>> pparr is a pointer to an array. The address of the array it points
>> to is stored in the C++ object allocated for pparr.
> I'm not sure what you mean by this. The object allocated to ppparr is what
> exactly?
The object allocated to pparr is the region of storage used because a
declaration like
int (*pparr)[4];
is in a C++ program.
>> Evaluating
>> *pparr loads that value from memory. In a context where
>> array-to-pointer conversion is done, there is no additional C++
>> object whose value is obtained to convert from the address of an
>> array to a pointer to the first element of the array.
>>
> I don't think so , *pparr dereferences a pointer, there is no
> array-to-pointer conversion here.
pparr is a pointer to an array. The result of *pparr is an array.
Array-to-pointer conversion is implicitly done on that result.
>>> A pointer to an array of integers , is of type int*.
>>> A pointer to an array, in your context, is a pointer to an array-type
>>> object. Which must be dereferenced twice to access the array, the second
>>> dereference will implicitly convert this object to an int*.
>>
>> The type int* is a pointer to int.
> Yes the TYPE is "pointer to int". This type of pointer can point to int
> object/s(singlular or plural).
A pointer to type T may validly point to a single object of type T
(or to the null object) at a given time. In some contexts what it
points to is treated as an element of an array of type T.
>> A pointer to an array of int is
>> type int(*)[N], where N is the number of array elements, if known.
>> A pointer to an array of int is dereferenced once to access the array.
> No this is a poointer to array-type objects, not to integer type objects.
What do you mean "No"? I wrote that it is a "pointer to an array of
int", not a pointer to an int.
>> It may be dereferenced twice to access the first int in the array.
> It MUST be dereferenced twcie, and converted to an int* , to point to any of
> the array elements.
The result of dereferencing it once is an array, just as the name of
the array in an expression is. In this context, that array is
impliclity converted to a pointer to the first element of the array.
Dereferencing that results in the first element of the array.
>> Look at the output of the following program.
>>
>> #include <iostream>
>> #include <typeinfo>
>> int main() {
>> int a1i[4], (*pa1i)[4]=&a1i;
>>
>> std::cout<<"typeid( pa1i).name()="<<typeid(pa1i).name()<<std::endl;
>> std::cout<<"typeid( *pa1i).name()="<<typeid(*pa1i).name()<<std::endl;
>> std::cout<<"typeid(**pa1i).name()="<<typeid(**pa1i).name()<<std::endl;
>> }
>>
>> pa1i is a pointer to an array of int; *pa1i an array of int (just
>> as a1i is); **pa1i is an int.
>>
> You are confusing types with what is pointed to.
> An array of T , is N x T objects
> An array-type object is a different thing altogether.
In C++ an array of type T may be pointed to by a pointer to an array
of type T. An array of type T may also be pointer to by a pointer to
void, but a pointer to void would have be to cast to a pointer to
array to type T before what is pointed to could be used.
>>> A pointer to , for example a char array, is generally consider to be of
>>> type
>>> char*. An array by nature can only be accesssed one element at a time.
>>
>> What something is generally considered to be is not necessarily what
>> it is according to the C++ standard. According to the C++ standard
>> char(*)[N] is a pointer to an array of char, while char* is a pointer
>> to a char.
> No a char(*)[N] is a TYPE pointer to an array.
> Its all about types. An array of objects of type T, is pointed to by a T*.
> A T(*)[] type pointer can also point to the array but indirectly.
That's right, it is about types. A T* points to a T, not an array of
T. A (*T)[] points to an array of T. A pointer is a level of
indirection from what it points to.
>> In some contexts a char* is treated like a pointer to an element of
>> an array; in some contexts an array is treated like a pointer to its
>> first element. Because in some contexts a thing is treated as if
>> it were something else, does not the thing is the something else.
>
> But you have things back to front , a pointer to an array of chars is
> firstmost a char*, a char(*)[N] is a pointer to an array-type.
I have things exactly how they are in the C++ standard, specifically
as in the following example from section 8.1 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 *pi
declares a "pointer to int" and
int (*p3i)[3]
declares a "pointer to array of 3 int". pi may point to an element
in an array of int, but pointing to an element of an array is not
the same as pointing to an array, as p3i does.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-04-29 19:10 +0100 |
| Message-ID | <HpadnXU-6q6sYifQnZ2dnUVZ8qednZ2d@giganews.com> |
| In reply to | #4519 |
On 29/04/2011 18:57, A. Bolmarcich wrote: > > According to the C++ standard > > int *pi > > declares a "pointer to int" and > > int (*p3i)[3] > > declares a "pointer to array of 3 int". pi may point to an element > in an array of int, but pointing to an element of an array is not > the same as pointing to an array, as p3i does. Paul The Troll must have been told this at least 10 times by 10 different people but he still rejects it; you are wasting your time (or you're letting Paul The Troll waste your time). /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-29 19:56 +0100 |
| Message-ID | <ZRDup.44374$0j7.31337@newsfe20.ams2> |
| In reply to | #4519 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
news:slrnirluvl.11b6.aggedor@earl-grey.cloud9.net...
> On 2011-04-27, Paul <pchristor@yahoo.co.uk> wrote:
>>
>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>> news:slrnirgm0l.1f0l.aggedor@earl-grey.cloud9.net...
>>> On 2011-04-26, Paul <pchristor@yahoo.co.uk> wrote:
>>>>
>>>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>>>> news:slrnire0ks.gb4.aggedor@earl-grey.cloud9.net...
> [snip]
>>> What you wrote was
>>>
>>> No it doesn't
>>> *arr =1; /*Accesses the array*/
>>> *pparr=1; /*Cannot do this*/
>>>
>>> in reply to "Dereferencing pparr accesses an array in the same
>>> sense that using the name arr accesses an array."
>> This statement is incorrect, dereferencing pparr does not access the
>> array
>> in the same sense as arr.
>
> In the snipped part, arr and pparr were declared with
>
> int arr[40] = {0};
> int (*pparr)[40] = &arr;
>
> An expression that dereferencing pparr has the same result as using
> arr; arr and *pparr in expressions have the same type and value. An
> example is (*pparr)[3] and arr[3]; they both are the element of arr
> 3 after its first element.
>
> What is an example where dereferencing pparr does not have the
> same result as arr?
You said ..dereferencing pparr accesses the array in the same way as arr,
which it doesn't.
You were/are not accepting the point I was making about dereferncing pparr.
Which was that it does not point to the array directly, it points to an
array-type object.
>
>>> Your example uses *arr and *pparr as if they were the same; they
>>> are not the same. *arr refers to the first element of the array
>>> while *pparr refers to the array. *pparr and arr both refer to
>>> the array.
>> So does :
>> int* p = arr;
>> So p accesses the array in the same sense as arr.
>> pparr has another level of indirection.
>
> p does not access an array in the same sense as arr. p and arr are
> different types: p is a pointer to int, while arr is an array of int.
It doesn't matter if they are different types, they still access the array
in the same sense, because arr is implicitly converted to the same type as
p.
> An array and a pointer are not the same, although in some contexts,
> such as that initialization, an array is implcitly converted to a
> pointer to it first element.
Nobody is saying an array and a pointer are the same. They access the array
in the same the sense.i.e:
arr[1];
p[1];
Both are subscripted only once to access the array.
>
> pparr is a level of indirection from arr just as any pointer to
> something in C++ is a level of indirection from what it points to.
No its not with arrays, an array of integers is pointed to by an int*( in
most cases), it can also be pointed to by an int(*)[N] for the purpose of
converting to reference, for example.
>>> Because pparr is a pointer to an array, of course it has to be
>>> dereference twice to get the same result as deferencing the array
>>> once. In general, if X points to Y, **X is the same as *Y.
>>>
>> When you have a pointer to an integer you don't derefernece it twice to
>> access the integer.
>> So why do you say "of course it has to be dereferneced twice"?
>> A pointer to something should not have to be dereferenced twice to access
>> what it points to.
>
> I said pparr is dereferenced twice has the same result as
> dereferencing arr (the name of the object that pparr points to).
> Dereferencing pparr once has the same result as using arr.
Yes so does this not prove to you that pparr is a different level of
indirection than arr?
pparr is a pointer to an array-type object. This does not automatically
imply that an int* cannot point to an array of integers.
>
> With
>
> int i, *pi = &i;
>
> pi is a level of indirection from i. Dereferencing pi accesses an int
> in the same sense that i does. Changing i to declare and array and pi
> to declare a pointer to an array, changes the declaration to
>
> int arr[40], (*pparr)[40] = &arr;
>
> Given that declaration, dereferencing pparr accesses an array in the
> same sense that arr does, just as prior to the change pi accesses an
> int in the same sense that i does.
Yes so this proves that pparr is a different level of indirection than arr.
arr accesses the array by directly converting to a pointer , pparr needs
indirection and then converted to a pointer.
>
> [snip]
>
>>>> So where does the memory address value come from? Its not stored in the
>>>> array of integer objects.
>>>
>>> Where the memory address comes from depends on where the
>>> implementation decides to store the array. For example, an object
>>> with automatic storage duration, such a non-static array declared
>>> in a function, is allocated on the stack in an implementation that
>>> uses a stack for automatic storage.
>>>
>>> The compiler knows the compile-time constant offset in the stack
>>> frame where it has decided to store the array. In places where a
>>> program needs the memory address of the array, the compiler puts
>>> in instructions to sum that compile-time constant offset and the
>>> current value of the stack pointer.
>>
>> This is not a sutable answer , we are talking about array-type object.
>> When
>> I asked where the memory address was stored I meant in what object, not
>> in
>> what area of memory.
>
> Although it may not be a suitable answer to you, it is what C++
> compilers do. You asked "where does the memory address value come
> from", and I explained where it comes from.
>
> In C++ an object is a region of storage. The snipped declarations
>
> int arr[4] = {1,2,3,4};
> int (*p)[4] = &arr;
>
> allocate an object named arr (and four unmaned subobjects in it) and
> an object named p. Because of the initialzation, the expressions **p
> and *arr have the same result. The expression **p access only one
> stored memory address: the one stored in the object named p. There
> is no other object between p and **p.
>
So answer the question if you are so smart.
What object stores the value of the address we get when we dereference
pparr?
>>>>> The array named arr is stored wherever the C++ implementation decides
>>>>> to store it, as long as the program behaves as specified by the C++
>>>>> standard. The same is true of the pointer to array named p.
>>>>
>>>>
>>>> Dereferencing pparr once , yields an object which has a value that is
>>>> the
>>>> address of the array. This object must exist someplace prior to it
>>>> getting
>>>> converted to a pointer.
>>>
>>> pparr is a pointer to an array. The address of the array it points
>>> to is stored in the C++ object allocated for pparr.
>> I'm not sure what you mean by this. The object allocated to ppparr is
>> what
>> exactly?
>
> The object allocated to pparr is the region of storage used because a
> declaration like
>
> int (*pparr)[4];
>
> is in a C++ program.
>
>>> Evaluating
>>> *pparr loads that value from memory. In a context where
>>> array-to-pointer conversion is done, there is no additional C++
>>> object whose value is obtained to convert from the address of an
>>> array to a pointer to the first element of the array.
>>>
>> I don't think so , *pparr dereferences a pointer, there is no
>> array-to-pointer conversion here.
>
> pparr is a pointer to an array. The result of *pparr is an array.
> Array-to-pointer conversion is implicitly done on that result.
That would be pointer-array conversion , not array-pointer.
>
>>>> A pointer to an array of integers , is of type int*.
>>>> A pointer to an array, in your context, is a pointer to an array-type
>>>> object. Which must be dereferenced twice to access the array, the
>>>> second
>>>> dereference will implicitly convert this object to an int*.
>>>
>>> The type int* is a pointer to int.
>> Yes the TYPE is "pointer to int". This type of pointer can point to int
>> object/s(singlular or plural).
>
> A pointer to type T may validly point to a single object of type T
> (or to the null object) at a given time. In some contexts what it
> points to is treated as an element of an array of type T.
>
A pointer to type T can point to a whole array of T's.
Maybe it cannot access them all at the same time but then , no pointer type
can.
>>> A pointer to an array of int is
>>> type int(*)[N], where N is the number of array elements, if known.
>>> A pointer to an array of int is dereferenced once to access the array.
>> No this is a poointer to array-type objects, not to integer type objects.
>
> What do you mean "No"? I wrote that it is a "pointer to an array of
> int", not a pointer to an int.
But you omit the word TYPE.
A pointer to an array of integer objects, or a single int, is of type int*.
A pointer to an array of int-array-objects, or a single int-array-object ,
is of type int(*)[N]
>
>>> It may be dereferenced twice to access the first int in the array.
>> It MUST be dereferenced twcie, and converted to an int* , to point to any
>> of
>> the array elements.
>
> The result of dereferencing it once is an array, just as the name of
> the array in an expression is.
dereferencing it yields an array-type object, you know the one that stores
the memory address, not THE array of integer objects.
> In this context, that array is
> impliclity converted to a pointer to the first element of the array.
> Dereferencing that results in the first element of the array.
>
>>> Look at the output of the following program.
>>>
>>> #include <iostream>
>>> #include <typeinfo>
>>> int main() {
>>> int a1i[4], (*pa1i)[4]=&a1i;
>>>
>>> std::cout<<"typeid( pa1i).name()="<<typeid(pa1i).name()<<std::endl;
>>> std::cout<<"typeid( *pa1i).name()="<<typeid(*pa1i).name()<<std::endl;
>>>
>>> std::cout<<"typeid(**pa1i).name()="<<typeid(**pa1i).name()<<std::endl;
>>> }
>>>
>>> pa1i is a pointer to an array of int; *pa1i an array of int (just
>>> as a1i is); **pa1i is an int.
>>>
>> You are confusing types with what is pointed to.
>> An array of T , is N x T objects
>> An array-type object is a different thing altogether.
>
> In C++ an array of type T may be pointed to by a pointer to an array
> of type T. An array of type T may also be pointer to by a pointer to
> void, but a pointer to void would have be to cast to a pointer to
> array to type T before what is pointed to could be used.
>
In C++ a pointer-type does not define what is pointed to.
>>>> A pointer to , for example a char array, is generally consider to be of
>>>> type
>>>> char*. An array by nature can only be accesssed one element at a time.
>>>
>>> What something is generally considered to be is not necessarily what
>>> it is according to the C++ standard. According to the C++ standard
>>> char(*)[N] is a pointer to an array of char, while char* is a pointer
>>> to a char.
>> No a char(*)[N] is a TYPE pointer to an array.
>> Its all about types. An array of objects of type T, is pointed to by a
>> T*.
>> A T(*)[] type pointer can also point to the array but indirectly.
>
> That's right, it is about types. A T* points to a T, not an array of
> T. A (*T)[] points to an array of T. A pointer is a level of
> indirection from what it points to.
its different with arrays.
>
>>> In some contexts a char* is treated like a pointer to an element of
>>> an array; in some contexts an array is treated like a pointer to its
>>> first element. Because in some contexts a thing is treated as if
>>> it were something else, does not the thing is the something else.
>>
>> But you have things back to front , a pointer to an array of chars is
>> firstmost a char*, a char(*)[N] is a pointer to an array-type.
>
> I have things exactly how they are in the C++ standard, specifically
> as in the following example from section 8.1 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 *pi
>
> declares a "pointer to int" and
>
> int (*p3i)[3]
>
> declares a "pointer to array of 3 int". pi may point to an element
> in an array of int, but pointing to an element of an array is not
> the same as pointing to an array, as p3i does.
No the standard say its of TYPE pointer to array.
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-05-02 13:20 -0500 |
| Message-ID | <slrnirttg4.1nli.aggedor@earl-grey.cloud9.net> |
| In reply to | #4522 |
On 2011-04-29, Paul <pchristor@yahoo.co.uk> wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrnirluvl.11b6.aggedor@earl-grey.cloud9.net...
>> On 2011-04-27, Paul <pchristor@yahoo.co.uk> wrote:
>>>
>>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>>> news:slrnirgm0l.1f0l.aggedor@earl-grey.cloud9.net...
>>>> On 2011-04-26, Paul <pchristor@yahoo.co.uk> wrote:
>>>>>
>>>>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>>>>> news:slrnire0ks.gb4.aggedor@earl-grey.cloud9.net...
>> [snip]
>>>> What you wrote was
>>>>
>>>> No it doesn't
>>>> *arr =1; /*Accesses the array*/
>>>> *pparr=1; /*Cannot do this*/
>>>>
>>>> in reply to "Dereferencing pparr accesses an array in the same
>>>> sense that using the name arr accesses an array."
>>> This statement is incorrect, dereferencing pparr does not access the
>>> array
>>> in the same sense as arr.
>>
>> In the snipped part, arr and pparr were declared with
>>
>> int arr[40] = {0};
>> int (*pparr)[40] = &arr;
>>
>> An expression that dereferencing pparr has the same result as using
>> arr; arr and *pparr in expressions have the same type and value. An
>> example is (*pparr)[3] and arr[3]; they both are the element of arr
>> 3 after its first element.
>>
>> What is an example where dereferencing pparr does not have the
>> same result as arr?
> You said ..dereferencing pparr accesses the array in the same way as arr,
> which it doesn't.
You claim "it doesn't", but you do not provide an example that
supports your claim. I have provided examples that supports mine.
> You were/are not accepting the point I was making about dereferncing pparr.
> Which was that it does not point to the array directly, it points to an
> array-type object.
I don't accept a point about C++ that is not supported by the C++
standard. pparr points directly to the array; it does not point to
another object. Look at the output of the following program.
#include <iostream>
#include <typeinfo>
int main() {
int arr[40], (*pparr)[40]=&arr;
std::cout
<<"arr"
<<(arr==*pparr?"==":"!=")
<<"*pparr"
<<" "
<<"typeid(arr).name()"
<<(typeid(arr).name()==typeid(*pparr).name()?"==":"!=")
<<"typeid(*pparr).name()"
<<std::endl;
}
The output that I get is that the values and types of arr and
*pparr are the same.
>>>> Your example uses *arr and *pparr as if they were the same; they
>>>> are not the same. *arr refers to the first element of the array
>>>> while *pparr refers to the array. *pparr and arr both refer to
>>>> the array.
>>> So does :
>>> int* p = arr;
>>> So p accesses the array in the same sense as arr.
>>> pparr has another level of indirection.
>>
>> p does not access an array in the same sense as arr. p and arr are
>> different types: p is a pointer to int, while arr is an array of int.
> It doesn't matter if they are different types, they still access the array
> in the same sense, because arr is implicitly converted to the same type as
> p.
That implicit conversion is done only in some contexts. p does not
access the array in same sense as arr in other contexts. *pparr
accesses the array in the same sense as arr in all contexts.
>> An array and a pointer are not the same, although in some contexts,
>> such as that initialization, an array is implcitly converted to a
>> pointer to it first element.
> Nobody is saying an array and a pointer are the same. They access the array
> in the same the sense.i.e:
> arr[1];
> p[1];
> Both are subscripted only once to access the array.
Someone who says a pointer to the first element of an array is
pointing to an array is saying the pointer and the array the element
is in are the same.
>> pparr is a level of indirection from arr just as any pointer to
>> something in C++ is a level of indirection from what it points to.
> No its not with arrays, an array of integers is pointed to by an int*( in
> most cases), it can also be pointed to by an int(*)[N] for the purpose of
> converting to reference, for example.
I don't understand what your reply has to do what the statement I
made about a level of indirection.
>>>> Because pparr is a pointer to an array, of course it has to be
>>>> dereference twice to get the same result as deferencing the array
>>>> once. In general, if X points to Y, **X is the same as *Y.
>>>>
>>> When you have a pointer to an integer you don't derefernece it twice to
>>> access the integer.
>>> So why do you say "of course it has to be dereferneced twice"?
>>> A pointer to something should not have to be dereferenced twice to access
>>> what it points to.
>>
>> I said pparr is dereferenced twice has the same result as
>> dereferencing arr (the name of the object that pparr points to).
>> Dereferencing pparr once has the same result as using arr.
> Yes so does this not prove to you that pparr is a different level of
> indirection than arr?
> pparr is a pointer to an array-type object. This does not automatically
> imply that an int* cannot point to an array of integers.
As I have said, pparr is a level of indirection from arr, just at
any pointer to something is a level of indirection away from what
it points to. A pointer to an element of an array is a level of
indirection from an element of an array, not a level of indirection
from an array.
The fact that an int(*)[] (pointer to array of int) cannot be assigned
to an int* (pointer to int) implies that an int* cannot point to an
array of integers. An int* can point to an element of an array of
integers.
>>
>> With
>>
>> int i, *pi = &i;
>>
>> pi is a level of indirection from i. Dereferencing pi accesses an int
>> in the same sense that i does. Changing i to declare and array and pi
>> to declare a pointer to an array, changes the declaration to
>>
>> int arr[40], (*pparr)[40] = &arr;
>>
>> Given that declaration, dereferencing pparr accesses an array in the
>> same sense that arr does, just as prior to the change pi accesses an
>> int in the same sense that i does.
> Yes so this proves that pparr is a different level of indirection than arr.
> arr accesses the array by directly converting to a pointer , pparr needs
> indirection and then converted to a pointer.
The results of dereferencing pparr and using arr are the same (see
the output of the program given eariler in this followup). In
other words, dereferencing pparr accesses an array in the same sense
that using the name arr accesses an array.
[snip]
>> In C++ an object is a region of storage. The snipped declarations
>>
>> int arr[4] = {1,2,3,4};
>> int (*p)[4] = &arr;
>>
>> allocate an object named arr (and four unmaned subobjects in it) and
>> an object named p. Because of the initialzation, the expressions **p
>> and *arr have the same result. The expression **p access only one
>> stored memory address: the one stored in the object named p. There
>> is no other object between p and **p.
>>
> So answer the question if you are so smart.
> What object stores the value of the address we get when we dereference
> pparr?
The result of dereferencing pparr, such as in the subexpression *p of
**p == 1
is not stored in an object. It is not a matter of being smart; it
is a matter of understanding the definition of object in the C++
standard and certain details of C++ compilers.
[snip]
>>>> Evaluating
>>>> *pparr loads that value from memory. In a context where
>>>> array-to-pointer conversion is done, there is no additional C++
>>>> object whose value is obtained to convert from the address of an
>>>> array to a pointer to the first element of the array.
>>>>
>>> I don't think so , *pparr dereferences a pointer, there is no
>>> array-to-pointer conversion here.
>>
>> pparr is a pointer to an array. The result of *pparr is an array.
>> Array-to-pointer conversion is implicitly done on that result.
>
> That would be pointer-array conversion , not array-pointer.
The section in the C++ standard has the heading "Array-to-pointer
conversion". I use the same term as is used in the C++ standard.
[snip]
> A pointer to type T can point to a whole array of T's.
> Maybe it cannot access them all at the same time but then , no pointer type
> can.
A pointer to type T can point to an element of an array of T. At
any one time, it points to at most one element of an array of T. At
no time does it point to a whole array a T's. A whole array of T's
is pointed to by a pointer to an array of T, not by a pointer to T.
>>>> A pointer to an array of int is
>>>> type int(*)[N], where N is the number of array elements, if known.
>>>> A pointer to an array of int is dereferenced once to access the array.
>>> No this is a poointer to array-type objects, not to integer type objects.
>>
>> What do you mean "No"? I wrote that it is a "pointer to an array of
>> int", not a pointer to an int.
> But you omit the word TYPE.
> A pointer to an array of integer objects, or a single int, is of type int*.
> A pointer to an array of int-array-objects, or a single int-array-object ,
> is of type int(*)[N]
In what I wrote, replacing "pointer to an" with "pointer of type"
results in: 'a "pointer of type array of int", not a pointer of
type int'. A pointer of type array of int points to an object with
an array type, not to an object with an int type.
[snip]
>> The result of dereferencing it once is an array, just as the name of
>> the array in an expression is.
> dereferencing it yields an array-type object, you know the one that stores
> the memory address, not THE array of integer objects.
Dereferencing it (a pointer to an array of int) results in an array
of int, the one that was allocated by the declaration of the array
whose address was assgined to the pointer to array. Dereferencing
a pointer to an array of int does not result in an object that
stores the memory address of an array.
[snip]
> In C++ a pointer-type does not define what is pointed to.
In C++ the pointer-type determines the type of the result of
dereferencing the pointer. Here is paragraph 1 of section 5.3.1 (Unary
operators) 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.]
I accept what is in the C++ standard: "If the type of the expression
is pointer to T, the type of the result is T."
>>>>> A pointer to , for example a char array, is generally consider to be of
>>>>> type
>>>>> char*. An array by nature can only be accesssed one element at a time.
>>>>
>>>> What something is generally considered to be is not necessarily what
>>>> it is according to the C++ standard. According to the C++ standard
>>>> char(*)[N] is a pointer to an array of char, while char* is a pointer
>>>> to a char.
>>> No a char(*)[N] is a TYPE pointer to an array.
>>> Its all about types. An array of objects of type T, is pointed to by a
>>> T*.
>>> A T(*)[] type pointer can also point to the array but indirectly.
>>
>> That's right, it is about types. A T* points to a T, not an array of
>> T. A (*T)[] points to an array of T. A pointer is a level of
>> indirection from what it points to.
> its different with arrays.
No, pointers and levels of indirection are the same with arrays.
What is different with arrays is that in some contexts an array is
implicitly converted to a pointer to the first element of the array.
>>>> In some contexts a char* is treated like a pointer to an element of
>>>> an array; in some contexts an array is treated like a pointer to its
>>>> first element. Because in some contexts a thing is treated as if
>>>> it were something else, does not the thing is the something else.
>>>
>>> But you have things back to front , a pointer to an array of chars is
>>> firstmost a char*, a char(*)[N] is a pointer to an array-type.
>>
>> I have things exactly how they are in the C++ standard, specifically
>> as in the following example from section 8.1 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 *pi
>>
>> declares a "pointer to int" and
>>
>> int (*p3i)[3]
>>
>> declares a "pointer to array of 3 int". pi may point to an element
>> in an array of int, but pointing to an element of an array is not
>> the same as pointing to an array, as p3i does.
> No the standard say its of TYPE pointer to array.
You are the one who wrote (quoted about 50 lines above): "Its all
about types." A value of type int* points to an int and a value of
type int(*)[] points to an array of int; the two are not the same.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-02 22:43 +0100 |
| Message-ID | <HAFvp.58280$7u3.32095@newsfe04.ams2> |
| In reply to | #4584 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
news:slrnirttg4.1nli.aggedor@earl-grey.cloud9.net...
>>> [snip]
>>>>> What you wrote was
>>>>>
>>>>> No it doesn't
>>>>> *arr =1; /*Accesses the array*/
>>>>> *pparr=1; /*Cannot do this*/
>>>>>
>>>>> in reply to "Dereferencing pparr accesses an array in the same
>>>>> sense that using the name arr accesses an array."
>>>> This statement is incorrect, dereferencing pparr does not access the
>>>> array
>>>> in the same sense as arr.
>>>
>>> In the snipped part, arr and pparr were declared with
>>>
>>> int arr[40] = {0};
>>> int (*pparr)[40] = &arr;
>>>
>>> An expression that dereferencing pparr has the same result as using
>>> arr; arr and *pparr in expressions have the same type and value. An
>>> example is (*pparr)[3] and arr[3]; they both are the element of arr
>>> 3 after its first element.
>>>
>>> What is an example where dereferencing pparr does not have the
>>> same result as arr?
>> You said ..dereferencing pparr accesses the array in the same way as arr,
>> which it doesn't.
>
> You claim "it doesn't", but you do not provide an example that
> supports your claim. I have provided examples that supports mine.
I have provided the proof that pparr needs to be dereferenced twice , and
arr once, to access the array. Thus dereferencing them does not access the
array in the same way.
I know what you mean but what you said is incorrect. You mean that
dereferencing pparr once then makes it the same as arr, so it can then be
subscripted to access the array. But you originally said this in response to
a point I was making about how pparr needs to be dereferenced twice to
access the array. You don't accept the point I was making therefore I do not
accept your statement, which is incorrect anyway.
>
>> You were/are not accepting the point I was making about dereferncing
>> pparr.
>> Which was that it does not point to the array directly, it points to an
>> array-type object.
>
> I don't accept a point about C++ that is not supported by the C++
> standard. pparr points directly to the array; it does not point to
> another object. Look at the output of the following program.
So what does it access to produce a memory address when dereferenced?
<snip>
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-05-05 14:13 -0500 |
| Message-ID | <slrnis5tnj.2g8c.aggedor@earl-grey.cloud9.net> |
| In reply to | #4591 |
On 2011-05-02, Paul <pchristor@yahoo.co.uk> wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrnirttg4.1nli.aggedor@earl-grey.cloud9.net...
>>>> [snip]
>>>>>> What you wrote was
>>>>>>
>>>>>> No it doesn't
>>>>>> *arr =1; /*Accesses the array*/
>>>>>> *pparr=1; /*Cannot do this*/
>>>>>>
>>>>>> in reply to "Dereferencing pparr accesses an array in the same
>>>>>> sense that using the name arr accesses an array."
>>>>> This statement is incorrect, dereferencing pparr does not access the
>>>>> array
>>>>> in the same sense as arr.
>>>>
>>>> In the snipped part, arr and pparr were declared with
>>>>
>>>> int arr[40] = {0};
>>>> int (*pparr)[40] = &arr;
>>>>
>>>> An expression that dereferencing pparr has the same result as using
>>>> arr; arr and *pparr in expressions have the same type and value. An
>>>> example is (*pparr)[3] and arr[3]; they both are the element of arr
>>>> 3 after its first element.
>>>>
>>>> What is an example where dereferencing pparr does not have the
>>>> same result as arr?
>>> You said ..dereferencing pparr accesses the array in the same way as arr,
>>> which it doesn't.
>>
>> You claim "it doesn't", but you do not provide an example that
>> supports your claim. I have provided examples that supports mine.
> I have provided the proof that pparr needs to be dereferenced twice , and
> arr once, to access the array. Thus dereferencing them does not access the
> array in the same way.
I wrote: "Dereferencing pparr accesses an array in the same sense
that using the name arr accesses an array." You replied that it
doesn't". Please provide an example that supports your claim that
dereferencing pparr doesn't access an array in the same sense that
using the name arr accesses an array. Dereferencing pparr twice and
arr once does not directly address whether dereferencing pparr (once)
and arr (not at all) access an array in the same sense.
> I know what you mean but what you said is incorrect. You mean that
> dereferencing pparr once then makes it the same as arr, so it can then be
> subscripted to access the array. But you originally said this in response to
> a point I was making about how pparr needs to be dereferenced twice to
> access the array. You don't accept the point I was making therefore I do not
> accept your statement, which is incorrect anyway.
No, I meant what I wrote: "Dereferencing pparr accesses an array in the
same sense that using the name arr accesses an array." I originally
wrote that in response to what you wrote: "Dereferencing pparr does not
access the array it accesses a temporary pointer." See:
http://groups.google.com/group/comp.lang.c++/msg/d921556db52ce388?hl=en
Let me see if I have this right, you don't accept my statement not
because of what is in the statement but because you, mistakenly,
think the statement was a response to a statemenet about
dereferencing pparr twice.
>>> You were/are not accepting the point I was making about dereferncing
>>> pparr.
>>> Which was that it does not point to the array directly, it points to an
>>> array-type object.
>>
>> I don't accept a point about C++ that is not supported by the C++
>> standard. pparr points directly to the array; it does not point to
>> another object. Look at the output of the following program.
> So what does it access to produce a memory address when dereferenced?
I answered that question in lines that you silently snipped from your
followup. Here is the answer again, with 1) the name of the pointer
to array changed to pparr, 2) additional details, and 3) spelling
and grammar corrections.
In C++ an object is a region of storage. The snipped declarations
int arr[4] = {1,2,3,4};
int (*pparr)[4] = &arr;
allocate an object named arr (and four unnamed int subobjects in
it) and an object named pparr. Because of the initialzation, the
expressions **pparr and *arr have the same result. The expression
**pparr accesses only one stored memory address: the one stored in
the object named pparr. There is no other object between pparr
and **pparr that stores a memory address.
Evaluating pparr accesses the value stored in the object allocated for
it (the object named pparr). The value is the memory address of the
array (the value to which pparr was initialized). The result of
evaluating *pparr is the int[4] at that address. The result of
evaluating **pparr is the int at that address, to get this result
there was an implicit array-to-pointer conversion on the array
result of *pparr.
The bottom line is that the expression **pparr accesses only one
stored memory address: the one stored in the object named pparr.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-05 22:21 +0100 |
| Message-ID | <VxEwp.48432$bT6.15330@newsfe05.ams2> |
| In reply to | #4738 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
news:slrnis5tnj.2g8c.aggedor@earl-grey.cloud9.net...
> On 2011-05-02, Paul <pchristor@yahoo.co.uk> wrote:
>>
>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>> news:slrnirttg4.1nli.aggedor@earl-grey.cloud9.net...
>>>>> [snip]
>>>>>>> What you wrote was
>>>>>>>
>>>>>>> No it doesn't
>>>>>>> *arr =1; /*Accesses the array*/
>>>>>>> *pparr=1; /*Cannot do this*/
>>>>>>>
>>>>>>> in reply to "Dereferencing pparr accesses an array in the same
>>>>>>> sense that using the name arr accesses an array."
>>>>>> This statement is incorrect, dereferencing pparr does not access the
>>>>>> array
>>>>>> in the same sense as arr.
>>>>>
>>>>> In the snipped part, arr and pparr were declared with
>>>>>
>>>>> int arr[40] = {0};
>>>>> int (*pparr)[40] = &arr;
>>>>>
>>>>> An expression that dereferencing pparr has the same result as using
>>>>> arr; arr and *pparr in expressions have the same type and value. An
>>>>> example is (*pparr)[3] and arr[3]; they both are the element of arr
>>>>> 3 after its first element.
>>>>>
>>>>> What is an example where dereferencing pparr does not have the
>>>>> same result as arr?
>>>> You said ..dereferencing pparr accesses the array in the same way as
>>>> arr,
>>>> which it doesn't.
>>>
>>> You claim "it doesn't", but you do not provide an example that
>>> supports your claim. I have provided examples that supports mine.
>> I have provided the proof that pparr needs to be dereferenced twice , and
>> arr once, to access the array. Thus dereferencing them does not access
>> the
>> array in the same way.
>
> I wrote: "Dereferencing pparr accesses an array in the same sense
> that using the name arr accesses an array." You replied that it
> doesn't". Please provide an example that supports your claim that
> dereferencing pparr doesn't access an array in the same sense that
> using the name arr accesses an array. Dereferencing pparr twice and
> arr once does not directly address whether dereferencing pparr (once)
> and arr (not at all) access an array in the same sense.
pparr needs to be dereferenced twice , and arr only once, to access the
array.
>
>> I know what you mean but what you said is incorrect. You mean that
>> dereferencing pparr once then makes it the same as arr, so it can then be
>> subscripted to access the array. But you originally said this in response
>> to
>> a point I was making about how pparr needs to be dereferenced twice to
>> access the array. You don't accept the point I was making therefore I do
>> not
>> accept your statement, which is incorrect anyway.
>
> No, I meant what I wrote: "Dereferencing pparr accesses an array in the
> same sense that using the name arr accesses an array." I originally
> wrote that in response to what you wrote: "Dereferencing pparr does not
> access the array it accesses a temporary pointer." See:
> http://groups.google.com/group/comp.lang.c++/msg/d921556db52ce388?hl=en
>
> Let me see if I have this right, you don't accept my statement not
> because of what is in the statement but because you, mistakenly,
> think the statement was a response to a statemenet about
> dereferencing pparr twice.
No your statement is rubbish, because it was in response to the point I said
that pparr needs to be dereferenced twice., which is correct. I was speaking
about dereferencing pparr once and that it does not access the array.
You replied with this nonsense that dereferencing pparr accesses the array
in the same way as arr.
That would be dereferencing pparr twice and dereferencing arr once, which is
not the same at all.
>
>>>> You were/are not accepting the point I was making about dereferncing
>>>> pparr.
>>>> Which was that it does not point to the array directly, it points to an
>>>> array-type object.
>>>
>>> I don't accept a point about C++ that is not supported by the C++
>>> standard. pparr points directly to the array; it does not point to
>>> another object. Look at the output of the following program.
>> So what does it access to produce a memory address when dereferenced?
>
> I answered that question in lines that you silently snipped from your
> followup. Here is the answer again, with 1) the name of the pointer
> to array changed to pparr, 2) additional details, and 3) spelling
> and grammar corrections.
>
> In C++ an object is a region of storage. The snipped declarations
>
> int arr[4] = {1,2,3,4};
> int (*pparr)[4] = &arr;
>
> allocate an object named arr (and four unnamed int subobjects in
> it) and an object named pparr. Because of the initialzation, the
> expressions **pparr and *arr have the same result. The expression
> **pparr accesses only one stored memory address: the one stored in
> the object named pparr. There is no other object between pparr
> and **pparr that stores a memory address.
No you are wrong. arr stores the address of the array. arr is the array-type
object, that pparr points to.
>
> Evaluating pparr accesses the value stored in the object allocated for
> it (the object named pparr).
> The value is the memory address of the
> array (the value to which pparr was initialized). The result of
> evaluating *pparr is the int[4] at that address.
No its the not, it's an object of TYPE int[4]. Evaluating *pparr does not
yield or access 4 integers, it yields an array-type object which has a
memory address value.
> The result of
> evaluating **pparr is the int at that address, to get this result
> there was an implicit array-to-pointer conversion on the array
> result of *pparr.
You still do not accept what the result of *pparr is. Evaluating **pparr is
not the question here, I have told you umpteen times that dereferencing
twice accesses the array.
>
> The bottom line is that the expression **pparr accesses only one
> stored memory address: the one stored in the object named pparr.
You cannot access a whole array simultaneously. You can only represent this
concept with an object type.
But you fail to answer the question which was what is accessed, with *pparr,
to produce a memory address? You can waffle on all day about what **pparr
accesses but this does not answer the above.
As I have said its an array-type object which stores the address of the
array, you seem to disagree but you are providing no reasonable reasons why.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-06 10:49 +1200 |
| Message-ID | <92gnsmFv9pU3@mid.individual.net> |
| In reply to | #4740 |
On 05/ 6/11 09:21 AM, Paul wrote: > > "A. Bolmarcich"<aggedor@earl-grey.cloud9.net> wrote: >> >> I wrote: "Dereferencing pparr accesses an array in the same sense >> that using the name arr accesses an array." You replied that it >> doesn't". Please provide an example that supports your claim that >> dereferencing pparr doesn't access an array in the same sense that >> using the name arr accesses an array. Dereferencing pparr twice and >> arr once does not directly address whether dereferencing pparr (once) >> and arr (not at all) access an array in the same sense. > > pparr needs to be dereferenced twice , and arr only once, to access the > array. Would you care to explain the difference between "Dereferencing pparr accesses an array in the same sense that using the name arr accesses an array." and "pparr needs to be dereferenced twice, and arr only once, to access the array."? The former is analogous to "subtracting 1 from 2 is equivalent to 1" and latter is analogous to "subtracting 2 from 2 equivalent to subtracting 1 from 1" Both are correct. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-06 12:29 +0100 |
| Message-ID | <3YQwp.5829$Pi.933@newsfe22.ams2> |
| In reply to | #4741 |
"Ian Collins" <ian-news@hotmail.com> wrote in message news:92gnsmFv9pU3@mid.individual.net... > On 05/ 6/11 09:21 AM, Paul wrote: >> >> "A. Bolmarcich"<aggedor@earl-grey.cloud9.net> wrote: >>> >>> I wrote: "Dereferencing pparr accesses an array in the same sense >>> that using the name arr accesses an array." You replied that it >>> doesn't". Please provide an example that supports your claim that >>> dereferencing pparr doesn't access an array in the same sense that >>> using the name arr accesses an array. Dereferencing pparr twice and >>> arr once does not directly address whether dereferencing pparr (once) >>> and arr (not at all) access an array in the same sense. >> >> pparr needs to be dereferenced twice , and arr only once, to access the >> array. > > Would you care to explain the difference between > > "Dereferencing pparr accesses an array in the same sense that using the > name arr accesses an array." > > and > > "pparr needs to be dereferenced twice, and arr only once, to access the > array."? > pparr points to an array-type object. arr points to an array of integer-type objects. That's the difference.
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-05-07 11:34 -0500 |
| Message-ID | <slrnisat4r.1649.aggedor@earl-grey.cloud9.net> |
| In reply to | #4740 |
On 2011-05-05, Paul <pchristor@yahoo.co.uk> wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrnis5tnj.2g8c.aggedor@earl-grey.cloud9.net...
>> On 2011-05-02, Paul <pchristor@yahoo.co.uk> wrote:
>>>
>>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>>> news:slrnirttg4.1nli.aggedor@earl-grey.cloud9.net...
[snip]
>> I wrote: "Dereferencing pparr accesses an array in the same sense
>> that using the name arr accesses an array." You replied that it
>> doesn't". Please provide an example that supports your claim that
>> dereferencing pparr doesn't access an array in the same sense that
>> using the name arr accesses an array. Dereferencing pparr twice and
>> arr once does not directly address whether dereferencing pparr (once)
>> and arr (not at all) access an array in the same sense.
>
> pparr needs to be dereferenced twice , and arr only once, to access the
> array.
That does not show that dereferencing pparr doesn't access an array
in the same sense that using the name arr accesses an array. An
example that shows it would dereference pparr once and arr not at all.
The fact that
*pparr and arr access an array in same sense
implies that
**pparr and *arr access the first element of that array
What *arr accesses is the first element of an array. Because an
array and elements of it have different types, accessing the first
element of an array is not the same as accessing the array.
>>> I know what you mean but what you said is incorrect. You mean that
>>> dereferencing pparr once then makes it the same as arr, so it can then be
>>> subscripted to access the array. But you originally said this in response
>>> to
>>> a point I was making about how pparr needs to be dereferenced twice to
>>> access the array. You don't accept the point I was making therefore I do
>>> not
>>> accept your statement, which is incorrect anyway.
>>
>> No, I meant what I wrote: "Dereferencing pparr accesses an array in the
>> same sense that using the name arr accesses an array." I originally
>> wrote that in response to what you wrote: "Dereferencing pparr does not
>> access the array it accesses a temporary pointer." See:
>> http://groups.google.com/group/comp.lang.c++/msg/d921556db52ce388?hl=en
>>
>> Let me see if I have this right, you don't accept my statement not
>> because of what is in the statement but because you, mistakenly,
>> think the statement was a response to a statemenet about
>> dereferencing pparr twice.
> No your statement is rubbish, because it was in response to the point I said
> that pparr needs to be dereferenced twice., which is correct. I was speaking
> about dereferencing pparr once and that it does not access the array.
> You replied with this nonsense that dereferencing pparr accesses the array
> in the same way as arr.
Open the google groups URL I provided. It clearly shows what I was
responding to when I originally made the statement; what I was
responding to was not a statement about pparr needing to be
dereferenced twice.
The statement I made is neither rubbish or nonsense. If you have
an example to support those claims, please post it. What is
rubbish and nonsense is making a claim but not being able to support
it with evidence, such as an example that supports the claim.
> That would be dereferencing pparr twice and dereferencing arr once, which is
> not the same at all.
What I wrote was: "Dereferencing pparr accesses an array in the
same sense that using the name arr accesses an array." I did not
write that dereferencing pparr twice and arr once dereferences both
of them the same number of times. The results of dereferencing pparr
twice and arr once are the same. In both cases the result is the
first element of the array.
[snip]
>>> So what does it access to produce a memory address when dereferenced?
>>
>> I answered that question in lines that you silently snipped from your
>> followup. Here is the answer again, with 1) the name of the pointer
>> to array changed to pparr, 2) additional details, and 3) spelling
>> and grammar corrections.
>>
>> In C++ an object is a region of storage. The snipped declarations
>>
>> int arr[4] = {1,2,3,4};
>> int (*pparr)[4] = &arr;
>>
>> allocate an object named arr (and four unnamed int subobjects in
>> it) and an object named pparr. Because of the initialzation, the
>> expressions **pparr and *arr have the same result. The expression
>> **pparr accesses only one stored memory address: the one stored in
>> the object named pparr. There is no other object between pparr
>> and **pparr that stores a memory address.
>
> No you are wrong. arr stores the address of the array. arr is the array-type
> object, that pparr points to.
arr does not store the address of the array; it stores an array of 4
int.
>> Evaluating pparr accesses the value stored in the object allocated for
>> it (the object named pparr).
>> The value is the memory address of the
>> array (the value to which pparr was initialized). The result of
>> evaluating *pparr is the int[4] at that address.
> No its the not, it's an object of TYPE int[4]. Evaluating *pparr does not
> yield or access 4 integers, it yields an array-type object which has a
> memory address value.
>
>
>> The result of
>> evaluating **pparr is the int at that address, to get this result
>> there was an implicit array-to-pointer conversion on the array
>> result of *pparr.
> You still do not accept what the result of *pparr is. Evaluating **pparr is
> not the question here, I have told you umpteen times that dereferencing
> twice accesses the array.
I accept that the result of *pparr is an array of 4 int. pparr is a
pointer to an array of 4 int. The result of dereferencing a pointer
to an array of 4 int is an array of 4 int. The output I get for the
prorgram
#include <iostream>
#include <typeinfo>
int main() {
int arr[4], (*pparr)[4]=&arr;
std::cout<<"typeid( pparr).name()="<<typeid( pparr).name()<<std::endl;
std::cout<<"typeid( *pparr).name()="<<typeid(*pparr).name()<<std::endl;
std::cout<<"typeid( arr).name()="<<typeid( arr).name()<<std::endl;
}
is
typeid( pparr).name()=PA4_i
typeid( *pparr).name()=A4_i
typeid( arr).name()=A4_i
The output indicates that pparr is a pointer to an array of 4 int
and both pparr and arr are arrays of 4 int.
>> The bottom line is that the expression **pparr accesses only one
>> stored memory address: the one stored in the object named pparr.
> You cannot access a whole array simultaneously. You can only represent this
> concept with an object type.
>
> But you fail to answer the question which was what is accessed, with *pparr,
> to produce a memory address? You can waffle on all day about what **pparr
> accesses but this does not answer the above.
> As I have said its an array-type object which stores the address of the
> array, you seem to disagree but you are providing no reasonable reasons why.
I have answered the question about what is accessed with *pparr to
produced a memory address. I wrote (copied from above):
Evaluating pparr accesses the value stored in the object allocated
for it (the object named pparr). The value is the memory address
of the array (the value to which pparr was initialized). The result
of evaluating *pparr is the int[4] at that address.
I have not waffled about what **pparr accesses. I unequivocally
wrote (continued from above):
The result of evaluating **pparr is the int at that address, to
get this result there was an implicit array-to-pointer conversion
on the array result of *pparr.
What I have written is consistent with what is in C++ standard about
the dereference operator and array-to-pointer conversion. It is
also consistent with C++ compilers that I have used. With the GNU
C++ compiler, the assembler output for the body of the foo function
in the C++ source
int arr[4] = {1,2,3,4};
int (*pparr)[4] = &arr;
int foo() {
return **pparr;
}
is
LFB2:
pushl %ebp
LCFI0:
movl %esp, %ebp
LCFI1:
movl _pparr, %eax
movl (%eax), %eax
popl %ebp
ret
when compiled for an Intel 686. The instruction
movl _pparr, %eax
loads the value stored in the C++ object named pparr into register
eax. That value is the memory address of the array named arr
because pparr was initialized with &arr. The instruction
movl (%eax), %eax
loads the value stored at that address into register eax. That
value is the value of the first element of the array named arr.
Because the return value of the function is the value in register
eax, the return value of the function is the value of the first
element of the array named arr.
As I wrote: "The bottom line is that the expression **pparr
accesses only one stored memory address: the one stored in the
object named pparr."
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-08 04:05 +0100 |
| Message-ID | <aMnxp.153$Gn4.18@newsfe19.ams2> |
| In reply to | #4793 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message news:slrnisat4r.1649.aggedor@earl-grey.cloud9.net... > [snip] >>> I wrote: "Dereferencing pparr accesses an array in the same sense >>> that using the name arr accesses an array." You replied that it >>> doesn't". Please provide an example that supports your claim that >>> dereferencing pparr doesn't access an array in the same sense that >>> using the name arr accesses an array. Dereferencing pparr twice and >>> arr once does not directly address whether dereferencing pparr (once) >>> and arr (not at all) access an array in the same sense. >> >> pparr needs to be dereferenced twice , and arr only once, to access the >> array. > > That does not show that dereferencing pparr doesn't access an array > in the same sense that using the name arr accesses an array. Yes it does. <snip>
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-05-10 12:31 -0500 |
| Message-ID | <slrnisitjh.13sv.aggedor@earl-grey.cloud9.net> |
| In reply to | #4798 |
On 2011-05-08, Paul <pchristor@yahoo.co.uk> wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrnisat4r.1649.aggedor@earl-grey.cloud9.net...
>> [snip]
>>>> I wrote: "Dereferencing pparr accesses an array in the same sense
>>>> that using the name arr accesses an array." You replied that it
>>>> doesn't". Please provide an example that supports your claim that
>>>> dereferencing pparr doesn't access an array in the same sense that
>>>> using the name arr accesses an array. Dereferencing pparr twice and
>>>> arr once does not directly address whether dereferencing pparr (once)
>>>> and arr (not at all) access an array in the same sense.
>>>
>>> pparr needs to be dereferenced twice , and arr only once, to access the
>>> array.
>>
>> That does not show that dereferencing pparr doesn't access an array
>> in the same sense that using the name arr accesses an array.
>
> Yes it does.
>
><snip>
You snipped what I wrote after that sentence. What I wrote was
That does not show that dereferencing pparr doesn't access an array
in the same sense that using the name arr accesses an array. An
example that shows it would dereference pparr once and arr not at all.
The fact that
*pparr and arr access an array in same sense
implies that
**pparr and *arr access the first element of that array
What *arr accesses is the first element of an array. Because an
array and elements of it have different types, accessing the first
element of an array is not the same as accessing the array.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-10 22:10 +0100 |
| Message-ID | <ZQhyp.1$2E6.0@newsfe18.ams2> |
| In reply to | #4870 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message news:slrnisitjh.13sv.aggedor@earl-grey.cloud9.net... > On 2011-05-08, Paul <pchristor@yahoo.co.uk> wrote: >> >> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message >> news:slrnisat4r.1649.aggedor@earl-grey.cloud9.net... >>> [snip] >>>>> I wrote: "Dereferencing pparr accesses an array in the same sense >>>>> that using the name arr accesses an array." You replied that it >>>>> doesn't". Please provide an example that supports your claim that >>>>> dereferencing pparr doesn't access an array in the same sense that >>>>> using the name arr accesses an array. Dereferencing pparr twice and >>>>> arr once does not directly address whether dereferencing pparr (once) >>>>> and arr (not at all) access an array in the same sense. >>>> >>>> pparr needs to be dereferenced twice , and arr only once, to access the >>>> array. >>> >>> That does not show that dereferencing pparr doesn't access an array >>> in the same sense that using the name arr accesses an array. >> >> Yes it does. >> >><snip> > > You snipped what I wrote after that sentence. What I wrote was > Yes I did because it was complete nonsense. arr accesses the array by dereferencing only once. pparr accesses the array by dereferencing twice. Dereferencing pparr does not access the array in the same way as arr at all, you are speaking complete nonsense. It doesn't matter how much code or nonsense you post, it won't change the fact that both have different levels of indirection.
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-05-12 12:19 -0500 |
| Message-ID | <slrniso5lm.s9.aggedor@earl-grey.cloud9.net> |
| In reply to | #4876 |
On 2011-05-10, Paul <pchristor@yahoo.co.uk> wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrnisitjh.13sv.aggedor@earl-grey.cloud9.net...
>> On 2011-05-08, Paul <pchristor@yahoo.co.uk> wrote:
>>>
>>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>>> news:slrnisat4r.1649.aggedor@earl-grey.cloud9.net...
>>>> [snip]
>>>>>> I wrote: "Dereferencing pparr accesses an array in the same sense
>>>>>> that using the name arr accesses an array." You replied that it
>>>>>> doesn't". Please provide an example that supports your claim that
>>>>>> dereferencing pparr doesn't access an array in the same sense that
>>>>>> using the name arr accesses an array. Dereferencing pparr twice and
>>>>>> arr once does not directly address whether dereferencing pparr (once)
>>>>>> and arr (not at all) access an array in the same sense.
>>>>>
>>>>> pparr needs to be dereferenced twice , and arr only once, to access the
>>>>> array.
>>>>
>>>> That does not show that dereferencing pparr doesn't access an array
>>>> in the same sense that using the name arr accesses an array.
>>>
>>> Yes it does.
>>>
>>><snip>
>>
>> You snipped what I wrote after that sentence. What I wrote was
>>
> Yes I did because it was complete nonsense.
It wasn't nonsense; it was evidence that supported my statement.
By snipping it you gave the misimpression that I made the statement
without giving supporting evidence. Now, you snipped it again.
> arr accesses the array by dereferencing only once. pparr accesses the array
> by dereferencing twice. Dereferencing pparr does not access the array in the
> same way as arr at all, you are speaking complete nonsense.
The fact that dereferencing pparr twice and arr once both result in
the first element of the array is consistent with the fact that
dereferencing pparr (once) accesses an array in the same sense as
using arr (not dereferenced) accesses the array.
The array accessed by dereferencing pparr once and arr not at all
is implicitly converted to a pointer to the first element of the
array. Dereferencing that pointer accesses the first element of
the array.
If having the result of dereferencing a pointer to something be
the thing pointed to is nonsense, then pointers and dereferencing
in C++ are nonsense.
> It doesn't matter how much code or nonsense you post, it won't change the
> fact that both have different levels of indirection.
I never claimed that they (pparr and arr) have the same level of
indirection. What I wrote that you have snipped in multiple followups
was
That does not show that dereferencing pparr doesn't access an array
in the same sense that using the name arr accesses an array. An
example that shows it would dereference pparr once and arr not at all.
The fact that
*pparr and arr access an array in same sense
implies that
**pparr and *arr access the first element of that array
What *arr accesses is the first element of an array. Because an
array and elements of it have different types, accessing the first
element of an array is not the same as accessing the array.
pparr is a level of indirection from arr. Dereferencing pparr
accesses an array in the same sense as using arr accesses an array,
just as given the declaration
int i, *pi = &i;
dereferencing pi accesses an int in the same sense that using i
accesses an int.
[toc] | [prev] | [next] | [standalone]
Page 5 of 21 — ← Prev page 1 … 3 4 [5] 6 7 … 21 Next page →
Back to top | Article view | comp.lang.c++
csiph-web