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 6 of 21 — ← Prev page 1 … 4 5 [6] 7 8 … 21 Next page →
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-13 09:54 +0100 |
| Message-ID | <fl6zp.117$Wy2.90@newsfe23.ams2> |
| In reply to | #4923 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message news:slrniso5lm.s9.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. > What is accessed when you dereference pparr once? Are you incapable of using a compiler to find this out? You speak utter nonsense, and I am considering ignoring further posts from you because of your unreasonableness. >> 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 Its consistent with fuck all you arsehole. THere is fuck all that is consistent about dereferencing pparr twice and arr once, except that it proves they are different levels of indirection. WHich is what I have been telling you all along. Dereferencing pparr once accesses what? You dont seem to know. > > 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. NO ARRAY IS ACCESED WHEN DEREFERENCING PPARR ONCE ! Are you stupid as well as incapable of using a compiler. If you think I am wasting my time arguing with an idiot like you you can go fuck yourself. Accept the facts arsehole, I've had enough of your unreasonable idiocy.
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-05-14 11:20 -0500 |
| Message-ID | <slrnistau0.1od6.aggedor@earl-grey.cloud9.net> |
| In reply to | #4936 |
On 2011-05-13, Paul <pchristor@yahoo.co.uk> wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrniso5lm.s9.aggedor@earl-grey.cloud9.net...
[snip]
> What is accessed when you dereference pparr once?
The array named arr (the value &arr has been assigned to pparr).
> Are you incapable of using a compiler to find this out?
No, I'm capable. Here is an example program.
#include <iostream>
#include <typeinfo>
int main() {
int arr[4], (*pparr)[4]=&arr;
std::cout<<"typeid(arr)"<<
((typeid(arr)==typeid(*pparr))?"==":"!=")<<
"typeid(*pparr)"<<std::endl;
std::cout<<"&arr"<<((&arr==&(*pparr))?"==":"!=")<<
"&(*pparr)"<<std::endl;
}
The output I get is
typeid(arr)==typeid(*pparr)
&arr==&(*pparr)
the results of the expressions arr and *pparr have the same type
and the same address; the results are the same object: the array
named arr.
> You speak utter nonsense, and I am considering ignoring further posts from
> you because of your unreasonableness.
I'm not unreasonable. I have answered your questions, both here and
in other posts. I have also responed to questionable statements that
you have made and have given reasons that support my claims.
[snip]
>> The fact that dereferencing pparr twice and arr once both result in
>> the first element of the array is consistent
> Its consistent with fuck all you arsehole.
> THere is fuck all that is consistent about dereferencing pparr twice and arr
> once, except that it proves they are different levels of indirection. WHich
> is what I have been telling you all along.
I have never claimed that they have the same level of indirection.
Apparently you stopped reading what I wrote at the word "consistent"
and did not read what I actually wrote what dereferencing pparr twice
and arr once both resulting in the first element of the array is
consistent with.
> Dereferencing pparr once accesses what?
The array named arr (the value &arr has been assigned to pparr).
> You dont seem to know.
What I have stated is that dereferencing pparr once accesses the
array named arr in the same sense as using the identifier arr.
>> 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.
>
> NO ARRAY IS ACCESED WHEN DEREFERENCING PPARR ONCE !
Here is what I wrote that you silently snipped.
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.
> Are you stupid as well as incapable of using a compiler.
I am neither. I have supported my claims with quotes from the C++
standard, sample C++ programs, and assembler source generated by
a C++ compiler. What I have not done is call someone stupid or
an arsehole, as you have done.
> If you think I am wasting my time arguing with an idiot like you you can go
> fuck yourself. Accept the facts arsehole, I've had enough of your
> unreasonable idiocy.
I accept facts, such as what is actually in the C++ standard and the
output of C++ programs. I have used those as reasons that support
what I have claimed.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-14 23:59 +0100 |
| Message-ID | <9PDzp.2011$Am5.1296@newsfe05.ams2> |
| In reply to | #4957 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
news:slrnistau0.1od6.aggedor@earl-grey.cloud9.net...
> On 2011-05-13, Paul <pchristor@yahoo.co.uk> wrote:
>>
>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>> news:slrniso5lm.s9.aggedor@earl-grey.cloud9.net...
>
> [snip]
>
>> What is accessed when you dereference pparr once?
>
> The array named arr (the value &arr has been assigned to pparr).
These are two different things.
Dereferencing pparr gives you arr, that is an array-type object , not &arr.
>
>> Are you incapable of using a compiler to find this out?
>
> No, I'm capable. Here is an example program.
>
> #include <iostream>
> #include <typeinfo>
> int main() {
> int arr[4], (*pparr)[4]=&arr;
>
> std::cout<<"typeid(arr)"<<
> ((typeid(arr)==typeid(*pparr))?"==":"!=")<<
> "typeid(*pparr)"<<std::endl;
> std::cout<<"&arr"<<((&arr==&(*pparr))?"==":"!=")<<
> "&(*pparr)"<<std::endl;
> }
>
> The output I get is
>
> typeid(arr)==typeid(*pparr)
> &arr==&(*pparr)
>
> the results of the expressions arr and *pparr have the same type
> and the same address; the results are the same object: the array
> named arr.
Typeid gives a string representation of an object TYPE, not an object.
Its not the array of integer objects, its another object. It's an array-TYPE
object which decays into a pointer.
Dereferencing pparr does not access the array of integer objects, it
accesses another object which decays into a pointer.
The array-type object can only be reperesented in a limited amount of ways :
1) typeinfo represents it as a string in the form of "int[]"
2) sizeof represents this as an integer value.
3) Almost any other operation will cause it to be converted to a pointer,
and its value will be an address.
An array-type object is not a figment of my imagination it exists in C++.
Why do you refuse to accept that there is such an entity as an array-type
object?
>
>> You speak utter nonsense, and I am considering ignoring further posts
>> from
>> you because of your unreasonableness.
>
> I'm not unreasonable. I have answered your questions, both here and
> in other posts. I have also responed to questionable statements that
> you have made and have given reasons that support my claims.
>
You are being unreasonable because you cannot accept that dereferencing
pparr doesn''t actually access the array but it gives access to an
array-type object.
All that code you posted above is uneccessary bullshit to try an show things
how you want them to appear.
simply coding :
std::cout<< *pparr;
is enough to prove that dereferencing pparr doesnt access the array, it
accesses and object which decays into a pointer.
I have stated numerous times that it is an array-TYPE object. So why dont
you understand when you do :
std::cout<< typeid(*pparr).name();
An array-TYPE is displayed. It's a TYPE not an OBJECT that is displayed by
typeid. The object that arr is, is an array-type object, which decays into a
pointer to the actuall array of integer objects.
> [snip]
>
>>> The fact that dereferencing pparr twice and arr once both result in
>>> the first element of the array is consistent
>> Its consistent with fuck all you arsehole.
>> THere is fuck all that is consistent about dereferencing pparr twice and
>> arr
>> once, except that it proves they are different levels of indirection.
>> WHich
>> is what I have been telling you all along.
>
> I have never claimed that they have the same level of indirection.
> Apparently you stopped reading what I wrote at the word "consistent"
> and did not read what I actually wrote what dereferencing pparr twice
> and arr once both resulting in the first element of the array is
> consistent with.
But we are not arguing about what dereferencing ppar twice and arr once is.
We are aguing about the fact that dereferencing pparr ONCE points a
array-type object which stores an address, and it does not access the array
of integer objects.
You claimed that there is no intermediate object and there is only one array
object, but you are incorrect. There is an array-type object and an array of
integer objects which are not stored in the same memory location They are
different entities or objects or whatever you want to call them, they are
different fucking things altogether.
>
>> Dereferencing pparr once accesses what?
>
> The array named arr (the value &arr has been assigned to pparr).
>
Ok so what is this object that 'arr' represents , do you accept that it is
an array-type object( which decays into a pointer) or do you still think
it's the array of integer objects?
>> You dont seem to know.
>
> What I have stated is that dereferencing pparr once accesses the
> array named arr in the same sense as using the identifier arr.
It doesn't access THE array, It is dereferencing a pointer to an array-type
object. It accesses an array-type object which when accessed decays into
another pointer.
Ok with the following code:
int arr[3] = {1,2,3};
int (*pparr)[3] = &arr;
std::cout<<*pparr;
If dereferencing pparr once accessed the array then it would output 1.
It doesn't because it doesn't access the array, it accesses an array-TYPE
object, which decays into another pointer.
>
>>> 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.
>>
>> NO ARRAY IS ACCESED WHEN DEREFERENCING PPARR ONCE !
>
> Here is what I wrote that you silently snipped.
>
It doesn't matter what you wrote if you're disagreeing, with what I wrote in
caps, you are wrong.
> 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.
pi needs to be dereferenced twice to access the array, i needs to be , and
can only be, dereferenced once.
It is completely incorrect to suggest that, when dereferencing, they access
the array in the same way.
>
>> Are you stupid as well as incapable of using a compiler.
>
> I am neither. I have supported my claims with quotes from the C++
> standard, sample C++ programs, and assembler source generated by
> a C++ compiler. What I have not done is call someone stupid or
> an arsehole, as you have done.
>
>> If you think I am wasting my time arguing with an idiot like you you can
>> go
>> fuck yourself. Accept the facts arsehole, I've had enough of your
>> unreasonable idiocy.
>
> I accept facts, such as what is actually in the C++ standard and the
> output of C++ programs. I have used those as reasons that support
> what I have claimed.
You don't accept the facts. You continue to claim that dereferencing pparr
accesses the array of integer objects and refuse to accept that it actually
accesses another object which is an array-type object that decays into a
pointer..
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-05-17 12:59 -0500 |
| Message-ID | <slrnit5drc.1qpu.aggedor@earl-grey.cloud9.net> |
| In reply to | #4963 |
On 2011-05-14, Paul <pchristor@yahoo.co.uk> wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrnistau0.1od6.aggedor@earl-grey.cloud9.net...
>> On 2011-05-13, Paul <pchristor@yahoo.co.uk> wrote:
>>>
>>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>>> news:slrniso5lm.s9.aggedor@earl-grey.cloud9.net...
>>
>> [snip]
>>
>>> What is accessed when you dereference pparr once?
>>
>> The array named arr (the value &arr has been assigned to pparr).
>
> These are two different things.
> Dereferencing pparr gives you arr, that is an array-type object , not &arr.
The result of dereferencing pparr once being arr is what I have
been stating. The result of the expression pparr is &arr (the
value to which pparr has been initialized). The results of
dereferencing pparr is arr.
>>> Are you incapable of using a compiler to find this out?
>>
>> No, I'm capable. Here is an example program.
>>
>> #include <iostream>
>> #include <typeinfo>
>> int main() {
>> int arr[4], (*pparr)[4]=&arr;
>>
>> std::cout<<"typeid(arr)"<<
>> ((typeid(arr)==typeid(*pparr))?"==":"!=")<<
>> "typeid(*pparr)"<<std::endl;
>> std::cout<<"&arr"<<((&arr==&(*pparr))?"==":"!=")<<
>> "&(*pparr)"<<std::endl;
>> }
>>
>> The output I get is
>>
>> typeid(arr)==typeid(*pparr)
>> &arr==&(*pparr)
>>
>> the results of the expressions arr and *pparr have the same type
>> and the same address; the results are the same object: the array
>> named arr.
> Typeid gives a string representation of an object TYPE, not an object.
> Its not the array of integer objects, its another object. It's an array-TYPE
> object which decays into a pointer.
> Dereferencing pparr does not access the array of integer objects, it
> accesses another object which decays into a pointer.
The result of typeid(arr), is a std::type_info object representing
the type of arr. The fact that
typeid(arr)==typeid(*pparr)
indicates that arr and *pparr have the same type.
The return value of the name() member function of class
std::type_info is a C-string whose implementation defined value
represents the name of the type. With the GNU C++ compiler that I
use, the result of both typeid(arr).name() and typeid(*pparr).name()
is "A4_i". That is, both arr and *pparr are an array of 4 int.
In some contexts an array, such as the result of the expression
arr or *pparr, is implicltly converted to a pointer to the first
element of the array. A result that is an array of integers
object "decays into" a pointer to the first integer of the array.
> The array-type object can only be reperesented in a limited amount of ways :
> 1) typeinfo represents it as a string in the form of "int[]"
> 2) sizeof represents this as an integer value.
> 3) Almost any other operation will cause it to be converted to a pointer,
> and its value will be an address.
In this case, the array-type object is the array named arr. As I
wrote just above, the value of typeid(arr).name() with the C++
compiler that I use is "A4_i", which denotes an array of 4 int.
The value of sizeof(arr) is 16, with the C++ compiler that I use
the sizeof(int) is 4, making the size of an array of 4 int 16. In
some contexts array-to-pointer conversion is implicitly applied to
an array and the result of that conversion is a pointer to the
first element of the array.
> An array-type object is not a figment of my imagination it exists in C++.
> Why do you refuse to accept that there is such an entity as an array-type
> object?
I don't accept that there is an array-type object different from the
array because, as far as I can tell, there is nothing the C++
standard about there being such an array-type object different from
the array. If you think there is something in the C++ standard
about it, please cite the specific paragraphs about an "array-type
object" different from an array.
In addition, I have posted the assembler file generated by a C++
compiler for an example program. That assembler file does not
contain an "array-type object" different from the array. That
example program and assembler output are also later in this post.
>>> You speak utter nonsense, and I am considering ignoring further posts
>>> from
>>> you because of your unreasonableness.
>>
>> I'm not unreasonable. I have answered your questions, both here and
>> in other posts. I have also responed to questionable statements that
>> you have made and have given reasons that support my claims.
>>
> You are being unreasonable because you cannot accept that dereferencing
> pparr doesn''t actually access the array but it gives access to an
> array-type object.
I am being reasonable; I have given the reasons why dereferencing
pparr accesses an array in the same sense as using the identifier of
the array. In this case, the array-type object that results from
dereferencing pparr is the array named arr.
> All that code you posted above is uneccessary bullshit to try an show things
> how you want them to appear.
What I have shown is consistent with what is in the C++ standard
and the behavior of C++ compilers that I have used. You are the
one who is trying to show things how you want them to appear, such
as there being an array-type object distinct from the array.
Apparently, you are drawing too close of a parallel between the
expression
**pparr
with the declarations
int arr[4], (*pparr)[4] = &arr;
and the expression
**ppi
with the declarations
int i, *pi = &i, **ppi = π
In the latter case there are three objects: i, pi, and ppi. Between
ppi and i there is an object (named pi) that stores a pointer to int.
In the former case there are two objects: arr and pparr. Between
pparr and the int that is the first element of arr there is no
third object that stores a pointer to an int.
> simply coding :
>
> std::cout<< *pparr;
>
> is enough to prove that dereferencing pparr doesnt access the array, it
> accesses and object which decays into a pointer.
What happens in this case is an implicit array-to-pointer conversion
from the array result of *pparr to a pointer to the first element of
the array. In other words: dereferencing pparr accesses the array
and the array decays into a pointer to the first element of the array.
The result of the array-to-pointer conversion is used as the argument
in a call to the <<(const void*) member function of the ostream named
cout.
> I have stated numerous times that it is an array-TYPE object. So why dont
> you understand when you do :
>
> std::cout<< typeid(*pparr).name();
>
> An array-TYPE is displayed. It's a TYPE not an OBJECT that is displayed by
> typeid. The object that arr is, is an array-type object, which decays into a
> pointer to the actuall array of integer objects.
That's right, typeid(*pparr).name() is a C-string that represents
the name of an array type, "A4_i" with the GNU C++ compiler that I
use. It is the type of the result of the expression *pparr. The
result of the expression *pparr is an array of 4 int. That array is
subject to array-to-pointer conversion, and the result of that
conversion is a pointer to the first element of the array. The
result that conversion is not a pointer to the array.
>> [snip]
>>
>>>> The fact that dereferencing pparr twice and arr once both result in
>>>> the first element of the array is consistent
>>> Its consistent with fuck all you arsehole.
>>> THere is fuck all that is consistent about dereferencing pparr twice and
>>> arr
>>> once, except that it proves they are different levels of indirection.
>>> WHich
>>> is what I have been telling you all along.
>>
>> I have never claimed that they have the same level of indirection.
>> Apparently you stopped reading what I wrote at the word "consistent"
>> and did not read what I actually wrote what dereferencing pparr twice
>> and arr once both resulting in the first element of the array is
>> consistent with.
>
> But we are not arguing about what dereferencing ppar twice and arr once is.
> We are aguing about the fact that dereferencing pparr ONCE points a
> array-type object which stores an address, and it does not access the array
> of integer objects.
Because pparr is a pointer to an array, the result of dereferencing
pparr is an array, just as the result of dereferencing a pointer to
an int is an int. The array that results by dereferencing pparr is
the array named arr, not a different object which stores an address.
An example program I gave in a previous post was
int arr[4] = {1,2,3,4};
int (*pparr)[4] = &arr;
int foo() {
return **pparr;
}
The assembler output for the function named foo using the GNU C++
compiler for an Intel 686 is
LFB2:
pushl %ebp
LCFI0:
movl %esp, %ebp
LCFI1:
movl _pparr, %eax
movl (%eax), %eax
popl %ebp
ret
The instruction
movl _pparr, %eax
copies the value stored in the C++ object named pparr into a register,
and the next instruction
movl (%eax), %eax
copies the value stored at that address into the register that holds
the return value of the function. The expression **pparr accesses
only one C++ object that stores a memory address: the one named pparr.
> You claimed that there is no intermediate object and there is only one array
> object, but you are incorrect. There is an array-type object and an array of
> integer objects which are not stored in the same memory location They are
> different entities or objects or whatever you want to call them, they are
> different fucking things altogether.
You stated that there is an intermediate object. I have been using
the word object with the meaning it has in C++. You are the one who
called it an object, I am simply using what the word object means in
C++.
I supported my claim of there being only one array-type object in this
this case with the above example program and assembler file generated
by the GNU C++ compiler. I did not include the data section of the
assembler file in the previous post. The data section is
.globl _arr
.data
.align 4
_arr:
.long 1
.long 2
.long 3
.long 4
.globl _pparr
.align 4
_pparr:
.long _arr
There are only two objects: one for an array of 4 int named arr in
the C++ program (initialized with the 4 values in C++ program) and
one for pointer to array of 4 int named pparr in the C++ program
(initialized with the address of the C++ object named arr).
There is only one array-type object here, the one named arr in the
C++ program. In addition, there is no array-type object created
by the instructions generated for the expression **pparr (the
generated instructions are in this post about 60 lines ago).
I have provided reasons that support my claim; you claim that
there is an intermediate object without supporting reasons.
>>> Dereferencing pparr once accesses what?
>>
>> The array named arr (the value &arr has been assigned to pparr).
>>
> Ok so what is this object that 'arr' represents , do you accept that it is
> an array-type object( which decays into a pointer) or do you still think
> it's the array of integer objects?
The identifier arr represents an object of type array of 4 int. That
object contains 4 subobjects of type int. As with all objects of
type array, it some contexts array-to-pointer conversion is
implicitly applied to it and the result is a pointer to the first
element of the array.
>>> You dont seem to know.
>>
>> What I have stated is that dereferencing pparr once accesses the
>> array named arr in the same sense as using the identifier arr.
>
> It doesn't access THE array, It is dereferencing a pointer to an array-type
> object. It accesses an array-type object which when accessed decays into
> another pointer.
The result of dereferencing a pointer to an array is an array, just
as the result of dereferencing a pointer to int is an int. In this
case, the object of type array that is the result of dereferencing
pparr is the array named arr; the result is not any other object.
As with all objects of type array, it some contexts array-to-pointer
conversion is implicitly applied to it and the result of the
conversion is a pointer to the first element of the array.
> Ok with the following code:
> int arr[3] = {1,2,3};
> int (*pparr)[3] = &arr;
> std::cout<<*pparr;
>
> If dereferencing pparr once accessed the array then it would output 1.
> It doesn't because it doesn't access the array, it accesses an array-TYPE
> object, which decays into another pointer.
Deferencing pparr once access the array; accessing an array is not
the same as accessing the first element of the array. An array and
its first element have different types. The array result of *pparr
undergoes implicit array-to-pointer conversion and the output is what
the member function <<(const void*) of the ostream named cout outputs.
>>>> 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.
>>>
>>> NO ARRAY IS ACCESED WHEN DEREFERENCING PPARR ONCE !
>>
>> Here is what I wrote that you silently snipped.
>>
> It doesn't matter what you wrote if you're disagreeing, with what I wrote in
> caps, you are wrong.
If it doesn't matter what I wrote if I disagree, I don't understand
why you write so much about what doesn't matter. Because pparr is a
pointer to an array, the result of dereferencing it is an 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.
>
> pi needs to be dereferenced twice to access the array, i needs to be , and
> can only be, dereferenced once.
There is no array involved with the above declaration of pi.
Dereferencing pi twice does not make sense. The result of
dereferencing pi once is an int. Dereferencing an int does not
make sense.
> It is completely incorrect to suggest that, when dereferencing, they access
> the array in the same way.
I have given reasons and examples to support my claim, here all you
do is make a claim without any supporting reasons or examples.
Please give an example where dereferencing pparr does not access the
array named arr in the sense that using the identifier arr does.
>>> Are you stupid as well as incapable of using a compiler.
>>
>> I am neither. I have supported my claims with quotes from the C++
>> standard, sample C++ programs, and assembler source generated by
>> a C++ compiler. What I have not done is call someone stupid or
>> an arsehole, as you have done.
>>
>>> If you think I am wasting my time arguing with an idiot like you you can
>>> go
>>> fuck yourself. Accept the facts arsehole, I've had enough of your
>>> unreasonable idiocy.
>>
>> I accept facts, such as what is actually in the C++ standard and the
>> output of C++ programs. I have used those as reasons that support
>> what I have claimed.
>
> You don't accept the facts. You continue to claim that dereferencing pparr
> accesses the array of integer objects and refuse to accept that it actually
> accesses another object which is an array-type object that decays into a
> pointer..
What I wrote was: "Dereferencing pparr accesses an array in the same
sense that using the name arr accesses an array." I originally wrote
that in a followup to a post by you in which you wrote: "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." See
http://groups.google.com/group/comp.lang.c++/msg/d921556db52ce388?hl=en
The result of dereferencing pparr is the array named arr, not
another object. In some contexts that array result is implicitly
converted to a pointer to the first element of the array.
I have supported my claim with what is in the C++ standard about
the unary * operator and with the code generated by a C++ compiler
for a sample program. You have not similarly supported your claim
that dereferencing pparr accesses an array-type object other than
the array named arr.
I accept facts, such as what is actually in the C++ standard and
the output of a C++ compiler. I accept claims supported with facts.
No one should accept unsupported claims.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-18 19:36 +0100 |
| Message-ID | <llUAp.895$Tw4.494@newsfe26.ams2> |
| In reply to | #5107 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
news:slrnit5drc.1qpu.aggedor@earl-grey.cloud9.net...
> On 2011-05-14, Paul <pchristor@yahoo.co.uk> wrote:
>>>
>>>> What is accessed when you dereference pparr once?
>>>
>>> The array named arr (the value &arr has been assigned to pparr).
>>
>> These are two different things.
>> Dereferencing pparr gives you arr, that is an array-type object , not
>> &arr.
>
> The result of dereferencing pparr once being arr is what I have
> been stating. The result of the expression pparr is &arr (the
> value to which pparr has been initialized). The results of
> dereferencing pparr is arr.
No you are confused. &arr is an operation being carried out on arr. pparr is
a pointer.
Dereferencing pparr gives access to an array-type object(arr).
This object decays into a pointer , in most situations.
>
>>>> Are you incapable of using a compiler to find this out?
>>>
>>> No, I'm capable. Here is an example program.
>>>
>>> #include <iostream>
>>> #include <typeinfo>
>>> int main() {
>>> int arr[4], (*pparr)[4]=&arr;
>>>
>>> std::cout<<"typeid(arr)"<<
>>> ((typeid(arr)==typeid(*pparr))?"==":"!=")<<
>>> "typeid(*pparr)"<<std::endl;
>>> std::cout<<"&arr"<<((&arr==&(*pparr))?"==":"!=")<<
>>> "&(*pparr)"<<std::endl;
>>> }
>>>
>>> The output I get is
>>>
>>> typeid(arr)==typeid(*pparr)
>>> &arr==&(*pparr)
>>>
>>> the results of the expressions arr and *pparr have the same type
>>> and the same address; the results are the same object: the array
>>> named arr.
>> Typeid gives a string representation of an object TYPE, not an object.
>> Its not the array of integer objects, its another object. It's an
>> array-TYPE
>> object which decays into a pointer.
>> Dereferencing pparr does not access the array of integer objects, it
>> accesses another object which decays into a pointer.
>
> The result of typeid(arr), is a std::type_info object representing
> the type of arr. The fact that
>
> typeid(arr)==typeid(*pparr)
>
> indicates that arr and *pparr have the same type.
This is not telling us what pparr points to , it points to an object, not a
type, and that object is not a type_info object.
>
> The return value of the name() member function of class
> std::type_info is a C-string whose implementation defined value
> represents the name of the type. With the GNU C++ compiler that I
> use, the result of both typeid(arr).name() and typeid(*pparr).name()
> is "A4_i". That is, both arr and *pparr are an array of 4 int.
>
> In some contexts an array, such as the result of the expression
> arr or *pparr, is implicltly converted to a pointer to the first
> element of the array. A result that is an array of integers
> object "decays into" a pointer to the first integer of the array.
You are confused what does typeinfo have to do with anything?
>
>> The array-type object can only be reperesented in a limited amount of
>> ways :
>> 1) typeinfo represents it as a string in the form of "int[]"
>> 2) sizeof represents this as an integer value.
>> 3) Almost any other operation will cause it to be converted to a pointer,
>> and its value will be an address.
>
> In this case, the array-type object is the array named arr. As I
> wrote just above, the value of typeid(arr).name() with the C++
> compiler that I use is "A4_i", which denotes an array of 4 int.
> The value of sizeof(arr) is 16, with the C++ compiler that I use
> the sizeof(int) is 4, making the size of an array of 4 int 16. In
> some contexts array-to-pointer conversion is implicitly applied to
> an array and the result of that conversion is a pointer to the
> first element of the array.
>
The value of sizeof(arr) has nothing to do with the values stored in the
array.
>> An array-type object is not a figment of my imagination it exists in C++.
>> Why do you refuse to accept that there is such an entity as an array-type
>> object?
>
> I don't accept that there is an array-type object different from the
> array because, as far as I can tell, there is nothing the C++
> standard about there being such an array-type object different from
> the array. If you think there is something in the C++ standard
> about it, please cite the specific paragraphs about an "array-type
> object" different from an array.
I dont need any standard to confirm what is comon sense. Dereferencing pparr
does not access the array of integer objects, it accesses an array-TYPE
object which is converted to a pointer in most cases.
>
> In addition, I have posted the assembler file generated by a C++
> compiler for an example program. That assembler file does not
> contain an "array-type object" different from the array. That
> example program and assembler output are also later in this post.
>
What does asm have to do with anything?
>>>> You speak utter nonsense, and I am considering ignoring further posts
>>>> from
>>>> you because of your unreasonableness.
>>>
>>> I'm not unreasonable. I have answered your questions, both here and
>>> in other posts. I have also responed to questionable statements that
>>> you have made and have given reasons that support my claims.
>>>
>> You are being unreasonable because you cannot accept that dereferencing
>> pparr doesn''t actually access the array but it gives access to an
>> array-type object.
>
> I am being reasonable; I have given the reasons why dereferencing
> pparr accesses an array in the same sense as using the identifier of
> the array. In this case, the array-type object that results from
> dereferencing pparr is the array named arr.
But it doesn't access the array. You cannot access the array of integer
objects by dereferencing pparr once, you MUST dereference it twice.
>
>> All that code you posted above is uneccessary bullshit to try an show
>> things
>> how you want them to appear.
>
> What I have shown is consistent with what is in the C++ standard
> and the behavior of C++ compilers that I have used. You are the
> one who is trying to show things how you want them to appear, such
> as there being an array-type object distinct from the array.
You have shown nothing but refusal to acknowledge the fact that
dereferencing pparr doesn't access the array.
>
> Apparently, you are drawing too close of a parallel between the
> expression
>
> **pparr
Apparently this has nothing to do with my understanding of the word
"parallel".
Perhaps you have your own meaning for this word.
>
> with the declarations
>
> int arr[4], (*pparr)[4] = &arr;
>
> and the expression
>
> **ppi
>
> with the declarations
>
> int i, *pi = &i, **ppi = π
>
> In the latter case there are three objects: i, pi, and ppi. Between
> ppi and i there is an object (named pi) that stores a pointer to int.
There are no objects here there is just your text and it shows only you
cannot accept that dereferencing pparr does not acces the array.
>
> In the former case there are two objects: arr and pparr. Between
> pparr and the int that is the first element of arr there is no
> third object that stores a pointer to an int.
>
Blah blah, you are incorrect.
>> simply coding :
>>
>> std::cout<< *pparr;
>>
>> is enough to prove that dereferencing pparr doesnt access the array, it
>> accesses and object which decays into a pointer.
>
> What happens in this case is an implicit array-to-pointer conversion
> from the array result of *pparr to a pointer to the first element of
> the array. In other words: dereferencing pparr accesses the array
> and the array decays into a pointer to the first element of the array.
>
> The result of the array-to-pointer conversion is used as the argument
> in a call to the <<(const void*) member function of the ostream named
> cout.
>
blah blah .
>> I have stated numerous times that it is an array-TYPE object. So why dont
>> you understand when you do :
>>
>> std::cout<< typeid(*pparr).name();
>>
>> An array-TYPE is displayed. It's a TYPE not an OBJECT that is displayed
>> by
>> typeid. The object that arr is, is an array-type object, which decays
>> into a
>> pointer to the actuall array of integer objects.
>
> That's right, typeid(*pparr).name() is a C-string that represents
> the name of an array type, "A4_i" with the GNU C++ compiler that I
> use. It is the type of the result of the expression *pparr. The
> result of the expression *pparr is an array of 4 int. That array is
> subject to array-to-pointer conversion, and the result of that
> conversion is a pointer to the first element of the array. The
> result that conversion is not a pointer to the array.
>
All this deduced from a string?
My you are smart, NOT.
>>> [snip]
>>>
>>>>> The fact that dereferencing pparr twice and arr once both result in
>>>>> the first element of the array is consistent
>>>> Its consistent with fuck all you arsehole.
>>>> THere is fuck all that is consistent about dereferencing pparr twice
>>>> and
>>>> arr
>>>> once, except that it proves they are different levels of indirection.
>>>> WHich
>>>> is what I have been telling you all along.
>>>
>>> I have never claimed that they have the same level of indirection.
>>> Apparently you stopped reading what I wrote at the word "consistent"
>>> and did not read what I actually wrote what dereferencing pparr twice
>>> and arr once both resulting in the first element of the array is
>>> consistent with.
>>
>> But we are not arguing about what dereferencing ppar twice and arr once
>> is.
>> We are aguing about the fact that dereferencing pparr ONCE points a
>> array-type object which stores an address, and it does not access the
>> array
>> of integer objects.
>
> Because pparr is a pointer to an array, the result of dereferencing
> pparr is an array, just as the result of dereferencing a pointer to
> an int is an int. The array that results by dereferencing pparr is
> the array named arr, not a different object which stores an address.
>
> An example program I gave in a previous post was
>
> int arr[4] = {1,2,3,4};
> int (*pparr)[4] = &arr;
>
> int foo() {
> return **pparr;
> }
I dont see what you are arguing about , its simple:
I think dereferencing pparr once does not access the array, you think it
does.
Its plain and simple you are incorrect.
<snip>
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-05-19 13:20 -0500 |
| Message-ID | <slrnitans0.14gr.aggedor@earl-grey.cloud9.net> |
| In reply to | #5140 |
On 2011-05-18, Paul <pchristor@yahoo.co.uk> wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrnit5drc.1qpu.aggedor@earl-grey.cloud9.net...
>> On 2011-05-14, Paul <pchristor@yahoo.co.uk> wrote:
>>>>
>>>>> What is accessed when you dereference pparr once?
>>>>
>>>> The array named arr (the value &arr has been assigned to pparr).
>>>
>>> These are two different things.
>>> Dereferencing pparr gives you arr, that is an array-type object , not
>>> &arr.
>>
>> The result of dereferencing pparr once being arr is what I have
>> been stating. The result of the expression pparr is &arr (the
>> value to which pparr has been initialized). The results of
>> dereferencing pparr is arr.
>
> No you are confused. &arr is an operation being carried out on arr. pparr is
> a pointer.
> Dereferencing pparr gives access to an array-type object(arr).
> This object decays into a pointer , in most situations.
I'm not confused. pparr is a pointer to an array; pparr has been
initialized to &arr; the result of dereferencing pparr is arr. This
is just like given the declaration
int i, *pi = &i;
pi is a pointer to an int; pi has been initialized to &i; the result
dereferencing pi is i.
>>>>> Are you incapable of using a compiler to find this out?
>>>>
>>>> No, I'm capable. Here is an example program.
>>>>
>>>> #include <iostream>
>>>> #include <typeinfo>
>>>> int main() {
>>>> int arr[4], (*pparr)[4]=&arr;
>>>>
>>>> std::cout<<"typeid(arr)"<<
>>>> ((typeid(arr)==typeid(*pparr))?"==":"!=")<<
>>>> "typeid(*pparr)"<<std::endl;
>>>> std::cout<<"&arr"<<((&arr==&(*pparr))?"==":"!=")<<
>>>> "&(*pparr)"<<std::endl;
>>>> }
>>>>
>>>> The output I get is
>>>>
>>>> typeid(arr)==typeid(*pparr)
>>>> &arr==&(*pparr)
>>>>
>>>> the results of the expressions arr and *pparr have the same type
>>>> and the same address; the results are the same object: the array
>>>> named arr.
>>> Typeid gives a string representation of an object TYPE, not an object.
>>> Its not the array of integer objects, its another object. It's an
>>> array-TYPE
>>> object which decays into a pointer.
>>> Dereferencing pparr does not access the array of integer objects, it
>>> accesses another object which decays into a pointer.
>>
>> The result of typeid(arr), is a std::type_info object representing
>> the type of arr. The fact that
>>
>> typeid(arr)==typeid(*pparr)
>>
>> indicates that arr and *pparr have the same type.
>
> This is not telling us what pparr points to , it points to an object, not a
> type, and that object is not a type_info object.
According to the C++ standard when typeid is applied to an expression,
the result refers to a type_info object representing the type of the
expression. The output line
typeid(arr)==typeid(*pparr)
of the above program indicates that arr and *pparr have the same type.
The output line
&arr==&(*pparr)
of the above program indicates that pparr points to the object named
arr.
>> The return value of the name() member function of class
>> std::type_info is a C-string whose implementation defined value
>> represents the name of the type. With the GNU C++ compiler that I
>> use, the result of both typeid(arr).name() and typeid(*pparr).name()
>> is "A4_i". That is, both arr and *pparr are an array of 4 int.
>>
>> In some contexts an array, such as the result of the expression
>> arr or *pparr, is implicltly converted to a pointer to the first
>> element of the array. A result that is an array of integers
>> object "decays into" a pointer to the first integer of the array.
>
> You are confused what does typeinfo have to do with anything?
What typeid has to do with it is that I posted the above program that
compares the typeid and address of arr and *pparr because you wrote:
Are you incapable of using a compiler to find this out?
That was in a reply to what I wrote:
The results of dereferencing pparr once being arr is what I have
been stating. The result of the expression pparr is &arr (the
value to which pparr has been initialized). The results of
dereferencing pparr is arr.
I posted a program that showed that arr and *pparr have the same
type and the same address. Because they have the same type and
same address, the result of dereferencing pparr is arr. I posted
the program to support a claim I made that you questioned. You
asked a question, I gave a detailed answer.
>>> The array-type object can only be reperesented in a limited amount of
>>> ways :
>>> 1) typeinfo represents it as a string in the form of "int[]"
>>> 2) sizeof represents this as an integer value.
>>> 3) Almost any other operation will cause it to be converted to a pointer,
>>> and its value will be an address.
>>
>> In this case, the array-type object is the array named arr. As I
>> wrote just above, the value of typeid(arr).name() with the C++
>> compiler that I use is "A4_i", which denotes an array of 4 int.
>> The value of sizeof(arr) is 16, with the C++ compiler that I use
>> the sizeof(int) is 4, making the size of an array of 4 int 16. In
>> some contexts array-to-pointer conversion is implicitly applied to
>> an array and the result of that conversion is a pointer to the
>> first element of the array.
>>
> The value of sizeof(arr) has nothing to do with the values stored in the
> array.
I never claimed it did. The value of sizeof(arr) is the number of
bytes in the object named arr.
>>> An array-type object is not a figment of my imagination it exists in C++.
>>> Why do you refuse to accept that there is such an entity as an array-type
>>> object?
>>
>> I don't accept that there is an array-type object different from the
>> array because, as far as I can tell, there is nothing the C++
>> standard about there being such an array-type object different from
>> the array. If you think there is something in the C++ standard
>> about it, please cite the specific paragraphs about an "array-type
>> object" different from an array.
> I dont need any standard to confirm what is comon sense. Dereferencing pparr
> does not access the array of integer objects, it accesses an array-TYPE
> object which is converted to a pointer in most cases.
Because we are discussing C++, what matters is what is in the C++
standard. The C++ standard specifies requirements for
implementations of the C++ programming language. If what is in
the C++ standard is different than someone's common sense, what
is correct for an implementation of C++ is what is in the standard.
The result of dereferencing a pointer to an array is an array. The
type of that result is an array type. As with all array results, in
some contexts array-to-pointer conversion is applied, and the result
of that conversion is a pointer to the first element of the array.
>> In addition, I have posted the assembler file generated by a C++
>> compiler for an example program. That assembler file does not
>> contain an "array-type object" different from the array. That
>> example program and assembler output are also later in this post.
>>
> What does asm have to do with anything?
To someone who understands it, it shows that the example C++
program does not contain an array-type object different from the
array. I posted the example program to support my claim that
there is not an array-type object different from the array.
>>>>> You speak utter nonsense, and I am considering ignoring further posts
>>>>> from
>>>>> you because of your unreasonableness.
>>>>
>>>> I'm not unreasonable. I have answered your questions, both here and
>>>> in other posts. I have also responed to questionable statements that
>>>> you have made and have given reasons that support my claims.
>>>>
>>> You are being unreasonable because you cannot accept that dereferencing
>>> pparr doesn''t actually access the array but it gives access to an
>>> array-type object.
>>
>> I am being reasonable; I have given the reasons why dereferencing
>> pparr accesses an array in the same sense as using the identifier of
>> the array. In this case, the array-type object that results from
>> dereferencing pparr is the array named arr.
> But it doesn't access the array. You cannot access the array of integer
> objects by dereferencing pparr once, you MUST dereference it twice.
Dereferencing pparr twice accesses the first element of the array.
Accessing an element of an array is not the same as accessing the
array, because an element of an array and the array have different
types.
>>> All that code you posted above is uneccessary bullshit to try an show
>>> things
>>> how you want them to appear.
>>
>> What I have shown is consistent with what is in the C++ standard
>> and the behavior of C++ compilers that I have used. You are the
>> one who is trying to show things how you want them to appear, such
>> as there being an array-type object distinct from the array.
>
> You have shown nothing but refusal to acknowledge the fact that
> dereferencing pparr doesn't access the array.
What I have shown supports my claim: "Dereferencing pparr accesses
an array in the same sense that using the name arr accesses an
array." If you want to claim that they don't both access the
array in the same sense, please support your claim, for example by
citing paragraph(s) in the C++ standard or with a C++ program.
>> Apparently, you are drawing too close of a parallel between the
>> expression
>>
>> **pparr
>
> Apparently this has nothing to do with my understanding of the word
> "parallel".
> Perhaps you have your own meaning for this word.
A standard meaning of the word parallel is: "a person or thing that
is similar or analogous to another" (from
http://oxforddictionaries.com/view/entry/m_en_gb0604160#m_en_gb0604160).
**pparr is similar to **ppi (in the continuation of what I wrote,
below); they both have ** followed by an identifier.
>> with the declarations
>>
>> int arr[4], (*pparr)[4] = &arr;
>>
>> and the expression
>>
>> **ppi
>>
>> with the declarations
>>
>> int i, *pi = &i, **ppi = π
>>
>> In the latter case there are three objects: i, pi, and ppi. Between
>> ppi and i there is an object (named pi) that stores a pointer to int.
> There are no objects here there is just your text and it shows only you
> cannot accept that dereferencing pparr does not acces the array.
According to the C++ standard: an object is created by a definition.
The statement
int i, *pi = &i, **ppi = π
is a definition of three objects, while the statement
int arr[4], (*pparr)[4] = &arr;
is a definition of two objects.
>> In the former case there are two objects: arr and pparr. Between
>> pparr and the int that is the first element of arr there is no
>> third object that stores a pointer to an int.
>>
> Blah blah, you are incorrect.
On my, a claim about me being incorrect without any supporting
reasons. That is a difference between us, I support my claims, such
as with above example of the difference between **pparr and **ppi.
[snip]
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-20 14:29 +0100 |
| Message-ID | <Y0uBp.5039$ue1.2806@newsfe28.ams2> |
| In reply to | #5176 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
news:slrnitans0.14gr.aggedor@earl-grey.cloud9.net...
> On 2011-05-18, Paul <pchristor@yahoo.co.uk> wrote:
>>>>>> What is accessed when you dereference pparr once?
>>>>>
>>>>> The array named arr (the value &arr has been assigned to pparr).
>>>>
>>>> These are two different things.
>>>> Dereferencing pparr gives you arr, that is an array-type object , not
>>>> &arr.
>>>
>>> The result of dereferencing pparr once being arr is what I have
>>> been stating. The result of the expression pparr is &arr (the
>>> value to which pparr has been initialized). The results of
>>> dereferencing pparr is arr.
>>
>> No you are confused. &arr is an operation being carried out on arr. pparr
>> is
>> a pointer.
>> Dereferencing pparr gives access to an array-type object(arr).
>> This object decays into a pointer , in most situations.
>
> I'm not confused. pparr is a pointer to an array; pparr has been
> initialized to &arr; the result of dereferencing pparr is arr. This
> is just like given the declaration
>
> int i, *pi = &i;
>
> pi is a pointer to an int; pi has been initialized to &i; the result
> dereferencing pi is i.
>
Its not the same , a single integer is exactly a single integer. An array of
integers is an array of integers.
An array of integers cannot be addressed simultaneously, the array can only
be represented by a type, that is an array-type object, which is what arr
is.
This array-type object is basically an object that is stored as a pointer on
most, if not all, implementations.
>>>>>> Are you incapable of using a compiler to find this out?
>>>>>
>>>>> No, I'm capable. Here is an example program.
>>>>>
>>>>> #include <iostream>
>>>>> #include <typeinfo>
>>>>> int main() {
>>>>> int arr[4], (*pparr)[4]=&arr;
>>>>>
>>>>> std::cout<<"typeid(arr)"<<
>>>>> ((typeid(arr)==typeid(*pparr))?"==":"!=")<<
>>>>> "typeid(*pparr)"<<std::endl;
>>>>> std::cout<<"&arr"<<((&arr==&(*pparr))?"==":"!=")<<
>>>>> "&(*pparr)"<<std::endl;
>>>>> }
>>>>>
>>>>> The output I get is
>>>>>
>>>>> typeid(arr)==typeid(*pparr)
>>>>> &arr==&(*pparr)
>>>>>
>>>>> the results of the expressions arr and *pparr have the same type
>>>>> and the same address; the results are the same object: the array
>>>>> named arr.
>>>> Typeid gives a string representation of an object TYPE, not an object.
>>>> Its not the array of integer objects, its another object. It's an
>>>> array-TYPE
>>>> object which decays into a pointer.
>>>> Dereferencing pparr does not access the array of integer objects, it
>>>> accesses another object which decays into a pointer.
>>>
>>> The result of typeid(arr), is a std::type_info object representing
>>> the type of arr. The fact that
>>>
>>> typeid(arr)==typeid(*pparr)
>>>
>>> indicates that arr and *pparr have the same type.
>>
>> This is not telling us what pparr points to , it points to an object, not
>> a
>> type, and that object is not a type_info object.
>
> According to the C++ standard when typeid is applied to an expression,
> the result refers to a type_info object representing the type of the
> expression. The output line
>
> typeid(arr)==typeid(*pparr)
>
> of the above program indicates that arr and *pparr have the same type.
> The output line
>
> &arr==&(*pparr)
>
> of the above program indicates that pparr points to the object named
> arr.
I don't need the C++ standard to understand that typeid gives information
about the TYPE, the name is kinda self explanatory.
I have told you it's an array-type object on many occassions.
The object pointed to by pparr is an array-type object, that decays into a
pointer.
>
>>> The return value of the name() member function of class
>>> std::type_info is a C-string whose implementation defined value
>>> represents the name of the type. With the GNU C++ compiler that I
>>> use, the result of both typeid(arr).name() and typeid(*pparr).name()
>>> is "A4_i". That is, both arr and *pparr are an array of 4 int.
>>>
>>> In some contexts an array, such as the result of the expression
>>> arr or *pparr, is implicltly converted to a pointer to the first
>>> element of the array. A result that is an array of integers
>>> object "decays into" a pointer to the first integer of the array.
>>
>> You are confused what does typeinfo have to do with anything?
>
> What typeid has to do with it is that I posted the above program that
> compares the typeid and address of arr and *pparr because you wrote:
>
> Are you incapable of using a compiler to find this out?
>
> That was in a reply to what I wrote:
>
> The results of dereferencing pparr once being arr is what I have
> been stating. The result of the expression pparr is &arr (the
> value to which pparr has been initialized). The results of
> dereferencing pparr is arr.
>
> I posted a program that showed that arr and *pparr have the same
> type and the same address. Because they have the same type and
> same address, the result of dereferencing pparr is arr. I posted
> the program to support a claim I made that you questioned. You
> asked a question, I gave a detailed answer.
>
>>>> The array-type object can only be reperesented in a limited amount of
>>>> ways :
>>>> 1) typeinfo represents it as a string in the form of "int[]"
>>>> 2) sizeof represents this as an integer value.
>>>> 3) Almost any other operation will cause it to be converted to a
>>>> pointer,
>>>> and its value will be an address.
>>>
>>> In this case, the array-type object is the array named arr. As I
>>> wrote just above, the value of typeid(arr).name() with the C++
>>> compiler that I use is "A4_i", which denotes an array of 4 int.
>>> The value of sizeof(arr) is 16, with the C++ compiler that I use
>>> the sizeof(int) is 4, making the size of an array of 4 int 16. In
>>> some contexts array-to-pointer conversion is implicitly applied to
>>> an array and the result of that conversion is a pointer to the
>>> first element of the array.
>>>
>> The value of sizeof(arr) has nothing to do with the values stored in the
>> array.
>
> I never claimed it did. The value of sizeof(arr) is the number of
> bytes in the object named arr.
So why have you meantioned sizeof?
What does that have to do with accessing the array?
You claim that dereferencing pparr once accesses the array but it doesn't,
and you are just now trying to obscure the whole argument by introducing
nonsnese about typeid and sizeof.
>
>>>> An array-type object is not a figment of my imagination it exists in
>>>> C++.
>>>> Why do you refuse to accept that there is such an entity as an
>>>> array-type
>>>> object?
>>>
>>> I don't accept that there is an array-type object different from the
>>> array because, as far as I can tell, there is nothing the C++
>>> standard about there being such an array-type object different from
>>> the array. If you think there is something in the C++ standard
>>> about it, please cite the specific paragraphs about an "array-type
>>> object" different from an array.
>> I dont need any standard to confirm what is comon sense. Dereferencing
>> pparr
>> does not access the array of integer objects, it accesses an array-TYPE
>> object which is converted to a pointer in most cases.
>
> Because we are discussing C++, what matters is what is in the C++
> standard. The C++ standard specifies requirements for
> implementations of the C++ programming language. If what is in
> the C++ standard is different than someone's common sense, what
> is correct for an implementation of C++ is what is in the standard.
>
> The result of dereferencing a pointer to an array is an array. The
> type of that result is an array type. As with all array results, in
> some contexts array-to-pointer conversion is applied, and the result
> of that conversion is a pointer to the first element of the array.
>
You refuse to acknowledge that an array has different levels of indirection.
You seem to think that only one exists.
The term "array" can mean different things:
a) An array of integer type objects.
b) An array type object.
The above have different levels if indirection.
You only see (b) as an acceptable meaning for "array", which is incorrect
and narrow minded.
A pointer to an "array" of integer objects is a pointer of type int*.
A pointer to an "array" of array-type objects is a pointer of type int(*)[]
>>> In addition, I have posted the assembler file generated by a C++
>>> compiler for an example program. That assembler file does not
>>> contain an "array-type object" different from the array. That
>>> example program and assembler output are also later in this post.
>>>
>> What does asm have to do with anything?
>
> To someone who understands it, it shows that the example C++
> program does not contain an array-type object different from the
> array. I posted the example program to support my claim that
> there is not an array-type object different from the array.
>
You don't seem to understand that, in asm, an array is just a pointer.
>>>>>> You speak utter nonsense, and I am considering ignoring further posts
>>>>>> from
>>>>>> you because of your unreasonableness.
>>>>>
>>>>> I'm not unreasonable. I have answered your questions, both here and
>>>>> in other posts. I have also responed to questionable statements that
>>>>> you have made and have given reasons that support my claims.
>>>>>
>>>> You are being unreasonable because you cannot accept that dereferencing
>>>> pparr doesn''t actually access the array but it gives access to an
>>>> array-type object.
>>>
>>> I am being reasonable; I have given the reasons why dereferencing
>>> pparr accesses an array in the same sense as using the identifier of
>>> the array. In this case, the array-type object that results from
>>> dereferencing pparr is the array named arr.
>> But it doesn't access the array. You cannot access the array of integer
>> objects by dereferencing pparr once, you MUST dereference it twice.
>
> Dereferencing pparr twice accesses the first element of the array.
> Accessing an element of an array is not the same as accessing the
> array, because an element of an array and the array have different
> types.
You cannot access a whole array simultaneously.
You can only access a single element.
>
>>>> All that code you posted above is uneccessary bullshit to try an show
>>>> things
>>>> how you want them to appear.
>>>
>>> What I have shown is consistent with what is in the C++ standard
>>> and the behavior of C++ compilers that I have used. You are the
>>> one who is trying to show things how you want them to appear, such
>>> as there being an array-type object distinct from the array.
>>
>> You have shown nothing but refusal to acknowledge the fact that
>> dereferencing pparr doesn't access the array.
>
> What I have shown supports my claim: "Dereferencing pparr accesses
> an array in the same sense that using the name arr accesses an
> array." If you want to claim that they don't both access the
> array in the same sense, please support your claim, for example by
> citing paragraph(s) in the C++ standard or with a C++ program.
>
Dereferencing pparr once does not access the array, dereferencing it twice
does.
Dereferencing arr once does access the array, arr cannot be dereferenced
twice.
>>> Apparently, you are drawing too close of a parallel between the
>>> expression
>>>
>>> **pparr
>>
>> Apparently this has nothing to do with my understanding of the word
>> "parallel".
>> Perhaps you have your own meaning for this word.
>
> A standard meaning of the word parallel is: "a person or thing that
> is similar or analogous to another" (from
> http://oxforddictionaries.com/view/entry/m_en_gb0604160#m_en_gb0604160).
> **pparr is similar to **ppi (in the continuation of what I wrote,
> below); they both have ** followed by an identifier.
>
Sorry but I still don't have a clue what you are talking about.
>>> with the declarations
>>>
>>> int arr[4], (*pparr)[4] = &arr;
>>>
>>> and the expression
>>>
>>> **ppi
>>>
>>> with the declarations
>>>
>>> int i, *pi = &i, **ppi = π
>>>
>>> In the latter case there are three objects: i, pi, and ppi. Between
>>> ppi and i there is an object (named pi) that stores a pointer to int.
>> There are no objects here there is just your text and it shows only you
>> cannot accept that dereferencing pparr does not acces the array.
>
> According to the C++ standard: an object is created by a definition.
> The statement
>
> int i, *pi = &i, **ppi = π
>
> is a definition of three objects, while the statement
>
> int arr[4], (*pparr)[4] = &arr;
>
> is a definition of two objects.
No its 6 objects.
And:
int arr[5]={0};
Is the defintion of one array-type object, and 5 integer objects.
>
>>> In the former case there are two objects: arr and pparr. Between
>>> pparr and the int that is the first element of arr there is no
>>> third object that stores a pointer to an int.
>>>
>> Blah blah, you are incorrect.
>
> On my, a claim about me being incorrect without any supporting
> reasons. That is a difference between us, I support my claims, such
> as with above example of the difference between **pparr and **ppi.
>
> [snip]
On my, its not a claim its a fact.
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-05-23 13:53 -0500 |
| Message-ID | <slrnitlb8j.1ruu.aggedor@earl-grey.cloud9.net> |
| In reply to | #5208 |
On 2011-05-20, Paul <pchristor@yahoo.co.uk> wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrnitans0.14gr.aggedor@earl-grey.cloud9.net...
>> On 2011-05-18, Paul <pchristor@yahoo.co.uk> wrote:
[snip]
>> I'm not confused. pparr is a pointer to an array; pparr has been
>> initialized to &arr; the result of dereferencing pparr is arr. This
>> is just like given the declaration
>>
>> int i, *pi = &i;
>>
>> pi is a pointer to an int; pi has been initialized to &i; the result
>> dereferencing pi is i.
>>
> Its not the same , a single integer is exactly a single integer. An array of
> integers is an array of integers.
> An array of integers cannot be addressed simultaneously, the array can only
> be represented by a type, that is an array-type object, which is what arr
> is.
> This array-type object is basically an object that is stored as a pointer on
> most, if not all, implementations.
That's right, an integer is an integer, and the result of
dereferencing a pointer to an integer is an integer. Similarly, an
array of integers is an array of integers, and the result of
dereferencing a pointer to an array of integers is an array of
integers. I don't know of anything in the C++ standard that
states otherwise.
Given the declaration
int arr[4];
a C++ implementaion creates an array object to represent the array,
but it does not also create an object that stores a pointer to the
array object, unless one is explicitly present, say due to the
declaration
int (*pparr)[4] = &arr;
Due to that statement a C++ implementation creates a pointer to
array object that is initialized to point to the array. The
pointer points directly to the array object.
A few followups ago I posted the code generated by a GNU C++ compiler
to show how an array object and a pointer to an array object were
implemented. I don't know of any compiler that adds an object that
stores a pointer to the array for each array. I don't know of
anything in the C++ standard that requires an object that stores
a pointer to an array for each array. If you do, please provide
details.
>>>>>>> Are you incapable of using a compiler to find this out?
>>>>>>
>>>>>> No, I'm capable. Here is an example program.
>>>>>>
>>>>>> #include <iostream>
>>>>>> #include <typeinfo>
>>>>>> int main() {
>>>>>> int arr[4], (*pparr)[4]=&arr;
>>>>>>
>>>>>> std::cout<<"typeid(arr)"<<
>>>>>> ((typeid(arr)==typeid(*pparr))?"==":"!=")<<
>>>>>> "typeid(*pparr)"<<std::endl;
>>>>>> std::cout<<"&arr"<<((&arr==&(*pparr))?"==":"!=")<<
>>>>>> "&(*pparr)"<<std::endl;
>>>>>> }
>>>>>>
>>>>>> The output I get is
>>>>>>
>>>>>> typeid(arr)==typeid(*pparr)
>>>>>> &arr==&(*pparr)
>>>>>>
>>>>>> the results of the expressions arr and *pparr have the same type
>>>>>> and the same address; the results are the same object: the array
>>>>>> named arr.
>>>>> Typeid gives a string representation of an object TYPE, not an object.
>>>>> Its not the array of integer objects, its another object. It's an
>>>>> array-TYPE
>>>>> object which decays into a pointer.
>>>>> Dereferencing pparr does not access the array of integer objects, it
>>>>> accesses another object which decays into a pointer.
>>>>
>>>> The result of typeid(arr), is a std::type_info object representing
>>>> the type of arr. The fact that
>>>>
>>>> typeid(arr)==typeid(*pparr)
>>>>
>>>> indicates that arr and *pparr have the same type.
>>>
>>> This is not telling us what pparr points to , it points to an object, not
>>> a
>>> type, and that object is not a type_info object.
>>
>> According to the C++ standard when typeid is applied to an expression,
>> the result refers to a type_info object representing the type of the
>> expression. The output line
>>
>> typeid(arr)==typeid(*pparr)
>>
>> of the above program indicates that arr and *pparr have the same type.
>> The output line
>>
>> &arr==&(*pparr)
>>
>> of the above program indicates that pparr points to the object named
>> arr.
> I don't need the C++ standard to understand that typeid gives information
> about the TYPE, the name is kinda self explanatory.
> I have told you it's an array-type object on many occassions.
>
> The object pointed to by pparr is an array-type object, that decays into a
> pointer.
Avoiding the term "array-type" that you use but the C++ standard
doesn't: the object pointed to by pparr is an array. The type of
the object pointed to is an array of int. As with all arrays in C++,
in some contexts, array-to-pointer conversion is implicitly applied
and the result of the conversion is a pointer to the first element of
the array.
[snip]
>>>>> The array-type object can only be reperesented in a limited amount of
>>>>> ways :
>>>>> 1) typeinfo represents it as a string in the form of "int[]"
>>>>> 2) sizeof represents this as an integer value.
>>>>> 3) Almost any other operation will cause it to be converted to a
>>>>> pointer,
>>>>> and its value will be an address.
>>>>
>>>> In this case, the array-type object is the array named arr. As I
>>>> wrote just above, the value of typeid(arr).name() with the C++
>>>> compiler that I use is "A4_i", which denotes an array of 4 int.
>>>> The value of sizeof(arr) is 16, with the C++ compiler that I use
>>>> the sizeof(int) is 4, making the size of an array of 4 int 16. In
>>>> some contexts array-to-pointer conversion is implicitly applied to
>>>> an array and the result of that conversion is a pointer to the
>>>> first element of the array.
>>>>
>>> The value of sizeof(arr) has nothing to do with the values stored in the
>>> array.
>>
>> I never claimed it did. The value of sizeof(arr) is the number of
>> bytes in the object named arr.
>
> So why have you meantioned sizeof?
> What does that have to do with accessing the array?
I mentioned sizeof because you did in the post I was responding to.
In that posted you wrote (see above):
2) sizeof represents this as an integer value.
> You claim that dereferencing pparr once accesses the array but it doesn't,
> and you are just now trying to obscure the whole argument by introducing
> nonsnese about typeid and sizeof.
As for sizeof, you introduced it (see above). As for typeid, you
asked
What is accessed when you dereference pparr once?
Are you incapable of using a compiler to find this out?
I replied with a program that used typeid to show that
dereferencing a pointer to an array had the same type as using the
identifier of the array pointed to. The program also showed that the
address of the result of dereferencing the pointer was the same as
the address of the array.
When the results of two expressions are the same type and are at the
same address, the two expressions access the object in the same
sense. If the object is an array, they both access the array in the
same sense.
You asked a question, I answered it. Now, I'll ask a question: if
dereferencing pparr and using the identifier do not access an array
in the same sense, what is an expression where using one instead of
the other does not access the array in the same sense?
>>>>> An array-type object is not a figment of my imagination it exists in
>>>>> C++.
>>>>> Why do you refuse to accept that there is such an entity as an
>>>>> array-type
>>>>> object?
>>>>
>>>> I don't accept that there is an array-type object different from the
>>>> array because, as far as I can tell, there is nothing the C++
>>>> standard about there being such an array-type object different from
>>>> the array. If you think there is something in the C++ standard
>>>> about it, please cite the specific paragraphs about an "array-type
>>>> object" different from an array.
>>> I dont need any standard to confirm what is comon sense. Dereferencing
>>> pparr
>>> does not access the array of integer objects, it accesses an array-TYPE
>>> object which is converted to a pointer in most cases.
>>
>> Because we are discussing C++, what matters is what is in the C++
>> standard. The C++ standard specifies requirements for
>> implementations of the C++ programming language. If what is in
>> the C++ standard is different than someone's common sense, what
>> is correct for an implementation of C++ is what is in the standard.
>>
>> The result of dereferencing a pointer to an array is an array. The
>> type of that result is an array type. As with all array results, in
>> some contexts array-to-pointer conversion is applied, and the result
>> of that conversion is a pointer to the first element of the array.
>>
> You refuse to acknowledge that an array has different levels of indirection.
> You seem to think that only one exists.
> The term "array" can mean different things:
> a) An array of integer type objects.
> b) An array type object.
What I think is that in the example code used in these posts:
int arr[4];
arr is an array of integers. A C++ implementation creates an array
object to represent that array. The type of that object is array of
int. "An array of integers type objects" is "An array type object".
> The above have different levels if indirection.
> You only see (b) as an acceptable meaning for "array", which is incorrect
> and narrow minded.
That are no levels of indirection between "An array of integer type
objects" and "An array type object". "An array of integers type
objects" is "An array type object". Given the declaration
int (*pparr)[4] = &arr;
pparr is a level of indirection from arr. The identifier arr is not
a level of indirection from the array.
> A pointer to an "array" of integer objects is a pointer of type int*.
> A pointer to an "array" of array-type objects is a pointer of type int(*)[]
A type int* points to an int, not to an array. The int that is
pointed to may be, but is not necessarily, an element of an array of
int. For example, given
int i; *pi = &i;
pi is of type int* but it does not point to an element of an array of
int.
A type int(*)[] points to an array of int. For example, given
int arr[4]; (*pparr)[] = &arr;
pparr is of type int(*)[]; it points to an array of int.
>>>> In addition, I have posted the assembler file generated by a C++
>>>> compiler for an example program. That assembler file does not
>>>> contain an "array-type object" different from the array. That
>>>> example program and assembler output are also later in this post.
>>>>
>>> What does asm have to do with anything?
>>
>> To someone who understands it, it shows that the example C++
>> program does not contain an array-type object different from the
>> array. I posted the example program to support my claim that
>> there is not an array-type object different from the array.
>>
> You don't seem to understand that, in asm, an array is just a pointer.
In asm, a C++ array is a sequence of the elements of the array. In
the example that I previously gave, for the C++ declaration
int arr[4] = {1,2,3,4};
the assembler output of the compiler contained
.globl _arr
.data
.align 4
_arr:
.long 1
.long 2
.long 3
.long 4
There is no implementation of a pointer object here. There is a
global relocatable symbol named _arr used by the linker.
>>>>>>> You speak utter nonsense, and I am considering ignoring further posts
>>>>>>> from
>>>>>>> you because of your unreasonableness.
>>>>>>
>>>>>> I'm not unreasonable. I have answered your questions, both here and
>>>>>> in other posts. I have also responed to questionable statements that
>>>>>> you have made and have given reasons that support my claims.
>>>>>>
>>>>> You are being unreasonable because you cannot accept that dereferencing
>>>>> pparr doesn''t actually access the array but it gives access to an
>>>>> array-type object.
>>>>
>>>> I am being reasonable; I have given the reasons why dereferencing
>>>> pparr accesses an array in the same sense as using the identifier of
>>>> the array. In this case, the array-type object that results from
>>>> dereferencing pparr is the array named arr.
>>> But it doesn't access the array. You cannot access the array of integer
>>> objects by dereferencing pparr once, you MUST dereference it twice.
>>
>> Dereferencing pparr twice accesses the first element of the array.
>> Accessing an element of an array is not the same as accessing the
>> array, because an element of an array and the array have different
>> types.
> You cannot access a whole array simultaneously.
> You can only access a single element.
The result of dereferencing a pointer to an array is an array. You
can do any operation on that result that C++ allows to be done on an
array.
>>>>> All that code you posted above is uneccessary bullshit to try an show
>>>>> things
>>>>> how you want them to appear.
>>>>
>>>> What I have shown is consistent with what is in the C++ standard
>>>> and the behavior of C++ compilers that I have used. You are the
>>>> one who is trying to show things how you want them to appear, such
>>>> as there being an array-type object distinct from the array.
>>>
>>> You have shown nothing but refusal to acknowledge the fact that
>>> dereferencing pparr doesn't access the array.
>>
>> What I have shown supports my claim: "Dereferencing pparr accesses
>> an array in the same sense that using the name arr accesses an
>> array." If you want to claim that they don't both access the
>> array in the same sense, please support your claim, for example by
>> citing paragraph(s) in the C++ standard or with a C++ program.
>>
> Dereferencing pparr once does not access the array, dereferencing it twice
> does.
> Dereferencing arr once does access the array, arr cannot be dereferenced
> twice.
Dereferencing pparr and using the identifier arr access the array
named arr in the same sense. Dereferencing each, that is
dereferencing pparr twice and arr once, actually dereferences the
result of an implicit array-to-pointer conversion on the accessed
array. Because the result of that implicit conversion is a pointer
to the first element of the array, the result of deferencing pparr
twice and arr once is the first element of the array.
>>>> Apparently, you are drawing too close of a parallel between the
>>>> expression
>>>>
>>>> **pparr
>>>
>>> Apparently this has nothing to do with my understanding of the word
>>> "parallel".
>>> Perhaps you have your own meaning for this word.
>>
>> A standard meaning of the word parallel is: "a person or thing that
>> is similar or analogous to another" (from
>> http://oxforddictionaries.com/view/entry/m_en_gb0604160#m_en_gb0604160).
>> **pparr is similar to **ppi (in the continuation of what I wrote,
>> below); they both have ** followed by an identifier.
>>
> Sorry but I still don't have a clue what you are talking about.
You wrote: 'Apparently this has nothing to do with my understanding
of the word "parallel".' I responded with a definition of that word
from the Oxford English Dictionary and explained how that definition
applied to what I wrote. I'll pass on the opportunity to comment
about you not having a clue.
>>>> with the declarations
>>>>
>>>> int arr[4], (*pparr)[4] = &arr;
>>>>
>>>> and the expression
>>>>
>>>> **ppi
>>>>
>>>> with the declarations
>>>>
>>>> int i, *pi = &i, **ppi = π
>>>>
>>>> In the latter case there are three objects: i, pi, and ppi. Between
>>>> ppi and i there is an object (named pi) that stores a pointer to int.
>>> There are no objects here there is just your text and it shows only you
>>> cannot accept that dereferencing pparr does not acces the array.
>>
>> According to the C++ standard: an object is created by a definition.
>> The statement
>>
>> int i, *pi = &i, **ppi = π
>>
>> is a definition of three objects, while the statement
>>
>> int arr[4], (*pparr)[4] = &arr;
>>
>> is a definition of two objects.
>
> No its 6 objects.
It is 2 objects with one of them being an array of 4 subobjects. The
point is that there is not another "array-type" object that stores a
pointer to the array.
> And:
> int arr[5]={0};
>
> Is the defintion of one array-type object, and 5 integer objects.
It is a definition of one array object that contains 5 int subojects,
not 5 integers objects that are independent of the array.
>>>> In the former case there are two objects: arr and pparr. Between
>>>> pparr and the int that is the first element of arr there is no
>>>> third object that stores a pointer to an int.
>>>>
>>> Blah blah, you are incorrect.
>>
>> On my, a claim about me being incorrect without any supporting
>> reasons. That is a difference between us, I support my claims, such
>> as with above example of the difference between **pparr and **ppi.
>>
>> [snip]
>
> On my, its not a claim its a fact.
Someone being incorrect is not a fact unless the claim is supported
with evidence. What is the evidence that between pparr and the int
that is the first element of arr there is a third object that stores
a pointer to an int?
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-23 22:53 +0100 |
| Message-ID | <bHACp.25543$IL2.14423@newsfe04.ams2> |
| In reply to | #5367 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
news:slrnitlb8j.1ruu.aggedor@earl-grey.cloud9.net...
> On 2011-05-20, Paul <pchristor@yahoo.co.uk> wrote:
>>
>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>> news:slrnitans0.14gr.aggedor@earl-grey.cloud9.net...
>>> On 2011-05-18, Paul <pchristor@yahoo.co.uk> wrote:
>
> [snip]
>
>>> I'm not confused. pparr is a pointer to an array; pparr has been
>>> initialized to &arr; the result of dereferencing pparr is arr. This
>>> is just like given the declaration
>>>
>>> int i, *pi = &i;
>>>
>>> pi is a pointer to an int; pi has been initialized to &i; the result
>>> dereferencing pi is i.
>>>
>> Its not the same , a single integer is exactly a single integer. An array
>> of
>> integers is an array of integers.
>> An array of integers cannot be addressed simultaneously, the array can
>> only
>> be represented by a type, that is an array-type object, which is what arr
>> is.
>> This array-type object is basically an object that is stored as a pointer
>> on
>> most, if not all, implementations.
>
> That's right, an integer is an integer, and the result of
> dereferencing a pointer to an integer is an integer. Similarly, an
> array of integers is an array of integers, and the result of
> dereferencing a pointer to an array of integers is an array of
> integers. I don't know of anything in the C++ standard that
> states otherwise.
When you dereference a pointer to int you access the pointed to integer
object like so :
int x=5;
int* px = &x;
std::cout<< *px;
//this will output 5 because dereferencing px accesses the object it points
to.
With an array the situation is not the same becasue an array cannot be
accessed, as a whole. The only way we can point to an array is to point to
one of its elements.
int arr[3] = {1,2,3};
int* parr = arr;
int (*pparr)[3] = &arr;
std::cout<< *parr;
//outputs 1 because it points to the first element of the array.
std::cout<<*pparr;
//outputs a memory address because it points to an array-type object.
An array identifier such as 'arr' is an array-type object. A pointer to this
object points to a single object, not to an array of thi sobject type.
>
> Given the declaration
>
> int arr[4];
>
> a C++ implementaion creates an array object to represent the array,
> but it does not also create an object that stores a pointer to the
> array object, unless one is explicitly present, say due to the
> declaration
>
> int (*pparr)[4] = &arr;
>
> Due to that statement a C++ implementation creates a pointer to
> array object that is initialized to point to the array. The
> pointer points directly to the array object.
The pointer pparr above points to a single object not an array of objects.
Consider this:
int (*p)[3]=0;
std::cout<<*p<<std::endl;
std::cout<< typeid(*p).name()<<std::endl;
std::cout<< sizeof(*p);
Does the above pointer point to a valid object?
Or is it completely UB because its dereferencing a null pointer?
>
> A few followups ago I posted the code generated by a GNU C++ compiler
> to show how an array object and a pointer to an array object were
> implemented. I don't know of any compiler that adds an object that
> stores a pointer to the array for each array. I don't know of
> anything in the C++ standard that requires an object that stores
> a pointer to an array for each array. If you do, please provide
> details.
An array object must store a pointer otherwise how does it know, where in
memory, the array is?
>
>>>>>>>> Are you incapable of using a compiler to find this out?
>>>>>>>
>>>>>>> No, I'm capable. Here is an example program.
>>>>>>>
>>>>>>> #include <iostream>
>>>>>>> #include <typeinfo>
>>>>>>> int main() {
>>>>>>> int arr[4], (*pparr)[4]=&arr;
>>>>>>>
>>>>>>> std::cout<<"typeid(arr)"<<
>>>>>>> ((typeid(arr)==typeid(*pparr))?"==":"!=")<<
>>>>>>> "typeid(*pparr)"<<std::endl;
>>>>>>> std::cout<<"&arr"<<((&arr==&(*pparr))?"==":"!=")<<
>>>>>>> "&(*pparr)"<<std::endl;
>>>>>>> }
>>>>>>>
>>>>>>> The output I get is
>>>>>>>
>>>>>>> typeid(arr)==typeid(*pparr)
>>>>>>> &arr==&(*pparr)
>>>>>>>
>>>>>>> the results of the expressions arr and *pparr have the same type
>>>>>>> and the same address; the results are the same object: the array
>>>>>>> named arr.
>>>>>> Typeid gives a string representation of an object TYPE, not an
>>>>>> object.
>>>>>> Its not the array of integer objects, its another object. It's an
>>>>>> array-TYPE
>>>>>> object which decays into a pointer.
>>>>>> Dereferencing pparr does not access the array of integer objects, it
>>>>>> accesses another object which decays into a pointer.
>>>>>
>>>>> The result of typeid(arr), is a std::type_info object representing
>>>>> the type of arr. The fact that
>>>>>
>>>>> typeid(arr)==typeid(*pparr)
>>>>>
>>>>> indicates that arr and *pparr have the same type.
>>>>
>>>> This is not telling us what pparr points to , it points to an object,
>>>> not
>>>> a
>>>> type, and that object is not a type_info object.
>>>
>>> According to the C++ standard when typeid is applied to an expression,
>>> the result refers to a type_info object representing the type of the
>>> expression. The output line
>>>
>>> typeid(arr)==typeid(*pparr)
>>>
>>> of the above program indicates that arr and *pparr have the same type.
>>> The output line
>>>
>>> &arr==&(*pparr)
>>>
>>> of the above program indicates that pparr points to the object named
>>> arr.
>> I don't need the C++ standard to understand that typeid gives information
>> about the TYPE, the name is kinda self explanatory.
>> I have told you it's an array-type object on many occassions.
>>
>> The object pointed to by pparr is an array-type object, that decays into
>> a
>> pointer.
>
> Avoiding the term "array-type" that you use but the C++ standard
> doesn't: the object pointed to by pparr is an array. The type of
> the object pointed to is an array of int. As with all arrays in C++,
> in some contexts, array-to-pointer conversion is implicitly applied
> and the result of the conversion is a pointer to the first element of
> the array.
>
No the C++ standard states its an array type object.
The object pointed to is an array TYPE.
> [snip]
>
<snip>
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-23 23:04 +0100 |
| Message-ID | <crednTTKded2REfQnZ2dnUVZ7oWdnZ2d@giganews.com> |
| In reply to | #5372 |
On 23/05/2011 22:53, Paul wrote: > An array object must store a pointer otherwise how does it know, where > in memory, the array is? Wrong. An array object does not store a pointer to itself just like an "int" object does not store a pointer to itself. Get a clue. It does not need to store a pointer to itself to "know" where in memory it (or its elements) preside; for example the compiler knows where an array object (or its elements) are on the stack relative to the stack frame pointer; this information is determined at compile time not runtime. If you want a pointer to an array then use a .. wait for it .. pointer to an array: int array[42]; int (*pointer_to_an_array)[42] = &array; /Leigh
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-23 23:19 +0100 |
| Message-ID | <LKqdnXnsMLkfQEfQnZ2dnUVZ8nWdnZ2d@giganews.com> |
| In reply to | #5374 |
On 23/05/2011 23:04, Leigh Johnston wrote: > On 23/05/2011 22:53, Paul wrote: >> An array object must store a pointer otherwise how does it know, where >> in memory, the array is? > > Wrong. An array object does not store a pointer to itself just like an > "int" object does not store a pointer to itself. Get a clue. It does not > need to store a pointer to itself to "know" where in memory it (or its > elements) preside; for example the compiler knows where an array object > (or its elements) are on the stack relative to the stack frame pointer; > this information is determined at compile time not runtime. > > If you want a pointer to an array then use a .. wait for it .. pointer > to an array: > > int array[42]; > int (*pointer_to_an_array)[42] = &array; > > /Leigh N00bish spelling mistake on my part: that should have been "reside" not "preside". HTH. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-24 02:26 +0100 |
| Message-ID | <CPDCp.13754$h35.1219@newsfe19.ams2> |
| In reply to | #5374 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:crednTTKded2REfQnZ2dnUVZ7oWdnZ2d@giganews.com... > On 23/05/2011 22:53, Paul wrote: >> An array object must store a pointer otherwise how does it know, where >> in memory, the array is? Actually I should've said array *type* object. That is the object that stores the address when we do this: int arr[43]; int* pntrto_array_of_intgr_objs = arr; The object 'arr' must store the address of the array someplace. > > Wrong. An array object does not store a pointer to itself just like an > "int" object does not store a pointer to itself. Get a clue. It does not > need to store a pointer to itself to "know" where in memory it (or its > elements) preside; for example the compiler knows where an array object > (or its elements) are on the stack relative to the stack frame pointer; > this information is determined at compile time not runtime. > > If you want a pointer to an array then use a .. wait for it .. pointer to > an array: > > int array[42]; > int (*pointer_to_an_array)[42] = &array; You naming is inaccurate what it should be is pointerto_one_single_arrayobj.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-24 13:16 +0100 |
| Message-ID | <846dndOds94DPEbQnZ2dnUVZ8ridnZ2d@giganews.com> |
| In reply to | #5383 |
On 24/05/2011 02:26, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:crednTTKded2REfQnZ2dnUVZ7oWdnZ2d@giganews.com... >> On 23/05/2011 22:53, Paul wrote: >>> An array object must store a pointer otherwise how does it know, where >>> in memory, the array is? > Actually I should've said array *type* object. > > That is the object that stores the address when we do this: > int arr[43]; > int* pntrto_array_of_intgr_objs = arr; > > The object 'arr' must store the address of the array someplace. No it mustn't. Read my initial reply again: >> >> Wrong. An array object does not store a pointer to itself just like an >> "int" object does not store a pointer to itself. Get a clue. It does >> not need to store a pointer to itself to "know" where in memory it (or >> its elements) preside; for example the compiler knows where an array >> object (or its elements) are on the stack relative to the stack frame >> pointer; this information is determined at compile time not runtime. >> >> If you want a pointer to an array then use a .. wait for it .. pointer >> to an array: >> >> int array[42]; >> int (*pointer_to_an_array)[42] = &array; > > You naming is inaccurate what it should be is > pointerto_one_single_arrayobj. > My naming is quite accurate. HTH. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-24 14:58 +0100 |
| Message-ID | <AQOCp.13100$Ky.1561@newsfe24.ams2> |
| In reply to | #5409 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:846dndOds94DPEbQnZ2dnUVZ8ridnZ2d@giganews.com... > On 24/05/2011 02:26, Paul wrote: >> >> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >> news:crednTTKded2REfQnZ2dnUVZ7oWdnZ2d@giganews.com... >>> On 23/05/2011 22:53, Paul wrote: >>>> An array object must store a pointer otherwise how does it know, where >>>> in memory, the array is? >> Actually I should've said array *type* object. >> >> That is the object that stores the address when we do this: >> int arr[43]; >> int* pntrto_array_of_intgr_objs = arr; >> >> The object 'arr' must store the address of the array someplace. > > No it mustn't. Read my initial reply again: > Yes it must how can we do this : int arr[6]; int* p = arr; arr must hold the address of the array or how can it be convered to a pointer? Do you think this value is plucked out of thin air? <snip>
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-24 15:05 +0100 |
| Message-ID | <qZGdnbsWxKGzJkbQnZ2dnUVZ8h-dnZ2d@giganews.com> |
| In reply to | #5420 |
On 24/05/2011 14:58, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:846dndOds94DPEbQnZ2dnUVZ8ridnZ2d@giganews.com... >> On 24/05/2011 02:26, Paul wrote: >>> >>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>> news:crednTTKded2REfQnZ2dnUVZ7oWdnZ2d@giganews.com... >>>> On 23/05/2011 22:53, Paul wrote: >>>>> An array object must store a pointer otherwise how does it know, where >>>>> in memory, the array is? >>> Actually I should've said array *type* object. >>> >>> That is the object that stores the address when we do this: >>> int arr[43]; >>> int* pntrto_array_of_intgr_objs = arr; >>> >>> The object 'arr' must store the address of the array someplace. >> >> No it mustn't. Read my initial reply again: >> > Yes it must how can we do this : > int arr[6]; > int* p = arr; > > arr must hold the address of the array or how can it be convered to a > pointer? Wrong; arr does not hold the address of the array; arr *is* the array. > Do you think this value is plucked out of thin air? The compiler knows the address of the array relative to something else (such as a stack frame pointer or a 'this' pointer). Again if you want something that holds the address of the array then you want a pointer to an array (as I said above). You need to learn the fundamentals of arrays and assembly if you want to know how things work under the hood. HTH. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-24 17:39 +0100 |
| Message-ID | <ZaRCp.9445$2E6.1297@newsfe18.ams2> |
| In reply to | #5421 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:qZGdnbsWxKGzJkbQnZ2dnUVZ8h-dnZ2d@giganews.com... > On 24/05/2011 14:58, Paul wrote: >>>>>> An array object must store a pointer otherwise how does it know, >>>>>> where >>>>>> in memory, the array is? >>>> Actually I should've said array *type* object. >>>> >>>> That is the object that stores the address when we do this: >>>> int arr[43]; >>>> int* pntrto_array_of_intgr_objs = arr; >>>> >>>> The object 'arr' must store the address of the array someplace. >>> >>> No it mustn't. Read my initial reply again: >>> >> Yes it must how can we do this : >> int arr[6]; >> int* p = arr; >> >> arr must hold the address of the array or how can it be convered to a >> pointer? > > Wrong; arr does not hold the address of the array; arr *is* the array. > >> Do you think this value is plucked out of thin air? > > The compiler knows the address of the array relative to something else > (such as a stack frame pointer or a 'this' pointer). Again if you want > something that holds the address of the array then you want a pointer to > an array (as I said above). What you say doesn't make sense. You say the compiler KNOWS the address of the array(whether it be a relative address or otherwise is irrelevant). How does it KNOW this address? It cannot KNOW this address unless it stores it someplace. So where is this address stored and how does the compiler know where to find this stored address, if arr does not store it? <snip>
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-24 17:58 +0100 |
| Message-ID | <hKidnekJ2PNbfkbQnZ2dnUVZ8sSdnZ2d@giganews.com> |
| In reply to | #5433 |
On 24/05/2011 17:39, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:qZGdnbsWxKGzJkbQnZ2dnUVZ8h-dnZ2d@giganews.com... >> On 24/05/2011 14:58, Paul wrote: >>>>>>> An array object must store a pointer otherwise how does it know, >>>>>>> where >>>>>>> in memory, the array is? >>>>> Actually I should've said array *type* object. >>>>> >>>>> That is the object that stores the address when we do this: >>>>> int arr[43]; >>>>> int* pntrto_array_of_intgr_objs = arr; >>>>> >>>>> The object 'arr' must store the address of the array someplace. >>>> >>>> No it mustn't. Read my initial reply again: >>>> >>> Yes it must how can we do this : >>> int arr[6]; >>> int* p = arr; >>> >>> arr must hold the address of the array or how can it be convered to a >>> pointer? >> >> Wrong; arr does not hold the address of the array; arr *is* the array. >> >>> Do you think this value is plucked out of thin air? >> >> The compiler knows the address of the array relative to something else >> (such as a stack frame pointer or a 'this' pointer). Again if you want >> something that holds the address of the array then you want a pointer >> to an array (as I said above). > > What you say doesn't make sense. You say the compiler KNOWS the address > of the array(whether it be a relative address or otherwise is irrelevant). > How does it KNOW this address? It cannot KNOW this address unless it > stores it someplace. What I said makes perfect sense if you are not dense. The address is calculated using an offset to something else (such as a stack frame pointer or a 'this' pointer). For example for an array on the stack the compiler KNOWS that array element n is located at stack frame pointer + o bytes; if n is a constant then o can be a constant known at compile time; if n is not a constant then all we need is a simple effective address calculation involving the stack frame pointer, n and the sizeof an element to determine the address of element n. > > So where is this address stored and how does the compiler know where to > find this stored address, if arr does not store it? There is no address stored; there is no difference between how the address of an array object is calculated and how the address of any other kind of object is calculated: there is nothing special about arrays. The address of an array or an array element is calculated at runtime using an effective address calculation involving some other pointer (stack frame pointer or a 'this' pointer). Read a book. Read another book. Learn. HTH. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-24 21:04 +0100 |
| Message-ID | <HbUCp.9426$5C7.5793@newsfe10.ams2> |
| In reply to | #5435 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:hKidnekJ2PNbfkbQnZ2dnUVZ8sSdnZ2d@giganews.com... > On 24/05/2011 17:39, Paul wrote: >>>>>>>> An array object must store a pointer otherwise how does it know, >>>>>>>> where >>>>>>>> in memory, the array is? >>>>>> Actually I should've said array *type* object. >>>>>> >>>>>> That is the object that stores the address when we do this: >>>>>> int arr[43]; >>>>>> int* pntrto_array_of_intgr_objs = arr; >>>>>> >>>>>> The object 'arr' must store the address of the array someplace. >>>>> >>>>> No it mustn't. Read my initial reply again: >>>>> >>>> Yes it must how can we do this : >>>> int arr[6]; >>>> int* p = arr; >>>> >>>> arr must hold the address of the array or how can it be convered to a >>>> pointer? >>> >>> Wrong; arr does not hold the address of the array; arr *is* the array. >>> >>>> Do you think this value is plucked out of thin air? >>> >>> The compiler knows the address of the array relative to something else >>> (such as a stack frame pointer or a 'this' pointer). Again if you want >>> something that holds the address of the array then you want a pointer >>> to an array (as I said above). >> >> What you say doesn't make sense. You say the compiler KNOWS the address >> of the array(whether it be a relative address or otherwise is >> irrelevant). >> How does it KNOW this address? It cannot KNOW this address unless it >> stores it someplace. > > What I said makes perfect sense if you are not dense. The address is > calculated using an offset to something else (such as a stack frame > pointer or a 'this' pointer). For example for an array on the stack the > compiler KNOWS that array element n is located at stack frame pointer + o > bytes; if n is a constant then o can be a constant known at compile time; > if n is not a constant then all we need is a simple effective address > calculation involving the stack frame pointer, n and the sizeof an element > to determine the address of element n. > The address cannot be calculated with random numbers. The address must be known, whether it is known as an offset or a real address is irrelevant. This known address must be stored in an object someplace. >> >> So where is this address stored and how does the compiler know where to >> find this stored address, if arr does not store it? > > There is no address stored; there is no difference between how the address > of an array object is calculated and how the address of any other kind of > object is calculated: there is nothing special about arrays. The address > of an array or an array element is calculated at runtime using an > effective address calculation involving some other pointer (stack frame > pointer or a 'this' pointer). It doesn't matter if it is an offset or a real address, the offset value must be stored to be known, it cannot just be magically KNOWN by the compiler. <snip>
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-24 21:11 +0100 |
| Message-ID | <5cadnQfIzuppjUHQnZ2dnUVZ8kidnZ2d@giganews.com> |
| In reply to | #5446 |
On 24/05/2011 21:04, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:hKidnekJ2PNbfkbQnZ2dnUVZ8sSdnZ2d@giganews.com... >> On 24/05/2011 17:39, Paul wrote: >>>>>>>>> An array object must store a pointer otherwise how does it know, >>>>>>>>> where >>>>>>>>> in memory, the array is? >>>>>>> Actually I should've said array *type* object. >>>>>>> >>>>>>> That is the object that stores the address when we do this: >>>>>>> int arr[43]; >>>>>>> int* pntrto_array_of_intgr_objs = arr; >>>>>>> >>>>>>> The object 'arr' must store the address of the array someplace. >>>>>> >>>>>> No it mustn't. Read my initial reply again: >>>>>> >>>>> Yes it must how can we do this : >>>>> int arr[6]; >>>>> int* p = arr; >>>>> >>>>> arr must hold the address of the array or how can it be convered to a >>>>> pointer? >>>> >>>> Wrong; arr does not hold the address of the array; arr *is* the array. >>>> >>>>> Do you think this value is plucked out of thin air? >>>> >>>> The compiler knows the address of the array relative to something else >>>> (such as a stack frame pointer or a 'this' pointer). Again if you want >>>> something that holds the address of the array then you want a pointer >>>> to an array (as I said above). >>> >>> What you say doesn't make sense. You say the compiler KNOWS the address >>> of the array(whether it be a relative address or otherwise is >>> irrelevant). >>> How does it KNOW this address? It cannot KNOW this address unless it >>> stores it someplace. >> >> What I said makes perfect sense if you are not dense. The address is >> calculated using an offset to something else (such as a stack frame >> pointer or a 'this' pointer). For example for an array on the stack >> the compiler KNOWS that array element n is located at stack frame >> pointer + o bytes; if n is a constant then o can be a constant known >> at compile time; if n is not a constant then all we need is a simple >> effective address calculation involving the stack frame pointer, n and >> the sizeof an element to determine the address of element n. >> > The address cannot be calculated with random numbers. The address must > be known, whether it is known as an offset or a real address is irrelevant. > This known address must be stored in an object someplace. > >>> >>> So where is this address stored and how does the compiler know where to >>> find this stored address, if arr does not store it? >> >> There is no address stored; there is no difference between how the >> address of an array object is calculated and how the address of any >> other kind of object is calculated: there is nothing special about >> arrays. The address of an array or an array element is calculated at >> runtime using an effective address calculation involving some other >> pointer (stack frame pointer or a 'this' pointer). > > It doesn't matter if it is an offset or a real address, the offset value > must be stored to be known, it cannot just be magically KNOWN by the > compiler. Asserting falsehoods just makes you look dense. The offset can be "stored" in the text segment. R E A D A B O O K . /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-25 00:12 +0100 |
| Message-ID | <WXWCp.15476$8A7.9999@newsfe12.ams2> |
| In reply to | #5447 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:5cadnQfIzuppjUHQnZ2dnUVZ8kidnZ2d@giganews.com... > On 24/05/2011 21:04, Paul wrote: : >>>>>>>>>> An array object must store a pointer otherwise how does it know, >>>>>>>>>> where >>>>>>>>>> in memory, the array is? >>>>>>>> Actually I should've said array *type* object. >>>>>>>> >>>>>>>> That is the object that stores the address when we do this: >>>>>>>> int arr[43]; >>>>>>>> int* pntrto_array_of_intgr_objs = arr; >>>>>>>> >>>>>>>> The object 'arr' must store the address of the array someplace. >>>>>>> >>>>>>> No it mustn't. Read my initial reply again: >>>>>>> >>>>>> Yes it must how can we do this : >>>>>> int arr[6]; >>>>>> int* p = arr; >>>>>> >>>>>> arr must hold the address of the array or how can it be convered to a >>>>>> pointer? >>>>> >>>>> Wrong; arr does not hold the address of the array; arr *is* the array. >>>>> >>>>>> Do you think this value is plucked out of thin air? >>>>> >>>>> The compiler knows the address of the array relative to something else >>>>> (such as a stack frame pointer or a 'this' pointer). Again if you want >>>>> something that holds the address of the array then you want a pointer >>>>> to an array (as I said above). >>>> >>>> What you say doesn't make sense. You say the compiler KNOWS the address >>>> of the array(whether it be a relative address or otherwise is >>>> irrelevant). >>>> How does it KNOW this address? It cannot KNOW this address unless it >>>> stores it someplace. >>> >>> What I said makes perfect sense if you are not dense. The address is >>> calculated using an offset to something else (such as a stack frame >>> pointer or a 'this' pointer). For example for an array on the stack >>> the compiler KNOWS that array element n is located at stack frame >>> pointer + o bytes; if n is a constant then o can be a constant known >>> at compile time; if n is not a constant then all we need is a simple >>> effective address calculation involving the stack frame pointer, n and >>> the sizeof an element to determine the address of element n. >>> >> The address cannot be calculated with random numbers. The address must >> be known, whether it is known as an offset or a real address is >> irrelevant. >> This known address must be stored in an object someplace. >> >>>> >>>> So where is this address stored and how does the compiler know where to >>>> find this stored address, if arr does not store it? >>> >>> There is no address stored; there is no difference between how the >>> address of an array object is calculated and how the address of any >>> other kind of object is calculated: there is nothing special about >>> arrays. The address of an array or an array element is calculated at >>> runtime using an effective address calculation involving some other >>> pointer (stack frame pointer or a 'this' pointer). >> >> It doesn't matter if it is an offset or a real address, the offset value >> must be stored to be known, it cannot just be magically KNOWN by the >> compiler. > > Asserting falsehoods just makes you look dense. The offset can be > "stored" in the text segment. R E A D A B O O K . > Its an object stored in memory regardless of what segment it is stored in.
[toc] | [prev] | [next] | [standalone]
Page 6 of 21 — ← Prev page 1 … 4 5 [6] 7 8 … 21 Next page →
Back to top | Article view | comp.lang.c++
csiph-web