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 7 of 21 — ← Prev page 1 … 5 6 [7] 8 9 … 21 Next page →
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-25 00:33 +0100 |
| Message-ID | <Go6dnU9userf3UHQnZ2dnUVZ8gednZ2d@giganews.com> |
| In reply to | #5464 |
On 25/05/2011 00:12, Paul wrote: > > "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. > An offset is not an object; an offset can be embedded in the machine code in the text segment where it is used to calculate the address of an object when added to some other pointer such as a stack frame pointer or a 'this' pointer. S T O P B E I N G O B T U S E . R E A D A B O O K . /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-25 11:39 +0100 |
| Message-ID | <805Dp.26220$7H.26163@newsfe08.ams2> |
| In reply to | #5465 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:Go6dnU9userf3UHQnZ2dnUVZ8gednZ2d@giganews.com... > On 25/05/2011 00:12, 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. >> > > An offset is not an object; an offset can be embedded in the machine code > in the text segment where it is used to calculate the address of an object > when added to some other pointer such as a stack frame pointer or a 'this' > pointer. > int arr[6]; std::cout<< arr; The above outputs a memory address, whether you think this is an offset embedded in machine code or it is stored in the XXXX segment is quite irrellevant. I tihnk you are speaking nonsense. It wouldn't be the first time.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-25 12:04 +0100 |
| Message-ID | <NIqdnYIxrM_df0HQnZ2dnUVZ8jGdnZ2d@giganews.com> |
| In reply to | #5483 |
On 25/05/2011 11:39, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:Go6dnU9userf3UHQnZ2dnUVZ8gednZ2d@giganews.com... >> On 25/05/2011 00:12, 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. >>> >> >> An offset is not an object; an offset can be embedded in the machine >> code in the text segment where it is used to calculate the address of >> an object when added to some other pointer such as a stack frame >> pointer or a 'this' pointer. >> > > int arr[6]; > std::cout<< arr; > > The above outputs a memory address, whether you think this is an offset > embedded in machine code or it is stored in the XXXX segment is quite > irrellevant. Of course it is relevant; it is relevant to a discussion in which you claim that an array identifier somehow "stores" a memory address which is plainly absurd. > I tihnk you are speaking nonsense. It wouldn't be the first time. > You have a habit of perfectly describing yourself when attempting to insult others. Arguing with you: "It's like going on a date with a Chatty Cathy doll. I expect you have a little string on your chest, you know, that I pull out and have to snap back. Except I wouldn't pull it out and snap it back - you would. Agh! Agh! Agh! Agh" HTH. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-25 12:56 +0100 |
| Message-ID | <%76Dp.15711$8A7.8058@newsfe12.ams2> |
| In reply to | #5486 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:NIqdnYIxrM_df0HQnZ2dnUVZ8jGdnZ2d@giganews.com... > On 25/05/2011 11:39, Paul wrote: >> <snip> >>>>> 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. >>>> >>> >>> An offset is not an object; an offset can be embedded in the machine >>> code in the text segment where it is used to calculate the address of >>> an object when added to some other pointer such as a stack frame >>> pointer or a 'this' pointer. >>> >> >> int arr[6]; >> std::cout<< arr; >> >> The above outputs a memory address, whether you think this is an offset >> embedded in machine code or it is stored in the XXXX segment is quite >> irrellevant. > > Of course it is relevant; it is relevant to a discussion in which you > claim that an array identifier somehow "stores" a memory address which is > plainly absurd. > I'm obviously talking about an array type object , as described in the C+ standards ref: "[ Note: conversions affecting expressions of array type are described in 4.2. Objects of array types cannot be modified, see 3.10. -end note ]" I don't know why you think this is so "absurd". And why you feel the need to babble on about machine code, text segments, stack pointers, and offsets is beyond me. <snip>
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-25 13:15 +0100 |
| Message-ID | <WtKdnaqX56VWb0HQnZ2dnUVZ8vmdnZ2d@giganews.com> |
| In reply to | #5491 |
On 25/05/2011 12:56, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:NIqdnYIxrM_df0HQnZ2dnUVZ8jGdnZ2d@giganews.com... >> On 25/05/2011 11:39, Paul wrote: >>> > <snip> >>>>>> 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. >>>>> >>>> >>>> An offset is not an object; an offset can be embedded in the machine >>>> code in the text segment where it is used to calculate the address of >>>> an object when added to some other pointer such as a stack frame >>>> pointer or a 'this' pointer. >>>> >>> >>> int arr[6]; >>> std::cout<< arr; >>> >>> The above outputs a memory address, whether you think this is an offset >>> embedded in machine code or it is stored in the XXXX segment is quite >>> irrellevant. >> >> Of course it is relevant; it is relevant to a discussion in which you >> claim that an array identifier somehow "stores" a memory address which >> is plainly absurd. >> > I'm obviously talking about an array type object , as described in the > C+ standards ref: > > "[ Note: conversions affecting expressions of array type are described > in 4.2. Objects of array types cannot be modified, see 3.10. -end note ]" We still do not understand your term "array-type object" and how this differs from "array object". Stop using "Paul terms" if you are unable to define what they mean. In the standard "array object" and "object of array type" are synonyms. > I don't know why you think this is so "absurd". An array object does not store a memory address to itself; implying it does is absurd. > And why you feel the need to babble on about machine code, text > segments, stack pointers, and offsets is beyond me. Because it proves that what you are asserting is rubbish. HTH. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-25 16:36 +0100 |
| Message-ID | <_l9Dp.9139$El6.7816@newsfe21.ams2> |
| In reply to | #5494 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:WtKdnaqX56VWb0HQnZ2dnUVZ8vmdnZ2d@giganews.com... > On 25/05/2011 12:56, Paul wrote: >> >> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >> news:NIqdnYIxrM_df0HQnZ2dnUVZ8jGdnZ2d@giganews.com... >>> On 25/05/2011 11:39, Paul wrote: >>>> >> <snip> >>>>>>> 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. >>>>>> >>>>> >>>>> An offset is not an object; an offset can be embedded in the machine >>>>> code in the text segment where it is used to calculate the address of >>>>> an object when added to some other pointer such as a stack frame >>>>> pointer or a 'this' pointer. >>>>> >>>> >>>> int arr[6]; >>>> std::cout<< arr; >>>> >>>> The above outputs a memory address, whether you think this is an offset >>>> embedded in machine code or it is stored in the XXXX segment is quite >>>> irrellevant. >>> >>> Of course it is relevant; it is relevant to a discussion in which you >>> claim that an array identifier somehow "stores" a memory address which >>> is plainly absurd. >>> >> I'm obviously talking about an array type object , as described in the >> C+ standards ref: >> >> "[ Note: conversions affecting expressions of array type are described >> in 4.2. Objects of array types cannot be modified, see 3.10. -end note ]" > > We still do not understand your term "array-type object" and how this > differs from "array object". Stop using "Paul terms" if you are unable to > define what they mean. In the standard "array object" and "object of > array type" are synonyms. > An array type object is an object of an array type. That is a non modifiable array type object. >> I don't know why you think this is so "absurd". > > An array object does not store a memory address to itself; implying it > does is absurd. > So what object stores this memory address? Its even more absurd to suggest another object is created.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-25 16:47 +0100 |
| Message-ID | <fqqdnf9UIZoAuUDQnZ2dnUVZ8t6dnZ2d@giganews.com> |
| In reply to | #5504 |
On 25/05/2011 16:36, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:WtKdnaqX56VWb0HQnZ2dnUVZ8vmdnZ2d@giganews.com... >> On 25/05/2011 12:56, Paul wrote: >>> >>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>> news:NIqdnYIxrM_df0HQnZ2dnUVZ8jGdnZ2d@giganews.com... >>>> On 25/05/2011 11:39, Paul wrote: >>>>> >>> <snip> >>>>>>>> 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. >>>>>>> >>>>>> >>>>>> An offset is not an object; an offset can be embedded in the machine >>>>>> code in the text segment where it is used to calculate the address of >>>>>> an object when added to some other pointer such as a stack frame >>>>>> pointer or a 'this' pointer. >>>>>> >>>>> >>>>> int arr[6]; >>>>> std::cout<< arr; >>>>> >>>>> The above outputs a memory address, whether you think this is an >>>>> offset >>>>> embedded in machine code or it is stored in the XXXX segment is quite >>>>> irrellevant. >>>> >>>> Of course it is relevant; it is relevant to a discussion in which you >>>> claim that an array identifier somehow "stores" a memory address which >>>> is plainly absurd. >>>> >>> I'm obviously talking about an array type object , as described in the >>> C+ standards ref: >>> >>> "[ Note: conversions affecting expressions of array type are described >>> in 4.2. Objects of array types cannot be modified, see 3.10. -end >>> note ]" >> >> We still do not understand your term "array-type object" and how this >> differs from "array object". Stop using "Paul terms" if you are unable >> to define what they mean. In the standard "array object" and "object >> of array type" are synonyms. >> > > An array type object is an object of an array type. That is a non > modifiable array type object. I repeat: nobody understands what you mean by "array type objects" being different to "array objects"; stop using these terms as you are unable to articulate what you mean by them. > >>> I don't know why you think this is so "absurd". >> >> An array object does not store a memory address to itself; implying it >> does is absurd. >> > So what object stores this memory address? > Its even more absurd to suggest another object is created. Nobody except you is suggesting that. I have asserted that *no* memory address is stored *at all*; there is only one object and that is the array object itself; nothing stores its address as nothing needs to store its address as its address can be *calculated* at runtime. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-25 17:15 +0100 |
| Message-ID | <3X9Dp.21606$yI6.13500@newsfe06.ams2> |
| In reply to | #5505 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:fqqdnf9UIZoAuUDQnZ2dnUVZ8t6dnZ2d@giganews.com... > On 25/05/2011 16:36, Paul wrote: >>>> <snip> >>>>>>>>> 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. >>>>>>>> >>>>>>> >>>>>>> An offset is not an object; an offset can be embedded in the machine >>>>>>> code in the text segment where it is used to calculate the address >>>>>>> of >>>>>>> an object when added to some other pointer such as a stack frame >>>>>>> pointer or a 'this' pointer. >>>>>>> >>>>>> >>>>>> int arr[6]; >>>>>> std::cout<< arr; >>>>>> >>>>>> The above outputs a memory address, whether you think this is an >>>>>> offset >>>>>> embedded in machine code or it is stored in the XXXX segment is quite >>>>>> irrellevant. >>>>> >>>>> Of course it is relevant; it is relevant to a discussion in which you >>>>> claim that an array identifier somehow "stores" a memory address which >>>>> is plainly absurd. >>>>> >>>> I'm obviously talking about an array type object , as described in the >>>> C+ standards ref: >>>> >>>> "[ Note: conversions affecting expressions of array type are described >>>> in 4.2. Objects of array types cannot be modified, see 3.10. -end >>>> note ]" >>> >>> We still do not understand your term "array-type object" and how this >>> differs from "array object". Stop using "Paul terms" if you are unable >>> to define what they mean. In the standard "array object" and "object >>> of array type" are synonyms. >>> >> >> An array type object is an object of an array type. That is a non >> modifiable array type object. > > I repeat: nobody understands what you mean by "array type objects" being > different to "array objects"; stop using these terms as you are unable to > articulate what you mean by them. You don't speak for everyone here. If you don't understand what is meant by this then <shrug> what more can one do to explain this. > >> >>>> I don't know why you think this is so "absurd". >>> >>> An array object does not store a memory address to itself; implying it >>> does is absurd. >>> >> So what object stores this memory address? >> Its even more absurd to suggest another object is created. > > Nobody except you is suggesting that. I have asserted that *no* memory > address is stored *at all*; there is only one object and that is the array > object itself; nothing stores its address as nothing needs to store its > address as its address can be *calculated* at runtime. > You are trying to suggest that some offset is stored in the text segment. How can its address be calcualted at runtime? Are you suggesting that an expression such as arr[2]; is converted to address at runtime?
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-25 17:39 +0100 |
| Message-ID | <Ps6dnYcL8d1LrUDQnZ2dnUVZ8sadnZ2d@giganews.com> |
| In reply to | #5508 |
On 25/05/2011 17:15, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:fqqdnf9UIZoAuUDQnZ2dnUVZ8t6dnZ2d@giganews.com... >> On 25/05/2011 16:36, Paul wrote: >>>>> <snip> >>>>>>>>>> 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. >>>>>>>>> >>>>>>>> >>>>>>>> An offset is not an object; an offset can be embedded in the >>>>>>>> machine >>>>>>>> code in the text segment where it is used to calculate the >>>>>>>> address of >>>>>>>> an object when added to some other pointer such as a stack frame >>>>>>>> pointer or a 'this' pointer. >>>>>>>> >>>>>>> >>>>>>> int arr[6]; >>>>>>> std::cout<< arr; >>>>>>> >>>>>>> The above outputs a memory address, whether you think this is an >>>>>>> offset >>>>>>> embedded in machine code or it is stored in the XXXX segment is >>>>>>> quite >>>>>>> irrellevant. >>>>>> >>>>>> Of course it is relevant; it is relevant to a discussion in which you >>>>>> claim that an array identifier somehow "stores" a memory address >>>>>> which >>>>>> is plainly absurd. >>>>>> >>>>> I'm obviously talking about an array type object , as described in the >>>>> C+ standards ref: >>>>> >>>>> "[ Note: conversions affecting expressions of array type are described >>>>> in 4.2. Objects of array types cannot be modified, see 3.10. -end >>>>> note ]" >>>> >>>> We still do not understand your term "array-type object" and how this >>>> differs from "array object". Stop using "Paul terms" if you are unable >>>> to define what they mean. In the standard "array object" and "object >>>> of array type" are synonyms. >>>> >>> >>> An array type object is an object of an array type. That is a non >>> modifiable array type object. >> >> I repeat: nobody understands what you mean by "array type objects" >> being different to "array objects"; stop using these terms as you are >> unable to articulate what you mean by them. > > > You don't speak for everyone here. Nevertheless what I said is correct. > If you don't understand what is meant by this then <shrug> what more can > one do to explain this. Nobody understands what *you* mean by these vague terms of *yours* as *you* have failed to define them clearly. >>>>> I don't know why you think this is so "absurd". >>>> >>>> An array object does not store a memory address to itself; implying it >>>> does is absurd. >>>> >>> So what object stores this memory address? >>> Its even more absurd to suggest another object is created. >> >> Nobody except you is suggesting that. I have asserted that *no* memory >> address is stored *at all*; there is only one object and that is the >> array object itself; nothing stores its address as nothing needs to >> store its address as its address can be *calculated* at runtime. >> > You are trying to suggest that some offset is stored in the text segment. Correct. > > How can its address be calcualted at runtime? If the array index is constant than a fixed offset (defined at compile time) is simply added to some other pointer (such as a stack frame pointer or a 'this' pointer). > Are you suggesting that an expression such as arr[2]; is converted to > address at runtime? > The address of 'arr[2]' can be calculated (see above) at runtime yes if 'arr' is not of static storage duration. If 'arr' was of static storage duration then its address is usually fixed at compile/link time. HTH. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-25 21:09 +0100 |
| Message-ID | <OldDp.11191$ue1.944@newsfe28.ams2> |
| In reply to | #5510 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:Ps6dnYcL8d1LrUDQnZ2dnUVZ8sadnZ2d@giganews.com... > On 25/05/2011 17:15, Paul wrote: >> >> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >> news:fqqdnf9UIZoAuUDQnZ2dnUVZ8t6dnZ2d@giganews.com... >>> On 25/05/2011 16:36, Paul wrote: >>>>>> <snip> >>>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>> >>>>>>>>> An offset is not an object; an offset can be embedded in the >>>>>>>>> machine >>>>>>>>> code in the text segment where it is used to calculate the >>>>>>>>> address of >>>>>>>>> an object when added to some other pointer such as a stack frame >>>>>>>>> pointer or a 'this' pointer. >>>>>>>>> >>>>>>>> >>>>>>>> int arr[6]; >>>>>>>> std::cout<< arr; >>>>>>>> >>>>>>>> The above outputs a memory address, whether you think this is an >>>>>>>> offset >>>>>>>> embedded in machine code or it is stored in the XXXX segment is >>>>>>>> quite >>>>>>>> irrellevant. >>>>>>> >>>>>>> Of course it is relevant; it is relevant to a discussion in which >>>>>>> you >>>>>>> claim that an array identifier somehow "stores" a memory address >>>>>>> which >>>>>>> is plainly absurd. >>>>>>> >>>>>> I'm obviously talking about an array type object , as described in >>>>>> the >>>>>> C+ standards ref: >>>>>> >>>>>> "[ Note: conversions affecting expressions of array type are >>>>>> described >>>>>> in 4.2. Objects of array types cannot be modified, see 3.10. -end >>>>>> note ]" >>>>> >>>>> We still do not understand your term "array-type object" and how this >>>>> differs from "array object". Stop using "Paul terms" if you are unable >>>>> to define what they mean. In the standard "array object" and "object >>>>> of array type" are synonyms. >>>>> >>>> >>>> An array type object is an object of an array type. That is a non >>>> modifiable array type object. >>> >>> I repeat: nobody understands what you mean by "array type objects" >>> being different to "array objects"; stop using these terms as you are >>> unable to articulate what you mean by them. >> >> >> You don't speak for everyone here. > > Nevertheless what I said is correct. > >> If you don't understand what is meant by this then <shrug> what more can >> one do to explain this. > > Nobody understands what *you* mean by these vague terms of *yours* as > *you* have failed to define them clearly. Well the authors of the C++ seem to understand it, why do they use the same terms? I requote: "[ Note: conversions affecting expressions of array type are described in 4.2. Objects of array types cannot be modified, see 3.10. -end note ]" So what is it you find vague about objects of array types? Or do you think there is a difference between me saying an "array type object" and an "object of array type"? <snip>
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-25 22:24 +0100 |
| Message-ID | <8-6dnR3ahbAQ7kDQnZ2dnUVZ7s-dnZ2d@giganews.com> |
| In reply to | #5521 |
On 25/05/2011 21:09, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:Ps6dnYcL8d1LrUDQnZ2dnUVZ8sadnZ2d@giganews.com... >> On 25/05/2011 17:15, Paul wrote: >>> >>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>> news:fqqdnf9UIZoAuUDQnZ2dnUVZ8t6dnZ2d@giganews.com... >>>> On 25/05/2011 16:36, Paul wrote: >>>>>>> <snip> >>>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> An offset is not an object; an offset can be embedded in the >>>>>>>>>> machine >>>>>>>>>> code in the text segment where it is used to calculate the >>>>>>>>>> address of >>>>>>>>>> an object when added to some other pointer such as a stack frame >>>>>>>>>> pointer or a 'this' pointer. >>>>>>>>>> >>>>>>>>> >>>>>>>>> int arr[6]; >>>>>>>>> std::cout<< arr; >>>>>>>>> >>>>>>>>> The above outputs a memory address, whether you think this is an >>>>>>>>> offset >>>>>>>>> embedded in machine code or it is stored in the XXXX segment is >>>>>>>>> quite >>>>>>>>> irrellevant. >>>>>>>> >>>>>>>> Of course it is relevant; it is relevant to a discussion in >>>>>>>> which you >>>>>>>> claim that an array identifier somehow "stores" a memory address >>>>>>>> which >>>>>>>> is plainly absurd. >>>>>>>> >>>>>>> I'm obviously talking about an array type object , as described >>>>>>> in the >>>>>>> C+ standards ref: >>>>>>> >>>>>>> "[ Note: conversions affecting expressions of array type are >>>>>>> described >>>>>>> in 4.2. Objects of array types cannot be modified, see 3.10. -end >>>>>>> note ]" >>>>>> >>>>>> We still do not understand your term "array-type object" and how this >>>>>> differs from "array object". Stop using "Paul terms" if you are >>>>>> unable >>>>>> to define what they mean. In the standard "array object" and "object >>>>>> of array type" are synonyms. >>>>>> >>>>> >>>>> An array type object is an object of an array type. That is a non >>>>> modifiable array type object. >>>> >>>> I repeat: nobody understands what you mean by "array type objects" >>>> being different to "array objects"; stop using these terms as you are >>>> unable to articulate what you mean by them. >>> >>> >>> You don't speak for everyone here. >> >> Nevertheless what I said is correct. >> >>> If you don't understand what is meant by this then <shrug> what more can >>> one do to explain this. >> >> Nobody understands what *you* mean by these vague terms of *yours* as >> *you* have failed to define them clearly. > > Well the authors of the C++ seem to understand it, why do they use the > same terms? I have already said the terms in the standard are synonyms whereas your terms are apparently not synonyms but have special distinct meanings that only you seem to understand. > I requote: > "[ Note: conversions affecting expressions of array type are described > in 4.2. Objects of array types cannot be modified, see 3.10. -end note ]" "array object" and "object of array type" are synonyms (the same thing). > > So what is it you find vague about objects of array types? > Or do you think there is a difference between me saying an "array type > object" and an "object of array type"? Nobody but *you* understands the difference between how *you* define these terms of *yours*. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-26 01:28 +0100 |
| Message-ID | <49hDp.12042$A05.1791@newsfe13.ams2> |
| In reply to | #5535 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:8-6dnR3ahbAQ7kDQnZ2dnUVZ7s-dnZ2d@giganews.com... > On 25/05/2011 21:09, Paul wrote: >> >>>>>>>> <snip> >>>>>>>>>>>>> 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. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> An offset is not an object; an offset can be embedded in the >>>>>>>>>>> machine >>>>>>>>>>> code in the text segment where it is used to calculate the >>>>>>>>>>> address of >>>>>>>>>>> an object when added to some other pointer such as a stack frame >>>>>>>>>>> pointer or a 'this' pointer. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> int arr[6]; >>>>>>>>>> std::cout<< arr; >>>>>>>>>> >>>>>>>>>> The above outputs a memory address, whether you think this is an >>>>>>>>>> offset >>>>>>>>>> embedded in machine code or it is stored in the XXXX segment is >>>>>>>>>> quite >>>>>>>>>> irrellevant. >>>>>>>>> >>>>>>>>> Of course it is relevant; it is relevant to a discussion in >>>>>>>>> which you >>>>>>>>> claim that an array identifier somehow "stores" a memory address >>>>>>>>> which >>>>>>>>> is plainly absurd. >>>>>>>>> >>>>>>>> I'm obviously talking about an array type object , as described >>>>>>>> in the >>>>>>>> C+ standards ref: >>>>>>>> >>>>>>>> "[ Note: conversions affecting expressions of array type are >>>>>>>> described >>>>>>>> in 4.2. Objects of array types cannot be modified, see 3.10. -end >>>>>>>> note ]" >>>>>>> >>>>>>> We still do not understand your term "array-type object" and how >>>>>>> this >>>>>>> differs from "array object". Stop using "Paul terms" if you are >>>>>>> unable >>>>>>> to define what they mean. In the standard "array object" and "object >>>>>>> of array type" are synonyms. >>>>>>> >>>>>> >>>>>> An array type object is an object of an array type. That is a non >>>>>> modifiable array type object. >>>>> >>>>> I repeat: nobody understands what you mean by "array type objects" >>>>> being different to "array objects"; stop using these terms as you are >>>>> unable to articulate what you mean by them. >>>> >>>> >>>> You don't speak for everyone here. >>> >>> Nevertheless what I said is correct. >>> >>>> If you don't understand what is meant by this then <shrug> what more >>>> can >>>> one do to explain this. >>> >>> Nobody understands what *you* mean by these vague terms of *yours* as >>> *you* have failed to define them clearly. >> >> Well the authors of the C++ seem to understand it, why do they use the >> same terms? > > I have already said the terms in the standard are synonyms whereas your > terms are apparently not synonyms but have special distinct meanings that > only you seem to understand. > >> I requote: >> "[ Note: conversions affecting expressions of array type are described >> in 4.2. Objects of array types cannot be modified, see 3.10. -end note ]" > > "array object" and "object of array type" are synonyms (the same thing). > >> >> So what is it you find vague about objects of array types? >> Or do you think there is a difference between me saying an "array type >> object" and an "object of array type"? > > Nobody but *you* understands the difference between how *you* define these > terms of *yours*. > You are obviously to thick to understand even though It has been explained to you.
[toc] | [prev] | [next] | [standalone]
| From | Thomas David Rivers <rivers@dignus.com> |
|---|---|
| Date | 2011-05-25 09:57 -0400 |
| Message-ID | <4DDD0AE0.9080001@dignus.com> |
| In reply to | #5483 |
Paul wrote:
>
> int arr[6];
> std::cout<< arr;
>
> The above outputs a memory address, whether you think this is an
> offset embedded in machine code or it is stored in the XXXX segment is
> quite irrellevant.
> I tihnk you are speaking nonsense. It wouldn't be the first time.
>
Not to add too much or be drawn too far into this...
But - it prints an address because of the rule that a rvalue reference
to an array becomes the address of the first element of the array; which
has been mentioned before...
So, when the compiler evaluates the expression 'arr', as an operand
of the '<<' operator; it discovers an array name. The compiler applies
that rule, and produces an expression that is a pointer to the first
element of the array.
So.. the type of right-hand-side of '<<' (after this implicit
conversion) is
'int *', the value of the right-hand-side is the address of the first
element
of 'arr'.
Thus... the expression 'arr' is actually completely the same (in this
example)
as the expression '&arr[0]'.
That is , this statement:
std::cout<<arr;
is exactly the same as this statement:
std::cout<<(&arr[0]);
This is a subtle and important rule.
It even explains how array indexing is accomplished:
In this snippet:
int i; int array[10];
i = array[5];
when the compiler examines the expression 'array[5]'; it has
to implement the indexing operation in some fashion. Many compilers
simply follow the rule, so that 'array[5]' (internally in the compiler)
is actually expressed as:
(&array[0]) + 5;
If you think about it; this is also why indexing works "backwards",
that is:
[5]array
is a valid C expression that accesses the 5th element of the array.
Because 'array' is simply short-hand for (&array[0]). So,
the expression:
[5]array;
becomes:
5 + (&array[0]);
Note that the type of &array[0] is (in this example) an `int *'; so
that the expressions are simply pointer addition.
This is where people tend to confuse arrays and pointers; because
array indexing devolves into pointer addition.
But - that is preciesly why, in your std:: example, the result is
a memory address. The expression 'arr' is just "short hand" for (&arr[0]).
I think, if you apply this rule (which is in both the C and C++ standards)
things might become clearer.
Now - to the point of "there is some 'object' that holds this address."
Well, clearly the object has an address - however, there need not be
a separate object to "hold" that. The compiler can generate code that
calculates that address at runtime.
A simple example might help:
int i; int *ip;
ip = &i+1;
In this example, we have taken the address of 'i'. Does the compiler
need a separate 'object' to hold that address... well, not actually... but,
certainly it will calculate the address and use it in some fashion.
In fact, the compiler will compute the address of 'i', add the sizeof(int)
to that address and store the result in 'ip'. In the C/C++ sense, there
was never a 'container/object' that held the address of `i'; it was simply
calculated at runtime. There wasn't, necessarily, a separate 'container'
to hold the address of 'i'.
Having said that, just _how_ the compiler calculates &i might involve
runtime entities (not C++ 'objects')... for example, it may have to load
the address 'i' into a hardware register and add the sizeof(int) to it.
In that sense; the hardware register is the container that the generated
code employs to implement the expression... but, there's not a C++ "object"
for it... it's just how the expression is compiled.
I may be stepping into a quagmire here.. but, please consider this
simple rule.
When you see the name of an array in an expression, it is simply
"short-hand" for the address of the first element of the array.
I think ou can apply that rule and come to the understanding
of the intent of the C and C++ languages.
- Dave Rivers-
--
rivers@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
[toc] | [prev] | [next] | [standalone]
| From | "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> |
|---|---|
| Date | 2011-05-25 16:50 +0200 |
| Message-ID | <irj4k8$1r2$1@dont-email.me> |
| In reply to | #5497 |
* Thomas David Rivers, on 25.05.2011 15:57:
> Paul wrote:
>
>>
>> int arr[6];
>> std::cout<< arr;
>>
>> The above outputs a memory address, whether you think this is an offset
>> embedded in machine code or it is stored in the XXXX segment is quite
>> irrellevant.
>> I tihnk you are speaking nonsense. It wouldn't be the first time.
>>
>
[snip]
>
> That is , this statement:
>
> std::cout<<arr;
>
> is exactly the same as this statement:
>
> std::cout<<(&arr[0]);
>
> This is a subtle and important rule.
Note that (1) the above is true for the standard iostreams, but not in general
for other objects, and (2) Paul is a well-known troll, don't feed him.
[snip]
> When you see the name of an array in an expression, it is simply
> "short-hand" for the address of the first element of the array.
No, that's incorrect.
For example:
struct S
{
template< int n >
void operator<<( int (&)[n] )
{
cout << "Your array has " << n << " elements.\n";
}
};
int main()
{
int arr[6];
S stream;
stream << arr;
}
Cheers & hth.,
- Alf
--
blog at <url: http://alfps.wordpress.com>
[toc] | [prev] | [next] | [standalone]
| From | Thomas David Rivers <rivers@dignus.com> |
|---|---|
| Date | 2011-05-25 12:01 -0400 |
| Message-ID | <4DDD27F7.3080009@dignus.com> |
| In reply to | #5503 |
Alf P. Steinbach /Usenet wrote:
>
> No, that's incorrect.
>
> For example:
>
> struct S
> {
> template< int n >
> void operator<<( int (&)[n] )
> {
> cout << "Your array has " << n << " elements.\n";
> }
> };
>
> int main()
> {
> int arr[6];
> S stream;
>
> stream << arr;
> }
>
>
> Cheers & hth.,
>
> - Alf
>
Ah yes - you're correct....
I was over-simplifying... (neglecting templates and function-overloading
situations...) I should have said that I was speaking in more simple terms.
Basic C-like expressions...
And, I think, my assertion breaks down in the delete[] situation as well.
(Although, in your example, you didn't access the 'arr' array, only the
number of elements.... so, a twisted argument in the template situation
could be had... but, in truth, my "blanket" statement is clearly too
simple.)
I tend to lean more toward "C-isms" where the type is less involved in
distinguishing behavior.
I was also trying to motivate the idea of "pointer to first element".
Hopefully, my attempt to make that point isn't lost in the morass of
other issues.
- Dave Rivers -
--
rivers@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-25 16:59 +0100 |
| Message-ID | <WH9Dp.9142$El6.1012@newsfe21.ams2> |
| In reply to | #5497 |
"Thomas David Rivers" <rivers@dignus.com> wrote in message
news:4DDD0AE0.9080001@dignus.com...
> Paul wrote:
>
>>
>> int arr[6];
>> std::cout<< arr;
>>
>> The above outputs a memory address, whether you think this is an offset
>> embedded in machine code or it is stored in the XXXX segment is quite
>> irrellevant.
>> I tihnk you are speaking nonsense. It wouldn't be the first time.
>>
>
> Not to add too much or be drawn too far into this...
>
> But - it prints an address because of the rule that a rvalue reference
> to an array becomes the address of the first element of the array; which
> has been mentioned before...
>
> So, when the compiler evaluates the expression 'arr', as an operand
> of the '<<' operator; it discovers an array name. The compiler applies
> that rule, and produces an expression that is a pointer to the first
> element of the array.
> So.. the type of right-hand-side of '<<' (after this implicit conversion)
> is
> 'int *', the value of the right-hand-side is the address of the first
> element
> of 'arr'.
>
> Thus... the expression 'arr' is actually completely the same (in this
> example)
> as the expression '&arr[0]'.
>
> That is , this statement:
>
> std::cout<<arr;
>
> is exactly the same as this statement:
>
> std::cout<<(&arr[0]);
>
> This is a subtle and important rule.
>
> It even explains how array indexing is accomplished:
>
> In this snippet:
>
> int i; int array[10];
>
> i = array[5];
>
> when the compiler examines the expression 'array[5]'; it has
> to implement the indexing operation in some fashion. Many compilers
> simply follow the rule, so that 'array[5]' (internally in the compiler)
> is actually expressed as:
>
> (&array[0]) + 5;
>
> If you think about it; this is also why indexing works "backwards",
> that is:
>
> [5]array
>
> is a valid C expression that accesses the 5th element of the array.
> Because 'array' is simply short-hand for (&array[0]). So,
> the expression:
>
> [5]array;
>
> becomes:
>
> 5 + (&array[0]);
>
>
> Note that the type of &array[0] is (in this example) an `int *'; so
> that the expressions are simply pointer addition.
>
> This is where people tend to confuse arrays and pointers; because
> array indexing devolves into pointer addition.
>
>
> But - that is preciesly why, in your std:: example, the result is
> a memory address. The expression 'arr' is just "short hand" for
> (&arr[0]).
>
> I think, if you apply this rule (which is in both the C and C++ standards)
> things might become clearer.
>
> Now - to the point of "there is some 'object' that holds this address."
>
> Well, clearly the object has an address - however, there need not be
> a separate object to "hold" that. The compiler can generate code that
> calculates that address at runtime.
No you have got something wrong here.
When code is executed at runtime it does not get compiled
> A simple example might help:
>
> int i; int *ip;
>
> ip = &i+1;
>
> In this example, we have taken the address of 'i'. Does the compiler
> need a separate 'object' to hold that address... well, not actually...
> but,
> certainly it will calculate the address and use it in some fashion.
An array object is not the same as a single variable.
An array is a sequence of objects that cannot be addressed with a single
instruction, unless its size one or soemthing silly.
An object of array type is an object that strores the pointer to the array ,
for example arr in the following:
int arr[5];
output arr and you will find it has a pointer value.
examine arr with typeid and you will find it is an array type.
examine with sizeof and you get the size of the whole array
arr is a non modifiable object that decays in a pointer. The pointer
value(the address of the array) is stored someplace so that when the program
is exectued the location of an element can be accessed for example:
void foo(int* p){
p[2] = 6;
}
This function will correctly process 'arr' even though it may be compiled on
a different machine. You could write fucntion in asm or some other language
that supports pointers becuase an object of array type decays into a
pointer.
A compiler translates C++ code into object code.
>
> In fact, the compiler will compute the address of 'i', add the sizeof(int)
> to that address and store the result in 'ip'. In the C/C++ sense, there
> was never a 'container/object' that held the address of `i'; it was simply
> calculated at runtime. There wasn't, necessarily, a separate 'container'
> to hold the address of 'i'.
>
> Having said that, just _how_ the compiler calculates &i might involve
> runtime entities (not C++ 'objects')... for example, it may have to load
> the address 'i' into a hardware register and add the sizeof(int) to it.
>
> In that sense; the hardware register is the container that the generated
> code employs to implement the expression... but, there's not a C++
> "object"
> for it... it's just how the expression is compiled.
>
Got nothing to do with hardware registers really. Its more to do with
terminology and peoples understanding.
A non modifiable object of array type, is not the same thing as an array of
integer objects that this object references.
Although an array is not a pointer in C++. For the sake of this discussion
an array can be seen as basically a pointer tot he first element because in
most situations it decays into a pointer.
HTH Paul.
[toc] | [prev] | [next] | [standalone]
| From | Thomas David Rivers <rivers@dignus.com> |
|---|---|
| Date | 2011-05-25 12:56 -0400 |
| Message-ID | <4DDD34A8.6030005@dignus.com> |
| In reply to | #5506 |
Paul wrote:
>
> An array object is not the same as a single variable.
Well - this is likely a mistake.. but....
Let me say that appreciate your zeal in defending your understanding.
Let's start with some pretty basic principles.
First - to offer my credentials... I've actually implemented C and C++
compilers,
we have one of the premier offerings for the mainframe (z/Architecture)
system.
So, I speak with some authority (BTDT.)
In my discussions below, I am trying to be clear, but if I'm not, let
me apoligize
a-priori... if I am unclear, please feel free to ask...
So - to begin with some basic principles; let's remove the complications
of templates, function overloading, etc... and let's just talk
about some really simple/straight-forward examples and how things
actually work "under the covers" for those simple situations.
>
> An array is a sequence of objects that cannot be addressed with a
> single instruction, unless its size one or soemthing silly.
> An object of array type is an object that strores the pointer to the
> array , for example arr in the following:
>
> int arr[5];
Hmm... those sound like nice definitions... but, I think I would prefer
some simpler ones. I'm terribly confused by this "object of array type"
you have there, and why you would need one...
So - let me offer these...
Let's say that an array is a contiguous sequence of elements.
Arrays may be indexed, which results in a single element. (Let's not get
into multi-dimension issues for the moment; just one dimension.) An array
defines the number of elements it comprises, starting at element #0 and
continuing to n-1 elements.
Does that sound good?
If so - let's continue with this example:
int arr[5];
If we agree on the basic definition, then this would indicate that,
somewhere at runtime, there is a contiguous set of 5 'int' elements.
The name of that contigous set of elements is 'arr'.
Does that sound good?
So - then, expanding further... using our definition above, let's
consider this snippet:
int i;
int arr[5];
i = arr[4];
What are the basic semantics of that? I propose that would mean
to find the location of the array name 'arr', treat this as a pointer to
the first element of the array (per the rule), add to that starting
address 4*sizeof(int), to compute the address of the 4th element.
Dereference that point to access the `int' value located there,
then assign that `int' value to the variable 'i'.
Does that sound good/proper... is there something not right there?
(albeit, perhaps I'm a little loose, but I'm avoiding specifics like
'registers' and 'memory'.)
Now, let's consider this snippet:
int i;
int arr[5];
i = *((&arr[0]) + 4);
What does that statement do?
Following the indexing example we just walked thru, I propose
that it would mean, find the address of 'arr', treat it as a pointer to
the first element (per the rule), add 0*sizeof(int) to that pointer
to compute the address of the 0th element. Apply the '&' operator
which results in that same address. At this point, we have an (int *)
pointer to the 0th element. Add 4*sizeof(int) to it; which happens to
produce a pointer to the 4th element of the array. Apply the '*' operator
to dereference that point, which produces an `int' that is the 4th
element of the array. Assign that value to `i'.
Does that sound right?
I believe that would show, in this basic situation; the equivalence
of the two statements.
If you agree with that; then we have a very simple answer to this
statement:
>
>
> output arr and you will find it has a pointer value.
Yes! That is true (again, neglecting templates and other more complicated
type situations.) I think, the reason it is true is because the
expression 'arr'
becomes a pointer to the first element of the array... hence, it,
definitionally
is a pointer value.
> examine arr with typeid and you will find it is an array type.
OK - at this point - let's bring typeid back into the picture.
You are correct; it _is_ an array type... so - why does typeid() not say
it's a pointer??? I just got thru explaining why it would be a pointer,
but typeid() says it's not! What's going on?
This is because of the semantics of typeid(). My statements/rationing
above was discussing accessing the array... not examining its type.
typeid() only looks at the type... the type of 'arr' is the contigous set
of 5 elements... recall that typeid() doesn't evaluate the expression, it
evaluates the type of the expression... it's an important distinction.
> examine with sizeof and you get the size of the whole array
The reason for this is the same as typeid(), sizeof() deals in the type
of the expression - it does not evaluate it.
> arr is a non modifiable object that decays in a pointer. The pointer
> value(the address of the array) is stored someplace so that when the
> program is exectued the location of an element can be accessed for
> example:
I'm not sure about the 'non-modifiable' part of that...
Clearly though, when you say "the pointer value.. is stored
someplace"... that is
frequently true... in this example:
>
>
> void foo(int* p){
> p[2] = 6;
> }
>
If foo() were invoked with 'arr' as a parameter; then the address of
'arr' must
be stored somewhere... it's clearly stored in 'p'.
However, I believe the question really is "is it stored somewhere
else?" That is,
is there another "object" that contains the address of 'arr'.. and the
value
of the other object would be passed to foo()?
I think the answer is "well, you _could_ do it that way - but - it's
frequently
not needed."
Let's consider this for example:
int *ip;
int arr[5];
ip = arr;
foo(ip);
Would you say that would be equivalent to:
int arr[5];
foo(arr);
If so, then in the first case, clearly the pointer to the first element
of `arr'
has been saved in the "object" named `ip'. That value is then passed
as a parameter to foo().
In the second case, is there some mysterious unnamed "object" which
contains the address of the first element of `arr', and the value
of the unnamed "object" is then passed as a parameter to foo()?
Well - as an implementation detail; you _could_ do that... but it is more
likely that the compiler can generate code that computes the address
of `arr' and simply passes that computed value as the parameter to foo()?
Thus, if my assertion is correct the expression:
foo(arr)
actually can be thought to be equivalent to
foo((&arr[0]))
(again, neglecting templates/function-overloading, etc... let's keep it
simple.)
The second expression simply makes the underlying semantics obvious.
>
>>
>> In that sense; the hardware register is the container that the generated
>> code employs to implement the expression... but, there's not a C++
>> "object"
>> for it... it's just how the expression is compiled.
>>
> Got nothing to do with hardware registers really. Its more to do with
> terminology and peoples understanding.
You are correct - I was using 'registers' as a term that I was hoping would
make things clear; I hope the discussion above (which avoids that) is more
in-line with what you are looking for.
> A non modifiable object of array type, is not the same thing as an
> array of integer objects that this object references.
I'm having problems with this sentence.. when you say "A non
modifiable object
of array type"; do you mean a `const' array ? I'm not sure I
understand what you're
getting at there...
Are you saying there exists this unnamed "object" that contains the
pointer to
array?
> Although an array is not a pointer in C++. For the sake of this
> discussion an array can be seen as basically a pointer to the first
> element because in most situations it decays into a pointer.
I think this is an oversimplication; as you point out above... If we
agree
that an array is a contiguous set of elements, then that's what it is...
We then say that there is this added rule that when the array name is
referenced
in an expression, the result of that expression is a pointer to the
first element...
With those two, one can readily define the []-operator in a consistent
fashion
vis-a-vis pointer addition.
That is (and, again, this is neglecting templates/function-overloading,
etc...)
given these declarations:
int i;
int arr[5];
the statements:
i = arr[4];
and
i = *((&arr[0])+4);
are completely equivalent.
If we can agree on those definitions and these basic semantics, then we can
proceed to talk about the slightly-more-complicated issues, in particular,
how do you handle multiple dimensions, and what does "&arr" mean?
However, one step at a time.
- Dave Rivers -
--
rivers@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-25 21:46 +0100 |
| Message-ID | <4VdDp.17340$h35.4417@newsfe19.ams2> |
| In reply to | #5511 |
"Thomas David Rivers" <rivers@dignus.com> wrote in message
news:4DDD34A8.6030005@dignus.com...
> Paul wrote:
>
>>
>> An array object is not the same as a single variable.
>
>
> Well - this is likely a mistake.. but....
>
> Let me say that appreciate your zeal in defending your understanding.
>
> Let's start with some pretty basic principles.
>
> First - to offer my credentials... I've actually implemented C and C++
> compilers,
> we have one of the premier offerings for the mainframe (z/Architecture)
> system.
> So, I speak with some authority (BTDT.)
>
> In my discussions below, I am trying to be clear, but if I'm not, let me
> apoligize
> a-priori... if I am unclear, please feel free to ask...
>
> So - to begin with some basic principles; let's remove the complications
> of templates, function overloading, etc... and let's just talk
> about some really simple/straight-forward examples and how things
> actually work "under the covers" for those simple situations.
>
So basically you want to consider an array as a simple pointer.
>>
>> An array is a sequence of objects that cannot be addressed with a single
>> instruction, unless its size one or soemthing silly.
>> An object of array type is an object that strores the pointer to the
>> array , for example arr in the following:
>>
>> int arr[5];
>
>
> Hmm... those sound like nice definitions... but, I think I would prefer
> some simpler ones. I'm terribly confused by this "object of array type"
> you have there, and why you would need one...
Hold on lets clear this confusion up.
In asm an array is basically a pointer, in C++ its an object of array type
(which I see as a non modifiable pointer with added typeinfo).
So according to C++ with the deifnition:
int arr[5];
The object arr is not a pointer , it is a non modifiable object of array
type.
If you want to forget about all the typeinfo etc and simply regard this as a
pointer for the sake of the dscussion I can go with that.
>
> So - let me offer these...
>
> Let's say that an array is a contiguous sequence of elements.
Aha now you are shifting the focus, to the actual objects of the array. Lets
be clear about these two definintions of array.
We have an array of 5 ints like so:
[int][int][int][int][int]
To access this array we need to have a pointer so we have:
[ptr_arr]...................[int][int][int][int][int]
The term array can be applied to a contiguous sequence of integer objects or
to the identifier(pointer) for these objects.
Going back to the old arr , arr is a pointer object that points to the
sequence of integer objects. This is a different object from any of the five
integer objects
1) An array is a pointer such as arr.
2) An array is a sequence of objects.
Note: Assuming we're agreeing to use this "pointer" terminology instead of
the C++ "object of array type" terminology.
> Arrays may be indexed, which results in a single element. (Let's not get
> into multi-dimension issues for the moment; just one dimension.) An array
> defines the number of elements it comprises, starting at element #0 and
> continuing to n-1 elements.
>
> Does that sound good?
>
> If so - let's continue with this example:
>
> int arr[5];
>
> If we agree on the basic definition, then this would indicate that,
> somewhere at runtime, there is a contiguous set of 5 'int' elements.
> The name of that contigous set of elements is 'arr'.
>
> Does that sound good?
No because arr is the name of a pointer object that points to the array of 5
ints.
You could consider it the name of the array of integer objects , ofc, but I
dont think it is suitable to ignore that pointer object named arr as this
seems to be what the discussion is all about.
>
>
> So - then, expanding further... using our definition above, let's
> consider this snippet:
Well I didnt agree with your definition above :)
>
> int i;
> int arr[5];
>
> i = arr[4];
>
> What are the basic semantics of that? I propose that would mean
> to find the location of the array name 'arr', treat this as a pointer to
> the first element of the array (per the rule), add to that starting
> address 4*sizeof(int), to compute the address of the 4th element.
> Dereference that point to access the `int' value located there,
> then assign that `int' value to the variable 'i'.
>
> Does that sound good/proper... is there something not right there?
> (albeit, perhaps I'm a little loose, but I'm avoiding specifics like
> 'registers' and 'memory'.)
>
> Now, let's consider this snippet:
>
> int i;
> int arr[5];
>
> i = *((&arr[0]) + 4);
>
> What does that statement do?
>
> Following the indexing example we just walked thru, I propose
> that it would mean, find the address of 'arr', treat it as a pointer to
> the first element (per the rule), add 0*sizeof(int) to that pointer
> to compute the address of the 0th element. Apply the '&' operator
> which results in that same address. At this point, we have an (int *)
> pointer to the 0th element. Add 4*sizeof(int) to it; which happens to
> produce a pointer to the 4th element of the array. Apply the '*' operator
> to dereference that point, which produces an `int' that is the 4th
> element of the array. Assign that value to `i'.
>
> Does that sound right?
>
> I believe that would show, in this basic situation; the equivalence
> of the two statements.
>
> If you agree with that; then we have a very simple answer to this
> statement:
>
>
>>
>>
>> output arr and you will find it has a pointer value.
>
>
> Yes! That is true (again, neglecting templates and other more
> complicated
> type situations.) I think, the reason it is true is because the
> expression 'arr'
> becomes a pointer to the first element of the array... hence, it,
> definitionally
> is a pointer value.
>
>> examine arr with typeid and you will find it is an array type.
>
>
> OK - at this point - let's bring typeid back into the picture.
>
> You are correct; it _is_ an array type... so - why does typeid() not say
> it's a pointer??? I just got thru explaining why it would be a pointer,
> but typeid() says it's not! What's going on?
>
> This is because of the semantics of typeid(). My statements/rationing
> above was discussing accessing the array... not examining its type.
> typeid() only looks at the type... the type of 'arr' is the contigous
> set
> of 5 elements... recall that typeid() doesn't evaluate the expression, it
> evaluates the type of the expression... it's an important distinction.
>
>> examine with sizeof and you get the size of the whole array
>
>
> The reason for this is the same as typeid(), sizeof() deals in the type
> of the expression - it does not evaluate it.
>
>> arr is a non modifiable object that decays in a pointer. The pointer
>> value(the address of the array) is stored someplace so that when the
>> program is exectued the location of an element can be accessed for
>> example:
>
>
> I'm not sure about the 'non-modifiable' part of that...
>
> Clearly though, when you say "the pointer value.. is stored someplace"...
> that is
> frequently true... in this example:
>
>>
>>
>> void foo(int* p){
>> p[2] = 6;
>> }
>>
>
> If foo() were invoked with 'arr' as a parameter; then the address of 'arr'
> must
> be stored somewhere... it's clearly stored in 'p'.
>
> However, I believe the question really is "is it stored somewhere else?"
> That is,
> is there another "object" that contains the address of 'arr'.. and the
> value
> of the other object would be passed to foo()?
>
> I think the answer is "well, you _could_ do it that way - but - it's
> frequently
> not needed."
>
> Let's consider this for example:
>
> int *ip;
> int arr[5];
>
> ip = arr;
> foo(ip);
>
> Would you say that would be equivalent to:
>
> int arr[5];
>
> foo(arr);
>
> If so, then in the first case, clearly the pointer to the first element of
> `arr'
> has been saved in the "object" named `ip'. That value is then passed
> as a parameter to foo().
>
> In the second case, is there some mysterious unnamed "object" which
> contains the address of the first element of `arr', and the value
> of the unnamed "object" is then passed as a parameter to foo()?
>
> Well - as an implementation detail; you _could_ do that... but it is more
> likely that the compiler can generate code that computes the address
> of `arr' and simply passes that computed value as the parameter to foo()?
>
> Thus, if my assertion is correct the expression:
>
> foo(arr)
>
> actually can be thought to be equivalent to
>
> foo((&arr[0]))
>
> (again, neglecting templates/function-overloading, etc... let's keep it
> simple.)
>
> The second expression simply makes the underlying semantics obvious.
>
>
>
>>
>>>
>>> In that sense; the hardware register is the container that the generated
>>> code employs to implement the expression... but, there's not a C++
>>> "object"
>>> for it... it's just how the expression is compiled.
>>>
>> Got nothing to do with hardware registers really. Its more to do with
>> terminology and peoples understanding.
>
>
> You are correct - I was using 'registers' as a term that I was hoping
> would
> make things clear; I hope the discussion above (which avoids that) is
> more
> in-line with what you are looking for.
>
>> A non modifiable object of array type, is not the same thing as an array
>> of integer objects that this object references.
>
> I'm having problems with this sentence.. when you say "A non modifiable
> object
> of array type"; do you mean a `const' array ? I'm not sure I understand
> what you're
> getting at there...
>
> Are you saying there exists this unnamed "object" that contains the
> pointer to
> array?
No arr is a pointer to the array.
But as I explained above , in C++ it is not simple pointer it is a non
modifiable pointer with additional type info. This is an object of array
type.
>
>> Although an array is not a pointer in C++. For the sake of this
>> discussion an array can be seen as basically a pointer to the first
>> element because in most situations it decays into a pointer.
>
>
> I think this is an oversimplication; as you point out above... If we
> agree
> that an array is a contiguous set of elements, then that's what it is...
>
> We then say that there is this added rule that when the array name is
> referenced
> in an expression, the result of that expression is a pointer to the first
> element...
>
> With those two, one can readily define the []-operator in a consistent
> fashion
> vis-a-vis pointer addition.
>
> That is (and, again, this is neglecting templates/function-overloading,
> etc...)
> given these declarations:
>
> int i;
> int arr[5];
>
> the statements:
>
> i = arr[4];
>
> and
>
> i = *((&arr[0])+4);
>
> are completely equivalent.
>
> If we can agree on those definitions and these basic semantics, then we
> can
> proceed to talk about the slightly-more-complicated issues, in particular,
> how do you handle multiple dimensions, and what does "&arr" mean?
>
> However, one step at a time.
>
> - Dave Rivers -
>
Some things I agree with you and others I do not, If we can aggree to
consider arr as a pointer and ignore all the typeinfo then thats ok , but
you must also agree with me that arr is a pointer object under the hood and
not simply a name for the array of integer objects.
[toc] | [prev] | [next] | [standalone]
| From | Thomas David Rivers <rivers@dignus.com> |
|---|---|
| Date | 2011-05-25 20:02 -0400 |
| Message-ID | <4DDD9893.9060502@dignus.com> |
| In reply to | #5523 |
Paul wrote:
>
> "Thomas David Rivers" <rivers@dignus.com> wrote in message
> news:4DDD34A8.6030005@dignus.com...
>
>> Paul wrote:
>>
>>>
>>> An array object is not the same as a single variable.
>>
>>
>>
>> Well - this is likely a mistake.. but....
>>
>>
>>
>> So - to begin with some basic principles; let's remove the complications
>> of templates, function overloading, etc... and let's just talk
>> about some really simple/straight-forward examples and how things
>> actually work "under the covers" for those simple situations.
>>
> So basically you want to consider an array as a simple pointer.
No - not at all - I provided my suggested definition of the term 'array'.
Basically, in that, an 'array' is a contiguous set of elements with
a defined length, where each element can be accessed individually.
>
>>>
>>> An array is a sequence of objects that cannot be addressed with a
>>> single instruction, unless its size one or soemthing silly.
>>> An object of array type is an object that strores the pointer to the
>>> array , for example arr in the following:
>>>
>>> int arr[5];
>>
>>
>>
>> Hmm... those sound like nice definitions... but, I think I would prefer
>> some simpler ones. I'm terribly confused by this "object of array
>> type"
>> you have there, and why you would need one...
>
>
> Hold on lets clear this confusion up.
> In asm an array is basically a pointer, in C++ its an object of array
> type (which I see as a non modifiable pointer with added typeinfo).
Actually, in 'asm' - an array is a contiguous set of elements of the
same type.
The concept does not change because the implementation language changes.
The array remains a contiguous set of elements of the same type.
Certainly, in 'asm', it might be convenient to have a pointer to that
allocated memory,
but the array is still the entire set of elements. Nothing more,
nothing less.
That is, a pointer is a pointer, an array is an array.
In C/C++, there is not this 'object of array type' you mention, there
is the idea
of an 'array'. An array is simply a contiguous set of elements of the same
type, each element can be accessed. When the array is allocated, all
of the
memory required for the entire set is allocated. When the array is
deallocated,
the entire array "goes away".
Let's just back up and start with that simple idea; then we can proceed
from there and build up the ideas of accessing the array and/or accessing
elements of the array.
So - to reiterate...
An array is simply a contigous set of like-typed elements.
How does that sound for a start?
I've added some more comments below - just to clarify a little. However,
we really need to agree on this definition... then, I think we can build
up from there and hopefully clarify this a little.
>
> So according to C++ with the deifnition:
> int arr[5];
>
> The object arr is not a pointer , it is a non modifiable object of
> array type.
> If you want to forget about all the typeinfo etc and simply regard
> this as a pointer for the sake of the dscussion I can go with that.
>
No, I don't think so.. the object 'arr' is not a pointer - it is a
contiguous
set of 5 elements of type 'int'.
Note that I keep using the word 'element'... arrays have elements (just
like
structures have members, for instance.) This will be important later.
>
>
>>
>> So - let me offer these...
>>
>> Let's say that an array is a contiguous sequence of elements.
>
>
> Aha now you are shifting the focus, to the actual objects of the
> array. Lets be clear about these two definintions of array.
> We have an array of 5 ints like so:
> [int][int][int][int][int]
>
> To access this array we need to have a pointer so we have:
> [ptr_arr]...................[int][int][int][int][int]
Actually - if you will follow along with me and we can agree on some
really basic ideas, then it will just so happen that multi-dimensional
arrays "just work", without these other pointers you are suggestion.
Because of that, I'd like to defer the discussion of multi-dimensional
arrays until we can get to the basic understanding of C/C++ simple
arrays. If you don't mind...
>
> The term array can be applied to a contiguous sequence of integer
> objects or to the identifier(pointer) for these objects.
Actually - that's not what I provided in my definition. The term
'array' simply
means the entire set of the contiguous elements; nothing more, nothing less.
It's important to understand that there is no separate pointer to the
objects,
there is simply the entire set of objects.
There is a context in which a reference to the entire set of objects is
converted
to a pointer to the first element... but that is different. It is not a
separate object
that contains the address.
That might be a good idea, and I mention at least one other language that
does take that approach below.. but, it's simply not how C/C++ is defined.
> Going back to the old arr , arr is a pointer object that points to the
> sequence of integer objects. This is a different object from any of
> the five integer objects
> 1) An array is a pointer such as arr.
> 2) An array is a sequence of objects.
> Note: Assuming we're agreeing to use this "pointer" terminology
> instead of the C++ "object of array type" terminology.
I don't think so... an array is not a pointer. An array is a contiguous
set of elements
of the same type. In some situations, references to this set are
converted to
the address of the first element of the set.
That really is all there is to it.
>
>
>> Arrays may be indexed, which results in a single element. (Let's not
>> get
>> into multi-dimension issues for the moment; just one dimension.) An
>> array
>> defines the number of elements it comprises, starting at element #0 and
>> continuing to n-1 elements.
>>
>> Does that sound good?
>>
>> If so - let's continue with this example:
>>
>> int arr[5];
>>
>> If we agree on the basic definition, then this would indicate that,
>> somewhere at runtime, there is a contiguous set of 5 'int' elements.
>> The name of that contigous set of elements is 'arr'.
>>
>> Does that sound good?
>
>
> No because arr is the name of a pointer object that points to the
> array of 5 ints.
Actually - no, 'arr' is the name of the start of the contiguous set of 5
int elements.
That's all 'arr' is - nothing more, nothing less. However, in some
situations, the reference
to the set of elements is converted to the address of the first element.
'arr' is not a pointer to another location. It is the actual location
of the 5 ints.
>
> You could consider it the name of the array of integer objects , ofc,
> but I dont think it is suitable to ignore that pointer object named
> arr as this seems to be what the discussion is all about.
I was trying to get to the idea that there is no "pointer object named
arr". There
actually is not one of those.
'arr' is the name of the contiguous set of 5 int elements.
It is not a pointer to the 5 int elements; it actually is the 5 int
elements.
When you use the name 'arr' in expression contexts where the value is
required,
the 'decay' as you put it occurs, and the result of that expression is a
pointer
to the first element of the array.
This is the subtle point...
Thus, in the snippet:
int *ip;
int arr[5];
ip = arr;
what happens semantically? In this statement above, the name 'arr' is used
in an expression that requires its value. In that case, the semantics
indicate
that the result of the expression would be the address of the first element.
Thus; these two statements are completely, totally, and utterly (in the
context of the declarations above) identical:
ip = arr;
ip = (&arr[0]);
They are identical in every aspect; because of the rule that an array name
used in an expression context is treated as the address of the first
element.
This is the definition of C/C++. This is really how it works. There
is not other
'magic' behind it.. no other objects-pointing-to-objects or anything else.
That's all there is to this... nothing more... There does not exist a
separate
object that points to the 5 bytes...
Unfortunately - this is not a matter to be debated. This just happens to be
the way C and C++ are defined. Other languages (e.g. PL/I) use approaches
similar to what you are considering.. it's called a "dope vector" and can be
very helpful.. but, that's not how C and C++ are defined.
Again, there is not a "pointer object" that points to the array; there is
only the array. And, an array is not a pointer... however, in some
situations,
the name of the array does not indicate the array in-total, but refers to
the address of the first element.
I'm afraid that's not really open to discussion - it simply is true by
definition.
It really, actually, truly is the way it works and the way its defined.
Now - I realize others have tried to explain this - I was hoping to add
clarification
to that. Starting with some really basic definitions and "working up"
from there.
But - we have to agree that an array is the contiguous set of elements
of the
same type. That there is nothing more to it.
If it is something about which you disagree, then I'll have give up on
the tutorial.
Which would be a shame, because it's really kinda cool how it all works out.
- Dave Rivers -
--
rivers@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-26 01:37 +0100 |
| Message-ID | <ghhDp.11778$f95.7720@newsfe02.ams2> |
| In reply to | #5567 |
"Thomas David Rivers" <rivers@dignus.com> wrote in message news:4DDD9893.9060502@dignus.com... > Paul wrote: > >> >> "Thomas David Rivers" <rivers@dignus.com> wrote in message >> news:4DDD34A8.6030005@dignus.com... >> >>> Paul wrote: >>> >>>> >>>> An array object is not the same as a single variable. >>> >>> >>> >>> Well - this is likely a mistake.. but.... >>> >>> >>> >>> So - to begin with some basic principles; let's remove the complications >>> of templates, function overloading, etc... and let's just talk >>> about some really simple/straight-forward examples and how things >>> actually work "under the covers" for those simple situations. >>> >> So basically you want to consider an array as a simple pointer. > > > No - not at all - I provided my suggested definition of the term 'array'. > > Basically, in that, an 'array' is a contiguous set of elements with > a defined length, where each element can be accessed individually. > Oh right I though I was aggreing with you on your terms but it seems that whether I discuss an array in one context you will discuss it in another context. I think and array is a contiguious sequence of elements but I can also accept that an array identifier is called an array and that idntifier is a non modifiable object. If I talk about an array in the context of an indentifier or in the context of a sequence of objects you will change the correct and say I am wrong. An array is a contiguous sequence of objects and nothing more. So no point in going any further . <snip>
[toc] | [prev] | [next] | [standalone]
Page 7 of 21 — ← Prev page 1 … 5 6 [7] 8 9 … 21 Next page →
Back to top | Article view | comp.lang.c++
csiph-web