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 8 of 21 — ← Prev page 1 … 6 7 [8] 9 10 … 21 Next page →
| From | Thomas David Rivers <rivers@dignus.com> |
|---|---|
| Date | 2011-05-26 09:08 -0400 |
| Message-ID | <4DDE50C0.1080402@dignus.com> |
| In reply to | #5573 |
Paul wrote: > 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 an array is a contiguous sequence of elements but I can also > accept that an array identifier is called an array and that identifier > 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 . OK! We've got a point of agreement.. Would you say that we both agree that an array is a contiguous set of elements of the same type ; and that these elements can be accessed via the indexing operator-[] ? And, that there is nothing more to it? (I want to drop this 'non-modifiable object' idea for the time being, we can come back to that... and, we can later discover just why it's "non-modifiable"... but, one thing at a time...) If you can agree with that, then we can proceed to learn about how this all works... it's really kinda neat. We can really build from this basic understanding. And, I think you might find that it will all become much more clear. So - do we agree that an array is a contigous set of like-typed elements, where the elements are accessed via the []-operator? - 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 15:19 +0100 |
| Message-ID | <8ktDp.17767$h35.800@newsfe19.ams2> |
| In reply to | #5616 |
"Thomas David Rivers" <rivers@dignus.com> wrote in message news:4DDE50C0.1080402@dignus.com... > Paul wrote: > >> 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 an array is a contiguous sequence of elements but I can also >> accept that an array identifier is called an array and that identifier 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 . > > > OK! We've got a point of agreement.. > > Would you say that we both agree that an array is a contiguous set of > elements of the same type ; and that these elements can be accessed > via the indexing operator-[] ? > > And, that there is nothing more to it? > > (I want to drop this 'non-modifiable object' idea for the time being, > we can come back to that... and, we can later discover just why > it's "non-modifiable"... but, one thing at a time...) > > If you can agree with that, then we can proceed to learn about how > this all works... it's really kinda neat. We can really build from this > basic understanding. And, I think you might find that it will all become > much more clear. > > So - do we agree that an array is a contigous set of like-typed elements, > where the elements are accessed via the []-operator? > Yes I aggree with that.
[toc] | [prev] | [next] | [standalone]
| From | Thomas David Rivers <rivers@dignus.com> |
|---|---|
| Date | 2011-05-26 14:45 -0400 |
| Message-ID | <4DDE9FCD.9050005@dignus.com> |
| In reply to | #5619 |
Paul wrote:
>
>>
>> So - do we agree that an array is a contigous set of like-typed
>> elements,
>> where the elements are accessed via the []-operator?
>>
> Yes I aggree with that.
>
So - next let's examine a rather simple declaration of an array in C/C++.
int arr[5];
What does this define.
This defines a contiguous set of 5 `int' elements. The name of that set
is 'arr'.
What is the type of 'arr'? It is an array of 5 'int' elements.
What is 'arr'?
'arr' represents, at execution time, a set of 5 contigous 'int'
elements. The name 'arr'
is used to refer to the runtime location of that set of elements. We
can colloquially
use the term, the "address" of the set of 5 contiguous 'int' elements
when we talk
about the runtime location of the set of 5 contiguous 'int' elements.
That is, the name 'arr' refers to the runtime location (or "address") of
the set
of 5 contiguous 'int' elements.
Does that sound right so far?
- 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 21:02 +0100 |
| Message-ID | <rlyDp.14214$Ky.5147@newsfe24.ams2> |
| In reply to | #5641 |
"Thomas David Rivers" <rivers@dignus.com> wrote in message news:4DDE9FCD.9050005@dignus.com... > Paul wrote: > >> >>> >>> So - do we agree that an array is a contigous set of like-typed >>> elements, >>> where the elements are accessed via the []-operator? >>> >> Yes I aggree with that. >> > > So - next let's examine a rather simple declaration of an array in C/C++. > > int arr[5]; No do a dynamic array like so: int* arr = new int[5]; Then there is no confusion about array objects, an array is simply the region of memory storing the integer objects and nothing more. Having read ahead you seem to be slowly introducing this "arr" object into the equation without first aggreeing on a definition of what exactly "arr" is. And that is what was the original argument. In the above example of a dynamic array there is no confusion that "arr" is a pointer. > > What does this define. > > This defines a contiguous set of 5 `int' elements. The name of that set > is 'arr'. > What is the type of 'arr'? It is an array of 5 'int' elements. > > What is 'arr'? > 'arr' represents, at execution time, a set of 5 contigous 'int' elements. > The name 'arr' > is used to refer to the runtime location of that set of elements. We can > colloquially > use the term, the "address" of the set of 5 contiguous 'int' elements when > we talk > about the runtime location of the set of 5 contiguous 'int' elements. > > That is, the name 'arr' refers to the runtime location (or "address") of > the set > of 5 contiguous 'int' elements. > > Does that sound right so far? >
[toc] | [prev] | [next] | [standalone]
| From | Thomas David Rivers <rivers@dignus.com> |
|---|---|
| Date | 2011-05-27 09:34 -0400 |
| Message-ID | <4DDFA87C.9060808@dignus.com> |
| In reply to | #5644 |
Paul wrote: > > "Thomas David Rivers" <rivers@dignus.com> wrote in message > news:4DDE9FCD.9050005@dignus.com... > >> Paul wrote: >> >>> >>>> >>>> So - do we agree that an array is a contigous set of like-typed >>>> elements, >>>> where the elements are accessed via the []-operator? >>>> >>> Yes I aggree with that. >>> >> >> So - next let's examine a rather simple declaration of an array in >> C/C++. >> >> int arr[5]; > > > No do a dynamic array like so: > int* arr = new int[5]; > > Then there is no confusion about array objects, an array is simply the > region of memory storing the integer objects and nothing more. > > Having read ahead you seem to be slowly introducing this "arr" object > into the equation without first aggreeing on a definition of what > exactly "arr" is. And that is what was the original argument. > > In the above example of a dynamic array there is no confusion that > "arr" is a pointer. > > You are correct - what you have declared there is a pointer to an integer, (the `int *arr' portion), and that pointer is initialized with some dynamically allocated space (the `new' portion.) The dynamically allocated space is a contiguous set of 5 'int' elements (the `int[5]' portion.) The pointer's name is 'arr'. That's all well and good, but it is very different from what I was talking about. What I'd like to focus on is this simple declaration: int arr[5]; Can we agree that the declaration of int arr[5]; represents, at runtime, a set of 5 contiguous 'int' elements. The name of the set of 5 contiguous elements it 'arr'. The name 'arr' refers to the runtime location of the set of 5 contiguous elements. If we can, I'd like to restrict the conversation to just that for the moment... we can get to the other stuff soon enough... but, one thing at a time. Does that sound like a good starting place? - 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-27 14:46 +0100 |
| Message-ID | <mXNDp.33897$IL2.20921@newsfe04.ams2> |
| In reply to | #5692 |
"Thomas David Rivers" <rivers@dignus.com> wrote in message news:4DDFA87C.9060808@dignus.com... > Paul wrote: > >> >> "Thomas David Rivers" <rivers@dignus.com> wrote in message >> news:4DDE9FCD.9050005@dignus.com... >> >>> Paul wrote: >>> >>>> >>>>> >>>>> So - do we agree that an array is a contigous set of like-typed >>>>> elements, >>>>> where the elements are accessed via the []-operator? >>>>> >>>> Yes I aggree with that. >>>> >>> >>> So - next let's examine a rather simple declaration of an array in >>> C/C++. >>> >>> int arr[5]; >> >> >> No do a dynamic array like so: >> int* arr = new int[5]; >> >> Then there is no confusion about array objects, an array is simply the >> region of memory storing the integer objects and nothing more. >> >> Having read ahead you seem to be slowly introducing this "arr" object >> into the equation without first aggreeing on a definition of what exactly >> "arr" is. And that is what was the original argument. >> >> In the above example of a dynamic array there is no confusion that "arr" >> is a pointer. >> >> > > You are correct - what you have declared there is a pointer to an integer, > (the `int *arr' portion), and that pointer is initialized with some > dynamically > allocated space (the `new' portion.) The dynamically allocated space is > a > contiguous set of 5 'int' elements (the `int[5]' portion.) The pointer's > name is 'arr'. > > That's all well and good, but it is very different from what I was talking > about. > > What I'd like to focus on is this simple declaration: > > int arr[5]; > > Can we agree that the declaration of > > int arr[5]; > > represents, at runtime, a set of 5 contiguous 'int' elements. The > name of the set of 5 contiguous elements it 'arr'. The name 'arr' > refers to the runtime location of the set of 5 contiguous elements. > > If we can, I'd like to restrict the conversation to just that for the > moment... we can get to the other stuff soon enough... but, one > thing at a time. > Yes I agree with this, but before we can proceed any further we need to agree on what exactly "arr" is. You are calling it a name that refers to the contiguous sequence of elements here. I would like to establish just what exactly it is because it seems to store a memory address as can be show with: int arr[5]; int* p = arr; So lets try to agree about what exactly arr is. As you know I have been calling it an array type object.
[toc] | [prev] | [next] | [standalone]
| From | Thomas David Rivers <rivers@dignus.com> |
|---|---|
| Date | 2011-05-27 15:07 -0400 |
| Message-ID | <4DDFF65B.8010007@dignus.com> |
| In reply to | #5694 |
Paul wrote:
>
> "Thomas David Rivers" <rivers@dignus.com> wrote in message
> news:4DDFA87C.9060808@dignus.com...
>
>> Paul wrote:
>>
>>>
>>> "Thomas David Rivers" <rivers@dignus.com> wrote in message
>>> news:4DDE9FCD.9050005@dignus.com...
>>>
>>>> Paul wrote:
>>>>
>>>>>
>>>>>>
>>>>>> So - do we agree that an array is a contigous set of like-typed
>>>>>> elements,
>>>>>> where the elements are accessed via the []-operator?
>>>>>>
>>>>> Yes I aggree with that.
>>>>>
>>>>
>>>> So - next let's examine a rather simple declaration of an array in
>>>> C/C++.
>>>>
>>>> int arr[5];
>>>
>>>
>>>
>>> No do a dynamic array like so:
>>> int* arr = new int[5];
>>>
>>> Then there is no confusion about array objects, an array is simply
>>> the region of memory storing the integer objects and nothing more.
>>>
>>> Having read ahead you seem to be slowly introducing this "arr"
>>> object into the equation without first aggreeing on a definition of
>>> what exactly "arr" is. And that is what was the original argument.
>>>
>>> In the above example of a dynamic array there is no confusion that
>>> "arr" is a pointer.
>>>
>>>
>>
>> You are correct - what you have declared there is a pointer to an
>> integer,
>> (the `int *arr' portion), and that pointer is initialized with some
>> dynamically
>> allocated space (the `new' portion.) The dynamically allocated
>> space is a
>> contiguous set of 5 'int' elements (the `int[5]' portion.) The
>> pointer's name is 'arr'.
>>
>> That's all well and good, but it is very different from what I was
>> talking about.
>>
>> What I'd like to focus on is this simple declaration:
>>
>> int arr[5];
>>
>> Can we agree that the declaration of
>>
>> int arr[5];
>>
>> represents, at runtime, a set of 5 contiguous 'int' elements. The
>> name of the set of 5 contiguous elements it 'arr'. The name 'arr'
>> refers to the runtime location of the set of 5 contiguous elements.
>>
>> If we can, I'd like to restrict the conversation to just that for the
>> moment... we can get to the other stuff soon enough... but, one
>> thing at a time.
>>
> Yes I agree with this, but before we can proceed any further we need
> to agree on what exactly "arr" is.
> You are calling it a name that refers to the contiguous sequence of
> elements here.
> I would like to establish just what exactly it is because it seems to
> store a memory address as can be show with:
> int arr[5];
> int* p = arr;
>
> So lets try to agree about what exactly arr is.
> As you know I have been calling it an array type object.
>
>
That would basically be the next step...
However, I want to hold to the definition; 'arr' is simply the name
of the 5 contiquous int elements.
Now - let's take up the problem of assignment to a pointer...
Let's consider this snippet:
int i;
int *ip;
ip = &i;
would you agree that the semantics of that would be that
'i' is the name of an `int'. `ip' is the name of a pointer to an `int'.
The expression:
&i
denotes "the address of the `int' named `i'"
And the expression:
ip = &i;
denotes "compute the address of the `int' named 'i', store that
value into the pointer-to-`int' named `ip'."
Does that sound correct?
If so, then we can begin to look at your example involving `arr';
and - we can compare the two with considerations toward just
what it means to assign a value to the `int' pointer named `ip'.
But - one thing 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-27 21:42 +0100 |
| Message-ID | <21UDp.11231$5C7.1331@newsfe10.ams2> |
| In reply to | #5722 |
"Thomas David Rivers" <rivers@dignus.com> wrote in message news:4DDFF65B.8010007@dignus.com... > Paul wrote: >>>>> >>>>>> >>>>>>> >>>>>>> So - do we agree that an array is a contigous set of like-typed >>>>>>> elements, >>>>>>> where the elements are accessed via the []-operator? >>>>>>> >>>>>> Yes I aggree with that. >>>>>> >>>>> >>>>> So - next let's examine a rather simple declaration of an array in >>>>> C/C++. >>>>> >>>>> int arr[5]; >>>> >>>> >>>> >>>> No do a dynamic array like so: >>>> int* arr = new int[5]; >>>> >>>> Then there is no confusion about array objects, an array is simply the >>>> region of memory storing the integer objects and nothing more. >>>> >>>> Having read ahead you seem to be slowly introducing this "arr" object >>>> into the equation without first aggreeing on a definition of what >>>> exactly "arr" is. And that is what was the original argument. >>>> >>>> In the above example of a dynamic array there is no confusion that >>>> "arr" is a pointer. >>>> >>>> >>> >>> You are correct - what you have declared there is a pointer to an >>> integer, >>> (the `int *arr' portion), and that pointer is initialized with some >>> dynamically >>> allocated space (the `new' portion.) The dynamically allocated space >>> is a >>> contiguous set of 5 'int' elements (the `int[5]' portion.) The pointer's >>> name is 'arr'. >>> >>> That's all well and good, but it is very different from what I was >>> talking about. >>> >>> What I'd like to focus on is this simple declaration: >>> >>> int arr[5]; >>> >>> Can we agree that the declaration of >>> >>> int arr[5]; >>> >>> represents, at runtime, a set of 5 contiguous 'int' elements. The >>> name of the set of 5 contiguous elements it 'arr'. The name 'arr' >>> refers to the runtime location of the set of 5 contiguous elements. >>> >>> If we can, I'd like to restrict the conversation to just that for the >>> moment... we can get to the other stuff soon enough... but, one >>> thing at a time. >>> >> Yes I agree with this, but before we can proceed any further we need to >> agree on what exactly "arr" is. >> You are calling it a name that refers to the contiguous sequence of >> elements here. >> I would like to establish just what exactly it is because it seems to >> store a memory address as can be show with: >> int arr[5]; >> int* p = arr; >> >> So lets try to agree about what exactly arr is. >> As you know I have been calling it an array type object. >> >> > > That would basically be the next step... > > However, I want to hold to the definition; 'arr' is simply the name > of the 5 contiquous int elements. > > Now - let's take up the problem of assignment to a pointer... > > Let's consider this snippet: > > int i; > int *ip; > > ip = &i; > > would you agree that the semantics of that would be that > 'i' is the name of an `int'. `ip' is the name of a pointer to an `int'. > The expression: > > &i > > denotes "the address of the `int' named `i'" > > And the expression: > > ip = &i; > > denotes "compute the address of the `int' named 'i', store that > value into the pointer-to-`int' named `ip'." > > Does that sound correct? > > If so, then we can begin to look at your example involving `arr'; > and - we can compare the two with considerations toward just > what it means to assign a value to the `int' pointer named `ip'. > Yes this is agreeable. You may continue to the next step :)
[toc] | [prev] | [next] | [standalone]
| From | Thomas David Rivers <rivers@dignus.com> |
|---|---|
| Date | 2011-05-27 19:34 -0400 |
| Message-ID | <4DE03514.7080802@dignus.com> |
| In reply to | #5731 |
Paul wrote:
>
> "Thomas David Rivers" <rivers@dignus.com> wrote in message
> news:4DDFF65B.8010007@dignus.com...
>
>> Paul wrote:
>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> So - do we agree that an array is a contigous set of like-typed
>>>>>>>> elements,
>>>>>>>> where the elements are accessed via the []-operator?
>>>>>>>>
>>>>>>> Yes I aggree with that.
>>>>>>>
>>>>>>
>>>>>> So - next let's examine a rather simple declaration of an array
>>>>>> in C/C++.
>>>>>>
>>>>>> int arr[5];
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> No do a dynamic array like so:
>>>>> int* arr = new int[5];
>>>>>
>>>>> Then there is no confusion about array objects, an array is simply
>>>>> the region of memory storing the integer objects and nothing more.
>>>>>
>>>>> Having read ahead you seem to be slowly introducing this "arr"
>>>>> object into the equation without first aggreeing on a definition
>>>>> of what exactly "arr" is. And that is what was the original argument.
>>>>>
>>>>> In the above example of a dynamic array there is no confusion that
>>>>> "arr" is a pointer.
>>>>>
>>>>>
>>>>
>>>> You are correct - what you have declared there is a pointer to an
>>>> integer,
>>>> (the `int *arr' portion), and that pointer is initialized with
>>>> some dynamically
>>>> allocated space (the `new' portion.) The dynamically allocated
>>>> space is a
>>>> contiguous set of 5 'int' elements (the `int[5]' portion.) The
>>>> pointer's name is 'arr'.
>>>>
>>>> That's all well and good, but it is very different from what I was
>>>> talking about.
>>>>
>>>> What I'd like to focus on is this simple declaration:
>>>>
>>>> int arr[5];
>>>>
>>>> Can we agree that the declaration of
>>>>
>>>> int arr[5];
>>>>
>>>> represents, at runtime, a set of 5 contiguous 'int' elements. The
>>>> name of the set of 5 contiguous elements it 'arr'. The name 'arr'
>>>> refers to the runtime location of the set of 5 contiguous elements.
>>>>
>>>> If we can, I'd like to restrict the conversation to just that for the
>>>> moment... we can get to the other stuff soon enough... but, one
>>>> thing at a time.
>>>>
>>> Yes I agree with this, but before we can proceed any further we need
>>> to agree on what exactly "arr" is.
>>> You are calling it a name that refers to the contiguous sequence of
>>> elements here.
>>> I would like to establish just what exactly it is because it seems
>>> to store a memory address as can be show with:
>>> int arr[5];
>>> int* p = arr;
>>>
>>> So lets try to agree about what exactly arr is.
>>> As you know I have been calling it an array type object.
>>>
>>>
>>
>> That would basically be the next step...
>>
>> However, I want to hold to the definition; 'arr' is simply the name
>> of the 5 contiquous int elements.
>>
>> Now - let's take up the problem of assignment to a pointer...
>>
>> Let's consider this snippet:
>>
>> int i;
>> int *ip;
>>
>> ip = &i;
>>
>> would you agree that the semantics of that would be that
>> 'i' is the name of an `int'. `ip' is the name of a pointer to an `int'.
>> The expression:
>>
>> &i
>>
>> denotes "the address of the `int' named `i'"
>>
>> And the expression:
>>
>> ip = &i;
>>
>> denotes "compute the address of the `int' named 'i', store that
>> value into the pointer-to-`int' named `ip'."
>>
>> Does that sound correct?
>>
>> If so, then we can begin to look at your example involving `arr';
>> and - we can compare the two with considerations toward just
>> what it means to assign a value to the `int' pointer named `ip'.
>>
> Yes this is agreeable. You may continue to the next step :)
>
OK - let's review - so we know we're on the same page:
int arr[5];
'arr' is the name of the set of 5 contiguous `int'-typed elements.
int *ip;
`ip' is the name of a variable that can contain the address of an `int',
it is a "pointer to int".
And:
int i;
`i' is the name of an `int'-tpe variable.
The expression:
ip=&i;
computes the address of `i', and places that value into the variable
`ip'.
This is what we've agreed to thus far... right?
This establishes that `ip' is not the same type as `arr'.
`arr' is the contiguous set of 5 `int' elements, `ip' can contain
the address of an `int', it can "point to" an `int'.
There is nothing new in that statement; it is a re-statement
of the preceeding items we've agreed to (in that `arr' is the
set, `ip' is a single pointer.)
Now - in a programming language like C/C++, typically the
language might enforce rules regarding assignent. One such
rule is that assignments can only be made from a value of the
destination type, and that if the types are not the same, then
some mechanism is employed to convert from oen type to another
(if possible).
As an example:
double d;
int i;
d = i;
The variable `i' is an `int'; `d' is a `double'. You might decide,
in a programming language, that such an assignment not be
allowed - but it is in C/C++ because the `int' value contained
in `i' will be, at runtime, converted to a `double' and then
stored in the variable `d'.
In this instance, would you say there was a "magic"/secret object
of type `double' that was created along with `i' to contain the
converted result before assigning the value to `d'? Or, would
you say that the conversion simply occurs as a matter-of-course?
I think, most people would say that the compiler generates code
which effects the conversion at runtime, so that `i' is, at runtime,
converted to a double, and the temporary value that results from
that conversion is stored in `d'.
But; this is a well-defined conversion... does the C/C++ language
definition provide any such mechanism for this snippet:
int *ip;
int arr[5];
ip = arr;
Given the definitions (to which we've all agreed), `ip' is a pointer
to an `int', and `arr' is a contigous set of 5 `int' elements. How could
those two types be reconciled to allow this assignment???
What is going on here??
As it so happens, the designers of C (and, by extension, C++) considered
this problem, and provide a mechanism by which such an assignment
is accomplished.
This mechanism has been written down in the various standard documents,
so that everyone can read it and truly understand what is meant by
that assignment.
First - recall, as you have agreed, that arr' is an array of 5 `int'
elements.
(we clearly cannot assign 5 `int' elements in-toto to a pointer to a
single `int',
in a reasonable type-system, at least.)
So - given that `arr' is an array, I will quote from the C standard,
which might
be a little more clear than the C++ one (simply for this discussion, the C++
definition is similar):
Section 6.3.2.1 Lvalues, arrays, and function designators
Paragraph #1:
An lvalue is an expression with an object type or an incomplete
type other than void.
(that is, `arr' is an "lvalue", it is an "lvalue" with an object type
of int[5].
An "lvalue" in C is basically what can appear on the left-hand-side of the
assignment operator, the opposing "rvalue" appears on the right-hand-side.
That is, you assign the rvalue to the lvalue. In this case, `arr' is
an lvalue,
until you get to the next step.)
Paragraph #3:
Except when it is the operand of the sizeof operator or the unary &
operator, or is a string literal used to initialize an array, an
expression
that has type "array of type" is converted to an expression
"pointer to type"
that points to the initial element of the array object and it is
not an lvalue.
In this example, `arr' is not the operand of sizeof(), nor the unary &,
an it
is not a string literal to initialize an array. Thus, the conversion
applies.
So... what do we have in this:
int *ip;
int arr[5];
ip = arr;
Let's take the expression 'arr', which is the value being assigned.
According to the rules, it is an "lvalue".. it's type (as we agreed) is
an array of 5 int elements. When such an expression is used, the
language definition indicates that it should be converted to an
expression that is a pointer to the element type. The value
of that expression is a pointer to the first element. After that,
the expression is no longer an "lvalue" (it can't be assigned to,
hence it is not `modifiable'). [As an aside, the effect of not being
an "lvalue" is that it can't appear on the left-hand-side of the assignment
operator, thus you cannot have: arr = <something>; because 'arr'
would be converted to the non-lvalue expression.]
So, following that logic; the semantics of the expression `arr',
are completely the same as if this was this expression:
ip = (&arr[0]);
Do you not agree that the expression "&arr[0]" is the address of
the first element of `arr'?
Clearly the type of "&arr[0]" (the address of the first `int' element
of `arr') is the address of a single `int'.
Thus, the assignment is valid, and the program is valid.
Now. did the C/C++ language definition provide a separate object to compute
"&arr[0]"?
I believe, we agreed before that there was no separate object
in this snippet:
int *ip;
int i;
ip = &i;
I recall we both agreed that the semantics of that were that the
address of `i' was computed, and that value was placed in `ip'.
Similarly, this snippet:
int *ip;
int arr[5];
ip = (&arr[0]);
would simply compute the address of the first (0th) element of `arr'
and place that value in `ip'. There would be no separate object
required to be a pointer to the array... there is simply the array
and the fact that we can compute its address when needed.
And, because of the rule I cited above, this snippet:
int *ip;
int arr[5];
ip = arr;
is equivalent to the previous one (in that `arr' is an lvalue expression of
an array type, and it is therefor converted to a pointer to the array's
first element.)
So, you see, there is no separate "object" of any kind defined by the
language,
nor required in the implementation. It's simply a matter of following
the rules
set out in the C/C++ definition.
If you agree with all of this, then I'd like to discuss how the
[]-operator (indexing)
is defined... it simply "falls out" from this very simple approach.
And, it
is frequently why people confuse pointers-and-arrays.
To recap:
1) An array is a contigous set of same-typed elements.
2) A pointer to a variable that contains an address.
3) A pointer is not an array, an array is not a pointer.
4) The C/C++ languages provide for situations where implicit
conversions occur.
5) One such situation is that when an expression is an lvalue,
and the type of that expression is an array; the expression
is converted to an expression that is a pointer to the first
element of the array.
So - you see - it's really rather simple, no actual "magic" behind
this at all.. no magic 'array type object' or anything like that.
Just some basic definitions on which to build...
If you agre with all of this, then, as I mentioned above, I'd like to
explore how the indexing operator [] works; especially its relationship
to pointer arithmetic. And, we should explore the caveats mentioned
in the conversion rule (particularly, the & operator when applied to
an expression of array type.)
- 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-28 01:24 +0100 |
| Message-ID | <bhXDp.17713$8A7.15190@newsfe12.ams2> |
| In reply to | #5740 |
"Thomas David Rivers" <rivers@dignus.com> wrote in message news:4DE03514.7080802@dignus.com... > Paul wrote: > >> >> "Thomas David Rivers" <rivers@dignus.com> wrote in message >> news:4DDFF65B.8010007@dignus.com... >> >>> Paul wrote: >>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> So - do we agree that an array is a contigous set of like-typed >>>>>>>>> elements, >>>>>>>>> where the elements are accessed via the []-operator? >>>>>>>>> >>>>>>>> Yes I aggree with that. >>>>>>>> >>>>>>> >>>>>>> So - next let's examine a rather simple declaration of an array in >>>>>>> C/C++. >>>>>>> >>>>>>> int arr[5]; >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> No do a dynamic array like so: >>>>>> int* arr = new int[5]; >>>>>> >>>>>> Then there is no confusion about array objects, an array is simply >>>>>> the region of memory storing the integer objects and nothing more. >>>>>> >>>>>> Having read ahead you seem to be slowly introducing this "arr" object >>>>>> into the equation without first aggreeing on a definition of what >>>>>> exactly "arr" is. And that is what was the original argument. >>>>>> >>>>>> In the above example of a dynamic array there is no confusion that >>>>>> "arr" is a pointer. >>>>>> >>>>>> >>>>> >>>>> You are correct - what you have declared there is a pointer to an >>>>> integer, >>>>> (the `int *arr' portion), and that pointer is initialized with some >>>>> dynamically >>>>> allocated space (the `new' portion.) The dynamically allocated space >>>>> is a >>>>> contiguous set of 5 'int' elements (the `int[5]' portion.) The >>>>> pointer's name is 'arr'. >>>>> >>>>> That's all well and good, but it is very different from what I was >>>>> talking about. >>>>> >>>>> What I'd like to focus on is this simple declaration: >>>>> >>>>> int arr[5]; >>>>> >>>>> Can we agree that the declaration of >>>>> >>>>> int arr[5]; >>>>> >>>>> represents, at runtime, a set of 5 contiguous 'int' elements. The >>>>> name of the set of 5 contiguous elements it 'arr'. The name 'arr' >>>>> refers to the runtime location of the set of 5 contiguous elements. >>>>> >>>>> If we can, I'd like to restrict the conversation to just that for the >>>>> moment... we can get to the other stuff soon enough... but, one >>>>> thing at a time. >>>>> >>>> Yes I agree with this, but before we can proceed any further we need to >>>> agree on what exactly "arr" is. >>>> You are calling it a name that refers to the contiguous sequence of >>>> elements here. >>>> I would like to establish just what exactly it is because it seems to >>>> store a memory address as can be show with: >>>> int arr[5]; >>>> int* p = arr; >>>> >>>> So lets try to agree about what exactly arr is. >>>> As you know I have been calling it an array type object. >>>> >>>> >>> >>> That would basically be the next step... >>> >>> However, I want to hold to the definition; 'arr' is simply the name >>> of the 5 contiquous int elements. >>> >>> Now - let's take up the problem of assignment to a pointer... >>> >>> Let's consider this snippet: >>> >>> int i; >>> int *ip; >>> >>> ip = &i; >>> >>> would you agree that the semantics of that would be that >>> 'i' is the name of an `int'. `ip' is the name of a pointer to an `int'. >>> The expression: >>> >>> &i >>> >>> denotes "the address of the `int' named `i'" >>> >>> And the expression: >>> >>> ip = &i; >>> >>> denotes "compute the address of the `int' named 'i', store that >>> value into the pointer-to-`int' named `ip'." >>> >>> Does that sound correct? >>> >>> If so, then we can begin to look at your example involving `arr'; >>> and - we can compare the two with considerations toward just >>> what it means to assign a value to the `int' pointer named `ip'. >>> >> Yes this is agreeable. You may continue to the next step :) >> > > OK - let's review - so we know we're on the same page: > > int arr[5]; > > 'arr' is the name of the set of 5 contiguous `int'-typed elements. > > int *ip; > > `ip' is the name of a variable that can contain the address of an `int', > it is a "pointer to int". > > And: > > int i; > > `i' is the name of an `int'-tpe variable. > > The expression: > ip=&i; > > computes the address of `i', and places that value into the variable > `ip'. > > This is what we've agreed to thus far... right? Yes ok. > > This establishes that `ip' is not the same type as `arr'. > `arr' is the contiguous set of 5 `int' elements, `ip' can contain > the address of an `int', it can "point to" an `int'. > No , I agree that ip 'is' not the same type as 'arr' but the next part where you say: "`arr' is the contiguous set of 5 `int' elements" I disagree with this because.. We agreed that 'arr' was a name for the 5 contiguous int objects, which is not the same as saying it is the 5 objects. The rest of what you say re: "ip can contain the address of an int, it can point to an int" , I agree with more or less. I say 'more or less' because I think the term 'contain' could be replaced with something more fitting like perhaps 'store' or 'hold', but its just nitpicking terminology I guess. However the point I made about 'arr' not being the 5 integer objects but a name for them is not nitpicking terminology IMO, and I think we need to resolve this difference of opinions before we can proceed. > There is nothing new in that statement; it is a re-statement > of the preceeding items we've agreed to (in that `arr' is the > set, `ip' is a single pointer.) I think there is something new because you have changed the meaning of 'arr' from (1) to (2) 1) a "name" for the 5 integer objects 2) the 5 integer objects. > > Now - in a programming language like C/C++, typically the > language might enforce rules regarding assignent. One such > rule is that assignments can only be made from a value of the > destination type, and that if the types are not the same, then > some mechanism is employed to convert from oen type to another > (if possible). > > As an example: > > double d; > int i; > > d = i; > > The variable `i' is an `int'; `d' is a `double'. You might decide, > in a programming language, that such an assignment not be > allowed - but it is in C/C++ because the `int' value contained > in `i' will be, at runtime, converted to a `double' and then > stored in the variable `d'. Are you sure this is converted at runtime? I would've though this would be converted at compile time. I'm not sure, OTTOMH, but I can see how this is possible because there would be no loss of information, not so for the reverese though i.e: double to integer. > > In this instance, would you say there was a "magic"/secret object > of type `double' that was created along with `i' to contain the > converted result before assigning the value to `d'? Or, would > you say that the conversion simply occurs as a matter-of-course? TBH I would need to refer to documentation about conversions from integer to double. From my previous studies of computer programming I know about fp type consisting of a mantissa and exponential etc, but I think different systems implement fp numbers in different ways and I would probably refer to the correct documentation to confirm the exact implementation for conversion from integer to fp for the target system. > > I think, most people would say that the compiler generates code > which effects the conversion at runtime, so that `i' is, at runtime, > converted to a double, and the temporary value that results from > that conversion is stored in `d'. > I don't see why this woud be a runtime conversion, as oppose to compile time conversion. > But; this is a well-defined conversion... does the C/C++ language > definition provide any such mechanism for this snippet: I don't know anything about this conversion , this is kinda straying of the subject a bit but if you care to discuss this further I would be willing to investigate it in order to fully understand it. > > int *ip; > int arr[5]; > > ip = arr; > > Given the definitions (to which we've all agreed), `ip' is a pointer > to an `int', and `arr' is a contigous set of 5 `int' elements. How > could > those two types be reconciled to allow this assignment??? But I disagree with this step you have taken to promote 'arr' from a name that refers to a contiguous set of 5 integers to actually being the contiguous set of 5 integers. > > What is going on here?? I don't know :) I think we need to stop here and resolve this disagreement about what 'arr' is. Is it a name that refers to the array of integers, or is it actually the array of integers. > > As it so happens, the designers of C (and, by extension, C++) considered > this problem, and provide a mechanism by which such an assignment > is accomplished. > > This mechanism has been written down in the various standard documents, > so that everyone can read it and truly understand what is meant by > that assignment. > > First - recall, as you have agreed, that arr' is an array of 5 `int' > elements. No I didn't. I agreed that 'arr' was simply the name for 5 contiguous integer objects, I did not agree that 'arr' WAS the contiguous set of integer objects. > > (we clearly cannot assign 5 `int' elements in-toto to a pointer to a > single `int', > in a reasonable type-system, at least.) > > So - given that `arr' is an array, I will quote from the C standard, which > might Well you have certainly promoted 'arr' in this statement. We agreed that 'arr' was a name for the contiguous set of integer objects. Now you seem to defined 'arr' as actually being the contiguous set of integer object, which I dsiagree with. If we look at the data stored in the contiguous set of integer objects, it is not the same data that is stored in 'arr'. > be a little more clear than the C++ one (simply for this discussion, the > C++ > definition is similar): > > Section 6.3.2.1 Lvalues, arrays, and function designators > > Paragraph #1: > > An lvalue is an expression with an object type or an incomplete > type other than void. > > (that is, `arr' is an "lvalue", it is an "lvalue" with an object type of > int[5]. An "lvalue" in C is basically what can appear on the > left-hand-side of the > assignment operator, the opposing "rvalue" appears on the right-hand-side. > That is, you assign the rvalue to the lvalue. In this case, `arr' is an > lvalue, > until you get to the next step.) The problem with this is you cannot assign to 'arr', except during initialisation. It's non modifiable AFAICT. I think we need to go back to where we disagree and resolve that before proceeding any further. <snip>
[toc] | [prev] | [next] | [standalone]
| From | Thomas David Rivers <rivers@dignus.com> |
|---|---|
| Date | 2011-05-28 10:58 -0400 |
| Message-ID | <4DE10DA2.9050201@dignus.com> |
| In reply to | #5743 |
>
> The problem with this is you cannot assign to 'arr', except during
> initialisation.
> It's non modifiable AFAICT.
>
> I think we need to go back to where we disagree and resolve that
> before proceeding any further.
> <snip>
>
>
Oh - OK - let me see if I understand.
I did take the liberty of removing the previous words, just to shorten
the posting - I hope that is OK.
When I read it, I believe you were saying that in the declartion:
int arr[5];
that 'arr' was the _name_ of the array of 5 `int' elements.
Is that correct?
If you completely agree with that, I think we can proceed from
there.
I did see some confusion regarding "compile-time" and "runtime",
which probably motivates definitions of those.
I would like to offer these definitions:
"compile-time" refers to the evaluation of the program's expression
during the compilation process. The compiler can, at its discretion,
evaluate an expression using information it can glean thru the
compilation process, or it can generate code that, when executed,
causes the execution platform to evaluate the expression.
When an expression is evaluated during execution, that is commonly
called "runtime".
Do those definition work for you?
If so, then I would offer this snippet of code as an example
of a "runtime" evaluation of the conversion from an integer
to a double:
Consider this snippet as the entire compilation unit, there
is nothing more in the input source file:
extern int i;
double foo(void)
{
double d;
d = i;
}
In this case, the compiler does not know, a-prior, the value of 'i',
and thus is obliged to produce code which will evaluate the
conversion at execution time. Therefor, following the definitions;
the conversion of 'i' from `int' to `double' is performed at runtime.
Does that sound right?
As a different example, lt's consider this:
double foo(void)
{
return 5;
}
In the C/C++ language, the expression "5" is defined to be an integer
constant.
Thus, the compiler, when processing this source, has the information
to convert the integer constant `5' (which comes from the expression "5")
to a double constant `5.0'. Thus, the compiler is not required to produce
instructions that evaluate this conversion at execution time; it can simply
use the "compile time" converted value. Note that, sometimes, the
compiler is not
obliged to use the "compile time" value (although the language standards
describe situations where it must...) so, frequently the evaluation of
expressions
at "compile time" is considered an optimization.
That is the idea I would like to follow when considering "compile time"
vs. "runtime".
Having said all of that; I'd hope these definitions of "compile time"
and "runtime"
will let us proceed with the other issues, and get back to the definitions
of arrays...
To return to that, do you agree that in this declaration:
int arr[5];
'arr' is the name of the contigous set of 5 `int' elements?
And, to go to the next step, would you agree that in this
declaration:
int i;
`i' is the name of single `int'?
- 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-28 19:41 +0100 |
| Message-ID | <plbEp.20101$h35.14408@newsfe19.ams2> |
| In reply to | #5769 |
"Thomas David Rivers" <rivers@dignus.com> wrote in message
news:4DE10DA2.9050201@dignus.com...
>
>>
>> The problem with this is you cannot assign to 'arr', except during
>> initialisation.
>> It's non modifiable AFAICT.
>>
>> I think we need to go back to where we disagree and resolve that before
>> proceeding any further.
>> <snip>
>>
>>
>
> Oh - OK - let me see if I understand.
>
> I did take the liberty of removing the previous words, just to shorten
> the posting - I hope that is OK.
Ok np.
>
> When I read it, I believe you were saying that in the declartion:
>
> int arr[5];
>
> that 'arr' was the _name_ of the array of 5 `int' elements.
> Is that correct?
>
> If you completely agree with that, I think we can proceed from
> there.
Yes this is what we agreed on IIRC.
>
> I did see some confusion regarding "compile-time" and "runtime",
> which probably motivates definitions of those.
>
> I would like to offer these definitions:
>
> "compile-time" refers to the evaluation of the program's expression
> during the compilation process. The compiler can, at its discretion,
> evaluate an expression using information it can glean thru the
> compilation process, or it can generate code that, when executed,
> causes the execution platform to evaluate the expression.
>
> When an expression is evaluated during execution, that is commonly
> called "runtime".
>
> Do those definition work for you?
>
>
> If so, then I would offer this snippet of code as an example
> of a "runtime" evaluation of the conversion from an integer
> to a double:
>
> Consider this snippet as the entire compilation unit, there
> is nothing more in the input source file:
>
> extern int i;
> double foo(void)
> {
> double d;
> d = i;
> }
>
> In this case, the compiler does not know, a-prior, the value of 'i',
> and thus is obliged to produce code which will evaluate the
> conversion at execution time. Therefor, following the definitions;
> the conversion of 'i' from `int' to `double' is performed at runtime.
>
> Does that sound right?
>
> As a different example, lt's consider this:
>
> double foo(void)
> {
> return 5;
> }
>
> In the C/C++ language, the expression "5" is defined to be an integer
> constant.
>
> Thus, the compiler, when processing this source, has the information
> to convert the integer constant `5' (which comes from the expression "5")
> to a double constant `5.0'. Thus, the compiler is not required to
> produce
> instructions that evaluate this conversion at execution time; it can
> simply
> use the "compile time" converted value. Note that, sometimes, the
> compiler is not
> obliged to use the "compile time" value (although the language standards
> describe situations where it must...) so, frequently the evaluation of
> expressions
> at "compile time" is considered an optimization.
>
> That is the idea I would like to follow when considering "compile time"
> vs. "runtime".
Ok np.
>
> Having said all of that; I'd hope these definitions of "compile time" and
> "runtime"
> will let us proceed with the other issues, and get back to the definitions
> of arrays...
>
> To return to that, do you agree that in this declaration:
>
> int arr[5];
>
> 'arr' is the name of the contigous set of 5 `int' elements?
>
> And, to go to the next step, would you agree that in this
> declaration:
>
> int i;
>
> `i' is the name of single `int'?
>
Yes I agree, you may continue.
[toc] | [prev] | [next] | [standalone]
| From | Thomas David Rivers <rivers@dignus.com> |
|---|---|
| Date | 2011-05-28 20:38 -0400 |
| Message-ID | <4DE19579.1060300@dignus.com> |
| In reply to | #5774 |
Paul wrote:
>
> "Thomas David Rivers" <rivers@dignus.com> wrote in message
> news:4DE10DA2.9050201@dignus.com...
>
>>
>>
>> To return to that, do you agree that in this declaration:
>>
>> int arr[5];
>>
>> 'arr' is the name of the contigous set of 5 `int' elements?
>>
>> And, to go to the next step, would you agree that in this
>> declaration:
>>
>> int i;
>>
>> `i' is the name of single `int'?
>>
> Yes I agree, you may continue.
So - we should then consider something fairly important... what does
"name" mean?
I would ask that we consider the 'name' of something to be the
designation of the location that contains that 'something'. And, I want
to movitave that definition with the following scenario.
If we can imagine that variables, in the C/C++ sense, are simply
"boxes" that contain their values - like shoeboxes on a shelf,
then the "name" associated with the variable is simply the name
associated with a "box." Let's imagine that this shelf can contain
many boxes, and that the boxes are numbered... box #0, box #1, box #2..
A box can be referred to by its number - its location on the shelf, or if
we associate a name with a box #; we can use the name. For example,
box #51 might have the name `i' associated with it.
Thus, if we consider this snippet of C code:
int i;
i = 5;
the semantics of that would be something similar to:
define a box name 'i', allocate space for it, let's say that is box
#51, associate
location #51 with the name 'i'.
produce the manifest `int' constant 5
Find the box with the name 'i', oh - it's box #51.
store the manifest constant 5 into box #51.
Similarly, the snippet:
int i,j;
i = j;
might be realized in this way:
define a box named 'i' that can contain int-typed objects, say, box #51.
define a box named 'j' that can contain int-typed objects, say, box #52.
Given the name 'j'; find its box - oh - it's box #52.
Retrieve (fetch) the value from box #52.
Given the name 'i'; find its box - oh - it's box #51.
Store the value previously fetched value into box #51.
So far, I've only talked about boxes that can contain `int'-typed values.
Let's introduce a new box, and say that it can contain the location (the
box #)
of another box, and the other box can contain `int'-typed values. We would
call this new box a "pointer" to an `int'-typed box, because it doesn't
contain
the `int'-type value itself, but instead tells us the location (the box
#) of the
value.
Now - let's consider this:
int *ip;
int i;
ip = &i;
in this mindset - what does this mean? To discuss this, we need to define
the &-operator. Le's say that the &-operator is named 'address of' and that
it returns the location (the box #) of its operand. Say, for example,
if `i'
happened to be box #51, then the expression "&i" would produce location #51.
Remember - I can have two kinds of boxes on my shelf, boxes that contain
`int'-typed values, and boxes that contain the location of other
`int'-typed boxes.
So, &i doesn't produce an `int'-typed value, it produces a location. In
this
example, it produced #51. (I have been careful to use '#' to indicate
location numbers
instead of simple `int'-typed values.. this distinction will become
important.)
So - the semantics of that statement would be (if I may be so bold
as to be a little loose on the details):
define a box named 'ip' - it can contain the location of other
`int'-typed boxes,
let's say it is box #52.
define a box named 'i' - it can contain `int' values, let's say it's
box #51.
Apply the &-operator to the box named `i' - oh - i is box #51, so &i
produces
the location #51.
Look up the name `ip - oh - that's box #52.
Store our previously found location (#51) into box #52.
OK - now - let's say that I happen to buy my boxes from a manufacturer that
can only make 2-kinds of boxes, those boxes that can contain `int' elements,
and those boxes that can contain the location of other boxes that contain
`int' elements. (that is, `int' boxes and `int *' boxes).
So, let's look at this:
int *ip;
int arr[5];
What can this do? I propose it does the following:
define a box named 'ip', that box is allowed to contain the location of
other `int'-type boxes; let's say that is box #52.
define a space of 5 boxes, each of these boxes is on the shelf starting
at, say, location #53. Each of these boxes is an `int'-typed
box. The
boxes are contiguous, starting a location #53 and going thru location
#57 (inclusive.) Since `arr' (at the C/C++ level) is a single
object,
the location associated with `arr' is #53 (the start of the 5
contiguous
boxes on the shelf.)
That is, in this scenario, the location of 'ip' is box #52, the
location of 'arr'
is box #53. `ip' uses one box, `arr' uses 5 boxes.
With this, we can provide a definition of "name".... the "name" of the
variable
provides a mechanism for finding precisely which "box" (the box #, or
location
of the box) houses the value of the variable. The "name" is nothing
more than
a convenience for mapping the location of the variable.
So - in our example, the name 'ip' is asociated with box #52, the name 'arr'
is associated with box #53.
Before I go on, I want to check to see if you agree with everything so
far...
- 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-29 12:32 +0100 |
| Message-ID | <M9qEp.30087$7H.25042@newsfe08.ams2> |
| In reply to | #5789 |
"Thomas David Rivers" <rivers@dignus.com> wrote in message news:4DE19579.1060300@dignus.com... > Paul wrote: > >>> >>> >>> To return to that, do you agree that in this declaration: >>> >>> int arr[5]; >>> >>> 'arr' is the name of the contigous set of 5 `int' elements? >>> >>> And, to go to the next step, would you agree that in this >>> declaration: >>> >>> int i; >>> >>> `i' is the name of single `int'? >>> >> Yes I agree, you may continue. > > > > So - we should then consider something fairly important... what does > "name" mean? > > I would ask that we consider the 'name' of something to be the > designation of the location that contains that 'something'. And, I want > to movitave that definition with the following scenario. > > If we can imagine that variables, in the C/C++ sense, are simply > "boxes" that contain their values - like shoeboxes on a shelf, > then the "name" associated with the variable is simply the name > associated with a "box." Let's imagine that this shelf can contain > many boxes, and that the boxes are numbered... box #0, box #1, box #2.. > > A box can be referred to by its number - its location on the shelf, or if > we associate a name with a box #; we can use the name. For example, > box #51 might have the name `i' associated with it. > > Thus, if we consider this snippet of C code: > > > int i; > i = 5; > > the semantics of that would be something similar to: > > define a box name 'i', allocate space for it, let's say that is box #51, > associate > location #51 with the name 'i'. > > produce the manifest `int' constant 5 > Find the box with the name 'i', oh - it's box #51. > store the manifest constant 5 into box #51. > > > > Similarly, the snippet: > > int i,j; > i = j; > > might be realized in this way: > > define a box named 'i' that can contain int-typed objects, say, box #51. > define a box named 'j' that can contain int-typed objects, say, box #52. > > Given the name 'j'; find its box - oh - it's box #52. > Retrieve (fetch) the value from box #52. > Given the name 'i'; find its box - oh - it's box #51. > Store the value previously fetched value into box #51. > > > So far, I've only talked about boxes that can contain `int'-typed values. > > Let's introduce a new box, and say that it can contain the location (the > box #) > of another box, and the other box can contain `int'-typed values. We > would > call this new box a "pointer" to an `int'-typed box, because it doesn't > contain > the `int'-type value itself, but instead tells us the location (the box #) > of the > value. > > Now - let's consider this: > > int *ip; > int i; > > ip = &i; > > in this mindset - what does this mean? To discuss this, we need to define > the &-operator. Le's say that the &-operator is named 'address of' and > that > it returns the location (the box #) of its operand. Say, for example, if > `i' > happened to be box #51, then the expression "&i" would produce location > #51. > > Remember - I can have two kinds of boxes on my shelf, boxes that contain > `int'-typed values, and boxes that contain the location of other > `int'-typed boxes. > So, &i doesn't produce an `int'-typed value, it produces a location. In > this > example, it produced #51. (I have been careful to use '#' to indicate > location numbers > instead of simple `int'-typed values.. this distinction will become > important.) > > So - the semantics of that statement would be (if I may be so bold > as to be a little loose on the details): > > define a box named 'ip' - it can contain the location of other > `int'-typed boxes, > let's say it is box #52. > define a box named 'i' - it can contain `int' values, let's say it's box > #51. > > Apply the &-operator to the box named `i' - oh - i is box #51, so &i > produces > the location #51. > Look up the name `ip - oh - that's box #52. > Store our previously found location (#51) into box #52. > > > OK - now - let's say that I happen to buy my boxes from a manufacturer > that > can only make 2-kinds of boxes, those boxes that can contain `int' > elements, > and those boxes that can contain the location of other boxes that contain > `int' elements. (that is, `int' boxes and `int *' boxes). > So, let's look at this: > > int *ip; > int arr[5]; > > > What can this do? I propose it does the following: > > define a box named 'ip', that box is allowed to contain the location > of > other `int'-type boxes; let's say that is box #52. > define a space of 5 boxes, each of these boxes is on the shelf > starting > at, say, location #53. Each of these boxes is an `int'-typed box. > The > boxes are contiguous, starting a location #53 and going thru > location > #57 (inclusive.) Since `arr' (at the C/C++ level) is a single > object, > the location associated with `arr' is #53 (the start of the 5 > contiguous > boxes on the shelf.) > > That is, in this scenario, the location of 'ip' is box #52, the location > of 'arr' > is box #53. `ip' uses one box, `arr' uses 5 boxes. > > With this, we can provide a definition of "name".... the "name" of the > variable > provides a mechanism for finding precisely which "box" (the box #, or > location > of the box) houses the value of the variable. The "name" is nothing more > than > a convenience for mapping the location of the variable. > So - in our example, the name 'ip' is asociated with box #52, the name > 'arr' > is associated with box #53. > > Before I go on, I want to check to see if you agree with everything so > far... > I agree with you that the "name" provides a mechanisn for mapping the location but.... The names 'i', 'ip' and 'arr' have different name mechanisms. The name 'i' refers to box#51, when used in an expression it evaluates to whatever is contained in box#51. The name 'ip' refers to box#52, it evaluates to whatever is contained in box#52. The name 'arr' refers to box#53.... but it does not evaluate to the contents of box#53. It evaluates to the address of box#53.
[toc] | [prev] | [next] | [standalone]
| From | Thomas David Rivers <rivers@dignus.com> |
|---|---|
| Date | 2011-05-29 10:05 -0400 |
| Message-ID | <4DE252BD.8060100@dignus.com> |
| In reply to | #5793 |
Paul wrote:
>
> "Thomas David Rivers" <rivers@dignus.com> wrote in message
> news:4DE19579.1060300@dignus.com...
>
>> Paul wrote:
>>
>>>>
>>>>
>>>> To return to that, do you agree that in this declaration:
>>>>
>>>> int arr[5];
>>>>
>>>> 'arr' is the name of the contigous set of 5 `int' elements?
>>>>
>>>> And, to go to the next step, would you agree that in this
>>>> declaration:
>>>>
>>>> int i;
>>>>
>>>> `i' is the name of single `int'?
>>>>
>>> Yes I agree, you may continue.
>>
>>
>>
>>
>> So - we should then consider something fairly important... what does
>> "name" mean?
>>
>> I would ask that we consider the 'name' of something to be the
>> designation of the location that contains that 'something'. And, I want
>> to movitave that definition with the following scenario.
>>
>> If we can imagine that variables, in the C/C++ sense, are simply
>> "boxes" that contain their values - like shoeboxes on a shelf,
>> then the "name" associated with the variable is simply the name
>> associated with a "box." Let's imagine that this shelf can contain
>> many boxes, and that the boxes are numbered... box #0, box #1, box #2..
>>
>> A box can be referred to by its number - its location on the shelf,
>> or if
>> we associate a name with a box #; we can use the name. For example,
>> box #51 might have the name `i' associated with it.
>>
>> Thus, if we consider this snippet of C code:
>>
>>
>> int i;
>> i = 5;
>>
>> the semantics of that would be something similar to:
>>
>> define a box name 'i', allocate space for it, let's say that is box
>> #51, associate
>> location #51 with the name 'i'.
>>
>> produce the manifest `int' constant 5
>> Find the box with the name 'i', oh - it's box #51.
>> store the manifest constant 5 into box #51.
>>
>>
>>
>> Similarly, the snippet:
>>
>> int i,j;
>> i = j;
>>
>> might be realized in this way:
>>
>> define a box named 'i' that can contain int-typed objects, say, box
>> #51.
>> define a box named 'j' that can contain int-typed objects, say, box
>> #52.
>>
>> Given the name 'j'; find its box - oh - it's box #52.
>> Retrieve (fetch) the value from box #52.
>> Given the name 'i'; find its box - oh - it's box #51.
>> Store the value previously fetched value into box #51.
>>
>>
>> So far, I've only talked about boxes that can contain `int'-typed
>> values.
>>
>> Let's introduce a new box, and say that it can contain the location
>> (the box #)
>> of another box, and the other box can contain `int'-typed values. We
>> would
>> call this new box a "pointer" to an `int'-typed box, because it
>> doesn't contain
>> the `int'-type value itself, but instead tells us the location (the
>> box #) of the
>> value.
>>
>> Now - let's consider this:
>>
>> int *ip;
>> int i;
>>
>> ip = &i;
>>
>> in this mindset - what does this mean? To discuss this, we need to
>> define
>> the &-operator. Le's say that the &-operator is named 'address of'
>> and that
>> it returns the location (the box #) of its operand. Say, for
>> example, if `i'
>> happened to be box #51, then the expression "&i" would produce
>> location #51.
>>
>> Remember - I can have two kinds of boxes on my shelf, boxes that contain
>> `int'-typed values, and boxes that contain the location of other
>> `int'-typed boxes.
>> So, &i doesn't produce an `int'-typed value, it produces a location.
>> In this
>> example, it produced #51. (I have been careful to use '#' to
>> indicate location numbers
>> instead of simple `int'-typed values.. this distinction will become
>> important.)
>>
>> So - the semantics of that statement would be (if I may be so bold
>> as to be a little loose on the details):
>>
>> define a box named 'ip' - it can contain the location of other
>> `int'-typed boxes,
>> let's say it is box #52.
>> define a box named 'i' - it can contain `int' values, let's say it's
>> box #51.
>>
>> Apply the &-operator to the box named `i' - oh - i is box #51, so
>> &i produces
>> the location #51.
>> Look up the name `ip - oh - that's box #52.
>> Store our previously found location (#51) into box #52.
>>
>>
>> OK - now - let's say that I happen to buy my boxes from a
>> manufacturer that
>> can only make 2-kinds of boxes, those boxes that can contain `int'
>> elements,
>> and those boxes that can contain the location of other boxes that
>> contain
>> `int' elements. (that is, `int' boxes and `int *' boxes).
>> So, let's look at this:
>>
>> int *ip;
>> int arr[5];
>>
>>
>> What can this do? I propose it does the following:
>>
>> define a box named 'ip', that box is allowed to contain the
>> location of
>> other `int'-type boxes; let's say that is box #52.
>> define a space of 5 boxes, each of these boxes is on the shelf
>> starting
>> at, say, location #53. Each of these boxes is an `int'-typed
>> box. The
>> boxes are contiguous, starting a location #53 and going thru
>> location
>> #57 (inclusive.) Since `arr' (at the C/C++ level) is a single
>> object,
>> the location associated with `arr' is #53 (the start of the 5
>> contiguous
>> boxes on the shelf.)
>>
>> That is, in this scenario, the location of 'ip' is box #52, the
>> location of 'arr'
>> is box #53. `ip' uses one box, `arr' uses 5 boxes.
>>
>> With this, we can provide a definition of "name".... the "name" of
>> the variable
>> provides a mechanism for finding precisely which "box" (the box #, or
>> location
>> of the box) houses the value of the variable. The "name" is nothing
>> more than
>> a convenience for mapping the location of the variable.
>> So - in our example, the name 'ip' is asociated with box #52, the
>> name 'arr'
>> is associated with box #53.
>>
>> Before I go on, I want to check to see if you agree with everything
>> so far...
>>
> I agree with you that the "name" provides a mechanisn for mapping the
> location but....
> The names 'i', 'ip' and 'arr' have different name mechanisms.
> The name 'i' refers to box#51, when used in an expression it evaluates
> to whatever is contained in box#51.
> The name 'ip' refers to box#52, it evaluates to whatever is contained
> in box#52.
>
> The name 'arr' refers to box#53.... but it does not evaluate to the
> contents of box#53. It evaluates to the address of box#53.
>
I left all of the context above, so we have something to refer to....
And - yes - you are absolutely right... the name 'arr' refers to the
start of
the array... that is; as you correctly point out above; 'arr' would
refer to box #53.
To echo your statement, the name 'arr' does not refer to the contents of
boxes #53 thru #57 - it, in many contexts, refers to the location #53.
Similarly, the name 'ip' denotes box #52... but, as you correctly point out,
the context in which the name is referenced is key to understanding what is
happening.
For example, in this snippet:
int i, j;
i = j;
On the right-hand-side of the assignment operator, we find 'j' - that refers
to the contents of the box at the location associated with the name
'j'. In C, we call
that an "rvalue". On the left-hand-side, we find 'i'. That refers to
the location of 'i',
the location used for storing the value computed on the
right-hand-side. In C, we call than an "lvalue". Note that, in both
instances, the names do refer to the location
of the boxes - it is simply what is done with that location that
changes. In the rvalue
context, we fetch the contents of the box, on the lvalue side, we store
the value into
the box.
(Note that 'j' in the assignment expression is first an "lvalue" and is
converted
into an "rvalue" by the rules of the language. It is this treatment
that indicates
that the value is to be retrieved from the box.)
As you mentioned above, the context is critical to understanding what is
going
on. I commend you on recognizing that distinction.
Thus - we now need to consider what it means in C/C++ when we encounter
an expression using the name of an array.
The way this is encapsulated in the C/C++ language is the rule regarding
conversion of an lvalue with an array type to a pointer to the first element
of the array.
So - if we now consider this:
int *ip;
int arr[5];
ip = arr;
What would happen in our "shoebox" world? If we use your absolutely
correct
observation, then it would be this:
define a box named "ip", say - box #52 - that box can contain the
location of
other `int'-typed boxes
define a space of 5 boxes, beginning at box #53 thru box #57; name that
area 'arr' by associating 'arr' with box #53
Now - how do we evaluate the expression "arr" in the context of the
assignment statement? Well, according to the C language rules, when
you discover an lvalue that has a type 'array'; you convert that into
the address of its first element.
Thus, we can say that:
ip = arr;
can be evaluated as:
Look up the name 'arr' - oh, it is an array of 5 `int'-typed
boxes. According
to the rules, in this context, we should produce the location of the
first box of the array, that would be location #53.
Look up the name 'ip' - oh - that is a box (at location #52) that
can contain the location
of other `int'-typed boxes.
Store the value previously found location (#53) into box #52.
As you had correctly forseen, we are able to evaluate this using the rules
of the programming language.
Note that, there wasn't a "extra" shoebox allocated/needed to produce
the result.
Note that the 'name' did not mean some other space was allocated... it
simply
refers to the location, as we have previously shown/agreed to.
If you can agree with this, then we can move on to other interesting items.
- 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-29 20:13 +0100 |
| Message-ID | <nVwEp.24865$h_.19621@newsfe30.ams2> |
| In reply to | #5800 |
"Thomas David Rivers" <rivers@dignus.com> wrote in message news:4DE252BD.8060100@dignus.com... > Paul wrote: > >>> >>>>> >>>>> >>>>> To return to that, do you agree that in this declaration: >>>>> >>>>> int arr[5]; >>>>> >>>>> 'arr' is the name of the contigous set of 5 `int' elements? >>>>> >>>>> And, to go to the next step, would you agree that in this >>>>> declaration: >>>>> >>>>> int i; >>>>> >>>>> `i' is the name of single `int'? >>>>> >>>> Yes I agree, you may continue. >>> >>> >>> >>> >>> So - we should then consider something fairly important... what does >>> "name" mean? >>> >>> I would ask that we consider the 'name' of something to be the >>> designation of the location that contains that 'something'. And, I want >>> to movitave that definition with the following scenario. >>> >>> If we can imagine that variables, in the C/C++ sense, are simply >>> "boxes" that contain their values - like shoeboxes on a shelf, >>> then the "name" associated with the variable is simply the name >>> associated with a "box." Let's imagine that this shelf can contain >>> many boxes, and that the boxes are numbered... box #0, box #1, box #2.. >>> >>> A box can be referred to by its number - its location on the shelf, or >>> if >>> we associate a name with a box #; we can use the name. For example, >>> box #51 might have the name `i' associated with it. >>> >>> Thus, if we consider this snippet of C code: >>> >>> >>> int i; >>> i = 5; >>> >>> the semantics of that would be something similar to: >>> >>> define a box name 'i', allocate space for it, let's say that is box >>> #51, associate >>> location #51 with the name 'i'. >>> >>> produce the manifest `int' constant 5 >>> Find the box with the name 'i', oh - it's box #51. >>> store the manifest constant 5 into box #51. >>> >>> >>> >>> Similarly, the snippet: >>> >>> int i,j; >>> i = j; >>> >>> might be realized in this way: >>> >>> define a box named 'i' that can contain int-typed objects, say, box >>> #51. >>> define a box named 'j' that can contain int-typed objects, say, box >>> #52. >>> >>> Given the name 'j'; find its box - oh - it's box #52. >>> Retrieve (fetch) the value from box #52. >>> Given the name 'i'; find its box - oh - it's box #51. >>> Store the value previously fetched value into box #51. >>> >>> >>> So far, I've only talked about boxes that can contain `int'-typed >>> values. >>> >>> Let's introduce a new box, and say that it can contain the location (the >>> box #) >>> of another box, and the other box can contain `int'-typed values. We >>> would >>> call this new box a "pointer" to an `int'-typed box, because it doesn't >>> contain >>> the `int'-type value itself, but instead tells us the location (the box >>> #) of the >>> value. >>> >>> Now - let's consider this: >>> >>> int *ip; >>> int i; >>> >>> ip = &i; >>> >>> in this mindset - what does this mean? To discuss this, we need to >>> define >>> the &-operator. Le's say that the &-operator is named 'address of' and >>> that >>> it returns the location (the box #) of its operand. Say, for example, >>> if `i' >>> happened to be box #51, then the expression "&i" would produce location >>> #51. >>> >>> Remember - I can have two kinds of boxes on my shelf, boxes that contain >>> `int'-typed values, and boxes that contain the location of other >>> `int'-typed boxes. >>> So, &i doesn't produce an `int'-typed value, it produces a location. In >>> this >>> example, it produced #51. (I have been careful to use '#' to indicate >>> location numbers >>> instead of simple `int'-typed values.. this distinction will become >>> important.) >>> >>> So - the semantics of that statement would be (if I may be so bold >>> as to be a little loose on the details): >>> >>> define a box named 'ip' - it can contain the location of other >>> `int'-typed boxes, >>> let's say it is box #52. >>> define a box named 'i' - it can contain `int' values, let's say it's >>> box #51. >>> >>> Apply the &-operator to the box named `i' - oh - i is box #51, so &i >>> produces >>> the location #51. >>> Look up the name `ip - oh - that's box #52. >>> Store our previously found location (#51) into box #52. >>> >>> >>> OK - now - let's say that I happen to buy my boxes from a manufacturer >>> that >>> can only make 2-kinds of boxes, those boxes that can contain `int' >>> elements, >>> and those boxes that can contain the location of other boxes that >>> contain >>> `int' elements. (that is, `int' boxes and `int *' boxes). >>> So, let's look at this: >>> >>> int *ip; >>> int arr[5]; >>> >>> >>> What can this do? I propose it does the following: >>> >>> define a box named 'ip', that box is allowed to contain the location >>> of >>> other `int'-type boxes; let's say that is box #52. >>> define a space of 5 boxes, each of these boxes is on the shelf >>> starting >>> at, say, location #53. Each of these boxes is an `int'-typed box. >>> The >>> boxes are contiguous, starting a location #53 and going thru >>> location >>> #57 (inclusive.) Since `arr' (at the C/C++ level) is a single >>> object, >>> the location associated with `arr' is #53 (the start of the 5 >>> contiguous >>> boxes on the shelf.) >>> >>> That is, in this scenario, the location of 'ip' is box #52, the >>> location of 'arr' >>> is box #53. `ip' uses one box, `arr' uses 5 boxes. >>> >>> With this, we can provide a definition of "name".... the "name" of the >>> variable >>> provides a mechanism for finding precisely which "box" (the box #, or >>> location >>> of the box) houses the value of the variable. The "name" is nothing >>> more than >>> a convenience for mapping the location of the variable. >>> So - in our example, the name 'ip' is asociated with box #52, the name >>> 'arr' >>> is associated with box #53. >>> >>> Before I go on, I want to check to see if you agree with everything so >>> far... >>> >> I agree with you that the "name" provides a mechanisn for mapping the >> location but.... >> The names 'i', 'ip' and 'arr' have different name mechanisms. >> The name 'i' refers to box#51, when used in an expression it evaluates to >> whatever is contained in box#51. >> The name 'ip' refers to box#52, it evaluates to whatever is contained in >> box#52. >> >> The name 'arr' refers to box#53.... but it does not evaluate to the >> contents of box#53. It evaluates to the address of box#53. >> > > I left all of the context above, so we have something to refer to.... > > And - yes - you are absolutely right... the name 'arr' refers to the > start of > the array... that is; as you correctly point out above; 'arr' would refer > to box #53. > To echo your statement, the name 'arr' does not refer to the contents of > boxes #53 thru #57 - it, in many contexts, refers to the location #53. > Similarly, the name 'ip' denotes box #52... but, as you correctly point > out, > the context in which the name is referenced is key to understanding what > is > happening. > > For example, in this snippet: > > int i, j; > i = j; > > On the right-hand-side of the assignment operator, we find 'j' - that > refers > to the contents of the box at the location associated with the name 'j'. > In C, we call > that an "rvalue". On the left-hand-side, we find 'i'. That refers to the > location of 'i', > the location used for storing the value computed on the right-hand-side. > In C, we call than an "lvalue". Note that, in both instances, the names > do refer to the location > of the boxes - it is simply what is done with that location that changes. > In the rvalue > context, we fetch the contents of the box, on the lvalue side, we store > the value into > the box. > > (Note that 'j' in the assignment expression is first an "lvalue" and is > converted > into an "rvalue" by the rules of the language. It is this treatment that > indicates > that the value is to be retrieved from the box.) > > As you mentioned above, the context is critical to understanding what is > going > on. I commend you on recognizing that distinction. > > Thus - we now need to consider what it means in C/C++ when we encounter > an expression using the name of an array. > > The way this is encapsulated in the C/C++ language is the rule regarding > conversion of an lvalue with an array type to a pointer to the first > element > of the array. > > So - if we now consider this: > > int *ip; > int arr[5]; > > ip = arr; > > What would happen in our "shoebox" world? If we use your absolutely > correct > observation, then it would be this: > > define a box named "ip", say - box #52 - that box can contain the > location of > other `int'-typed boxes > define a space of 5 boxes, beginning at box #53 thru box #57; name > that > area 'arr' by associating 'arr' with box #53 > > Now - how do we evaluate the expression "arr" in the context of the > assignment statement? Well, according to the C language rules, when > you discover an lvalue that has a type 'array'; you convert that into > the address of its first element. > > Thus, we can say that: > > ip = arr; > > can be evaluated as: > > Look up the name 'arr' - oh, it is an array of 5 `int'-typed boxes. > According > to the rules, in this context, we should produce the location of the > first box of the array, that would be location #53. > Look up the name 'ip' - oh - that is a box (at location #52) that can > contain the location > of other `int'-typed boxes. > Store the value previously found location (#53) into box #52. > > As you had correctly forseen, we are able to evaluate this using the rules > of the programming language. > > Note that, there wasn't a "extra" shoebox allocated/needed to produce the > result. > > Note that the 'name' did not mean some other space was allocated... it > simply > refers to the location, as we have previously shown/agreed to. > This behaviour is different to other C++ names. For example given the name of an int or an int*: int x=7; int* p =7; When we use the names of a object in C++ we expect the the object to be addressed and the value accessed whether it be a read or write operation. With an arr the situation is different , when we use the name of an array we do not expect the array to be addressed , instead we expect a pointer to the array: int* = arr; The identifier or name 'arr' refers to an array of objects yet somehow its value is an address , not the same value as any of the objects it refers to. In C++
[toc] | [prev] | [next] | [standalone]
| From | Thomas David Rivers <rivers@dignus.com> |
|---|---|
| Date | 2011-05-29 19:38 -0400 |
| Message-ID | <4DE2D8FA.6@dignus.com> |
| In reply to | #5808 |
Paul wrote:
>
> "Thomas David Rivers" <rivers@dignus.com> wrote in message
> news:4DE252BD.8060100@dignus.com...
>
>> Paul wrote:
>>
>>>>
>>>>>>
>>>>>>
>>>>>> To return to that, do you agree that in this declaration:
>>>>>>
>>>>>> int arr[5];
>>>>>>
>>>>>> 'arr' is the name of the contigous set of 5 `int' elements?
>>>>>>
>>>>>> And, to go to the next step, would you agree that in this
>>>>>> declaration:
>>>>>>
>>>>>> int i;
>>>>>>
>>>>>> `i' is the name of single `int'?
>>>>>>
>>>>> Yes I agree, you may continue.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> So - we should then consider something fairly important... what does
>>>> "name" mean?
>>>>
>>>> I would ask that we consider the 'name' of something to be the
>>>> designation of the location that contains that 'something'. And, I
>>>> want
>>>> to movitave that definition with the following scenario.
>>>>
>>>> If we can imagine that variables, in the C/C++ sense, are simply
>>>> "boxes" that contain their values - like shoeboxes on a shelf,
>>>> then the "name" associated with the variable is simply the name
>>>> associated with a "box." Let's imagine that this shelf can contain
>>>> many boxes, and that the boxes are numbered... box #0, box #1, box
>>>> #2..
>>>>
>>>> A box can be referred to by its number - its location on the shelf,
>>>> or if
>>>> we associate a name with a box #; we can use the name. For example,
>>>> box #51 might have the name `i' associated with it.
>>>>
>>>> Thus, if we consider this snippet of C code:
>>>>
>>>>
>>>> int i;
>>>> i = 5;
>>>>
>>>> the semantics of that would be something similar to:
>>>>
>>>> define a box name 'i', allocate space for it, let's say that is
>>>> box #51, associate
>>>> location #51 with the name 'i'.
>>>>
>>>> produce the manifest `int' constant 5
>>>> Find the box with the name 'i', oh - it's box #51.
>>>> store the manifest constant 5 into box #51.
>>>>
>>>>
>>>>
>>>> Similarly, the snippet:
>>>>
>>>> int i,j;
>>>> i = j;
>>>>
>>>> might be realized in this way:
>>>>
>>>> define a box named 'i' that can contain int-typed objects, say,
>>>> box #51.
>>>> define a box named 'j' that can contain int-typed objects, say,
>>>> box #52.
>>>>
>>>> Given the name 'j'; find its box - oh - it's box #52.
>>>> Retrieve (fetch) the value from box #52.
>>>> Given the name 'i'; find its box - oh - it's box #51.
>>>> Store the value previously fetched value into box #51.
>>>>
>>>>
>>>> So far, I've only talked about boxes that can contain `int'-typed
>>>> values.
>>>>
>>>> Let's introduce a new box, and say that it can contain the location
>>>> (the box #)
>>>> of another box, and the other box can contain `int'-typed values.
>>>> We would
>>>> call this new box a "pointer" to an `int'-typed box, because it
>>>> doesn't contain
>>>> the `int'-type value itself, but instead tells us the location (the
>>>> box #) of the
>>>> value.
>>>>
>>>> Now - let's consider this:
>>>>
>>>> int *ip;
>>>> int i;
>>>>
>>>> ip = &i;
>>>>
>>>> in this mindset - what does this mean? To discuss this, we need to
>>>> define
>>>> the &-operator. Le's say that the &-operator is named 'address of'
>>>> and that
>>>> it returns the location (the box #) of its operand. Say, for
>>>> example, if `i'
>>>> happened to be box #51, then the expression "&i" would produce
>>>> location #51.
>>>>
>>>> Remember - I can have two kinds of boxes on my shelf, boxes that
>>>> contain
>>>> `int'-typed values, and boxes that contain the location of other
>>>> `int'-typed boxes.
>>>> So, &i doesn't produce an `int'-typed value, it produces a
>>>> location. In this
>>>> example, it produced #51. (I have been careful to use '#' to
>>>> indicate location numbers
>>>> instead of simple `int'-typed values.. this distinction will become
>>>> important.)
>>>>
>>>> So - the semantics of that statement would be (if I may be so bold
>>>> as to be a little loose on the details):
>>>>
>>>> define a box named 'ip' - it can contain the location of other
>>>> `int'-typed boxes,
>>>> let's say it is box #52.
>>>> define a box named 'i' - it can contain `int' values, let's say
>>>> it's box #51.
>>>>
>>>> Apply the &-operator to the box named `i' - oh - i is box #51, so
>>>> &i produces
>>>> the location #51.
>>>> Look up the name `ip - oh - that's box #52.
>>>> Store our previously found location (#51) into box #52.
>>>>
>>>>
>>>> OK - now - let's say that I happen to buy my boxes from a
>>>> manufacturer that
>>>> can only make 2-kinds of boxes, those boxes that can contain `int'
>>>> elements,
>>>> and those boxes that can contain the location of other boxes that
>>>> contain
>>>> `int' elements. (that is, `int' boxes and `int *' boxes).
>>>> So, let's look at this:
>>>>
>>>> int *ip;
>>>> int arr[5];
>>>>
>>>>
>>>> What can this do? I propose it does the following:
>>>>
>>>> define a box named 'ip', that box is allowed to contain the
>>>> location of
>>>> other `int'-type boxes; let's say that is box #52.
>>>> define a space of 5 boxes, each of these boxes is on the shelf
>>>> starting
>>>> at, say, location #53. Each of these boxes is an `int'-typed
>>>> box. The
>>>> boxes are contiguous, starting a location #53 and going thru
>>>> location
>>>> #57 (inclusive.) Since `arr' (at the C/C++ level) is a
>>>> single object,
>>>> the location associated with `arr' is #53 (the start of the 5
>>>> contiguous
>>>> boxes on the shelf.)
>>>>
>>>> That is, in this scenario, the location of 'ip' is box #52, the
>>>> location of 'arr'
>>>> is box #53. `ip' uses one box, `arr' uses 5 boxes.
>>>>
>>>> With this, we can provide a definition of "name".... the "name" of
>>>> the variable
>>>> provides a mechanism for finding precisely which "box" (the box #,
>>>> or location
>>>> of the box) houses the value of the variable. The "name" is
>>>> nothing more than
>>>> a convenience for mapping the location of the variable.
>>>> So - in our example, the name 'ip' is asociated with box #52, the
>>>> name 'arr'
>>>> is associated with box #53.
>>>>
>>>> Before I go on, I want to check to see if you agree with everything
>>>> so far...
>>>>
>>> I agree with you that the "name" provides a mechanisn for mapping
>>> the location but....
>>> The names 'i', 'ip' and 'arr' have different name mechanisms.
>>> The name 'i' refers to box#51, when used in an expression it
>>> evaluates to whatever is contained in box#51.
>>> The name 'ip' refers to box#52, it evaluates to whatever is
>>> contained in box#52.
>>>
>>> The name 'arr' refers to box#53.... but it does not evaluate to the
>>> contents of box#53. It evaluates to the address of box#53.
>>>
>>
>> I left all of the context above, so we have something to refer to....
>>
>> And - yes - you are absolutely right... the name 'arr' refers to
>> the start of
>> the array... that is; as you correctly point out above; 'arr' would
>> refer to box #53.
>> To echo your statement, the name 'arr' does not refer to the contents of
>> boxes #53 thru #57 - it, in many contexts, refers to the location #53.
>> Similarly, the name 'ip' denotes box #52... but, as you correctly
>> point out,
>> the context in which the name is referenced is key to understanding
>> what is
>> happening.
>>
>> For example, in this snippet:
>>
>> int i, j;
>> i = j;
>>
>> On the right-hand-side of the assignment operator, we find 'j' - that
>> refers
>> to the contents of the box at the location associated with the name
>> 'j'. In C, we call
>> that an "rvalue". On the left-hand-side, we find 'i'. That refers
>> to the location of 'i',
>> the location used for storing the value computed on the
>> right-hand-side. In C, we call than an "lvalue". Note that, in both
>> instances, the names do refer to the location
>> of the boxes - it is simply what is done with that location that
>> changes. In the rvalue
>> context, we fetch the contents of the box, on the lvalue side, we
>> store the value into
>> the box.
>>
>> (Note that 'j' in the assignment expression is first an "lvalue" and
>> is converted
>> into an "rvalue" by the rules of the language. It is this treatment
>> that indicates
>> that the value is to be retrieved from the box.)
>>
>> As you mentioned above, the context is critical to understanding what
>> is going
>> on. I commend you on recognizing that distinction.
>>
>> Thus - we now need to consider what it means in C/C++ when we encounter
>> an expression using the name of an array.
>>
>> The way this is encapsulated in the C/C++ language is the rule regarding
>> conversion of an lvalue with an array type to a pointer to the first
>> element
>> of the array.
>>
>> So - if we now consider this:
>>
>> int *ip;
>> int arr[5];
>>
>> ip = arr;
>>
>> What would happen in our "shoebox" world? If we use your absolutely
>> correct
>> observation, then it would be this:
>>
>> define a box named "ip", say - box #52 - that box can contain the
>> location of
>> other `int'-typed boxes
>> define a space of 5 boxes, beginning at box #53 thru box #57;
>> name that
>> area 'arr' by associating 'arr' with box #53
>>
>> Now - how do we evaluate the expression "arr" in the context of the
>> assignment statement? Well, according to the C language rules, when
>> you discover an lvalue that has a type 'array'; you convert that into
>> the address of its first element.
>>
>> Thus, we can say that:
>>
>> ip = arr;
>>
>> can be evaluated as:
>>
>> Look up the name 'arr' - oh, it is an array of 5 `int'-typed
>> boxes. According
>> to the rules, in this context, we should produce the location
>> of the
>> first box of the array, that would be location #53.
>> Look up the name 'ip' - oh - that is a box (at location #52) that
>> can contain the location
>> of other `int'-typed boxes.
>> Store the value previously found location (#53) into box #52.
>>
>> As you had correctly forseen, we are able to evaluate this using the
>> rules
>> of the programming language.
>>
>> Note that, there wasn't a "extra" shoebox allocated/needed to produce
>> the result.
>>
>> Note that the 'name' did not mean some other space was allocated...
>> it simply
>> refers to the location, as we have previously shown/agreed to.
>>
>
> This behaviour is different to other C++ names.
> For example given the name of an int or an int*:
>
> int x=7;
> int* p =7;
>
> When we use the names of a object in C++ we expect the the object to
> be addressed and the value accessed whether it be a read or write
> operation.
> With an arr the situation is different , when we use the name of an
> array we do not expect the array to be addressed , instead we expect a
> pointer to the array:
> int* = arr;
>
> The identifier or name 'arr' refers to an array of objects yet somehow
> its value is an address , not the same value as any of the objects it
> refers to.
>
>
> In C++
You are correct.. the reason for your correctness has been detailed
above.
For arrays, there is a "special" rule.. this rule is only for arrays,
the rule
is that when the array name is used, it does not designate the entire
array, it designates the address of the first element.
I am glad that you have reached this understanding, and that you have
expressed your agreement!
That is, when you reference an array name, it does not denote the entire
array; nor is there any other special object that is created to point to the
array - it is simply that the result of the reference is the address of the
first element (which you pointed out above.)
Now - given that understanding, I suggest that given this
declaration:
int arr[5];
that the expression
(&arr[0])
is also the address of the first element of 'arr' - do you not agree?
- 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-30 17:01 +0100 |
| Message-ID | <7fPEp.12138$El6.500@newsfe21.ams2> |
| In reply to | #5814 |
"Thomas David Rivers" <rivers@dignus.com> wrote in message news:4DE2D8FA.6@dignus.com... > Paul wrote: > >> >> "Thomas David Rivers" <rivers@dignus.com> wrote in message >> news:4DE252BD.8060100@dignus.com... >> >>> Paul wrote: >>> >>>>> >>>>>>> >>>>>>> >>>>>>> To return to that, do you agree that in this declaration: >>>>>>> >>>>>>> int arr[5]; >>>>>>> >>>>>>> 'arr' is the name of the contigous set of 5 `int' elements? >>>>>>> >>>>>>> And, to go to the next step, would you agree that in this >>>>>>> declaration: >>>>>>> >>>>>>> int i; >>>>>>> >>>>>>> `i' is the name of single `int'? >>>>>>> >>>>>> Yes I agree, you may continue. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> So - we should then consider something fairly important... what does >>>>> "name" mean? >>>>> >>>>> I would ask that we consider the 'name' of something to be the >>>>> designation of the location that contains that 'something'. And, I >>>>> want >>>>> to movitave that definition with the following scenario. >>>>> >>>>> If we can imagine that variables, in the C/C++ sense, are simply >>>>> "boxes" that contain their values - like shoeboxes on a shelf, >>>>> then the "name" associated with the variable is simply the name >>>>> associated with a "box." Let's imagine that this shelf can contain >>>>> many boxes, and that the boxes are numbered... box #0, box #1, box >>>>> #2.. >>>>> >>>>> A box can be referred to by its number - its location on the shelf, or >>>>> if >>>>> we associate a name with a box #; we can use the name. For example, >>>>> box #51 might have the name `i' associated with it. >>>>> >>>>> Thus, if we consider this snippet of C code: >>>>> >>>>> >>>>> int i; >>>>> i = 5; >>>>> >>>>> the semantics of that would be something similar to: >>>>> >>>>> define a box name 'i', allocate space for it, let's say that is box >>>>> #51, associate >>>>> location #51 with the name 'i'. >>>>> >>>>> produce the manifest `int' constant 5 >>>>> Find the box with the name 'i', oh - it's box #51. >>>>> store the manifest constant 5 into box #51. >>>>> >>>>> >>>>> >>>>> Similarly, the snippet: >>>>> >>>>> int i,j; >>>>> i = j; >>>>> >>>>> might be realized in this way: >>>>> >>>>> define a box named 'i' that can contain int-typed objects, say, box >>>>> #51. >>>>> define a box named 'j' that can contain int-typed objects, say, box >>>>> #52. >>>>> >>>>> Given the name 'j'; find its box - oh - it's box #52. >>>>> Retrieve (fetch) the value from box #52. >>>>> Given the name 'i'; find its box - oh - it's box #51. >>>>> Store the value previously fetched value into box #51. >>>>> >>>>> >>>>> So far, I've only talked about boxes that can contain `int'-typed >>>>> values. >>>>> >>>>> Let's introduce a new box, and say that it can contain the location >>>>> (the box #) >>>>> of another box, and the other box can contain `int'-typed values. We >>>>> would >>>>> call this new box a "pointer" to an `int'-typed box, because it >>>>> doesn't contain >>>>> the `int'-type value itself, but instead tells us the location (the >>>>> box #) of the >>>>> value. >>>>> >>>>> Now - let's consider this: >>>>> >>>>> int *ip; >>>>> int i; >>>>> >>>>> ip = &i; >>>>> >>>>> in this mindset - what does this mean? To discuss this, we need to >>>>> define >>>>> the &-operator. Le's say that the &-operator is named 'address of' >>>>> and that >>>>> it returns the location (the box #) of its operand. Say, for >>>>> example, if `i' >>>>> happened to be box #51, then the expression "&i" would produce >>>>> location #51. >>>>> >>>>> Remember - I can have two kinds of boxes on my shelf, boxes that >>>>> contain >>>>> `int'-typed values, and boxes that contain the location of other >>>>> `int'-typed boxes. >>>>> So, &i doesn't produce an `int'-typed value, it produces a location. >>>>> In this >>>>> example, it produced #51. (I have been careful to use '#' to >>>>> indicate location numbers >>>>> instead of simple `int'-typed values.. this distinction will become >>>>> important.) >>>>> >>>>> So - the semantics of that statement would be (if I may be so bold >>>>> as to be a little loose on the details): >>>>> >>>>> define a box named 'ip' - it can contain the location of other >>>>> `int'-typed boxes, >>>>> let's say it is box #52. >>>>> define a box named 'i' - it can contain `int' values, let's say it's >>>>> box #51. >>>>> >>>>> Apply the &-operator to the box named `i' - oh - i is box #51, so &i >>>>> produces >>>>> the location #51. >>>>> Look up the name `ip - oh - that's box #52. >>>>> Store our previously found location (#51) into box #52. >>>>> >>>>> >>>>> OK - now - let's say that I happen to buy my boxes from a manufacturer >>>>> that >>>>> can only make 2-kinds of boxes, those boxes that can contain `int' >>>>> elements, >>>>> and those boxes that can contain the location of other boxes that >>>>> contain >>>>> `int' elements. (that is, `int' boxes and `int *' boxes). >>>>> So, let's look at this: >>>>> >>>>> int *ip; >>>>> int arr[5]; >>>>> >>>>> >>>>> What can this do? I propose it does the following: >>>>> >>>>> define a box named 'ip', that box is allowed to contain the >>>>> location of >>>>> other `int'-type boxes; let's say that is box #52. >>>>> define a space of 5 boxes, each of these boxes is on the shelf >>>>> starting >>>>> at, say, location #53. Each of these boxes is an `int'-typed >>>>> box. The >>>>> boxes are contiguous, starting a location #53 and going thru >>>>> location >>>>> #57 (inclusive.) Since `arr' (at the C/C++ level) is a single >>>>> object, >>>>> the location associated with `arr' is #53 (the start of the 5 >>>>> contiguous >>>>> boxes on the shelf.) >>>>> >>>>> That is, in this scenario, the location of 'ip' is box #52, the >>>>> location of 'arr' >>>>> is box #53. `ip' uses one box, `arr' uses 5 boxes. >>>>> >>>>> With this, we can provide a definition of "name".... the "name" of the >>>>> variable >>>>> provides a mechanism for finding precisely which "box" (the box #, or >>>>> location >>>>> of the box) houses the value of the variable. The "name" is nothing >>>>> more than >>>>> a convenience for mapping the location of the variable. >>>>> So - in our example, the name 'ip' is asociated with box #52, the name >>>>> 'arr' >>>>> is associated with box #53. >>>>> >>>>> Before I go on, I want to check to see if you agree with everything so >>>>> far... >>>>> >>>> I agree with you that the "name" provides a mechanisn for mapping the >>>> location but.... >>>> The names 'i', 'ip' and 'arr' have different name mechanisms. >>>> The name 'i' refers to box#51, when used in an expression it evaluates >>>> to whatever is contained in box#51. >>>> The name 'ip' refers to box#52, it evaluates to whatever is contained >>>> in box#52. >>>> >>>> The name 'arr' refers to box#53.... but it does not evaluate to the >>>> contents of box#53. It evaluates to the address of box#53. >>>> >>> >>> I left all of the context above, so we have something to refer to.... >>> >>> And - yes - you are absolutely right... the name 'arr' refers to the >>> start of >>> the array... that is; as you correctly point out above; 'arr' would >>> refer to box #53. >>> To echo your statement, the name 'arr' does not refer to the contents of >>> boxes #53 thru #57 - it, in many contexts, refers to the location #53. >>> Similarly, the name 'ip' denotes box #52... but, as you correctly point >>> out, >>> the context in which the name is referenced is key to understanding what >>> is >>> happening. >>> >>> For example, in this snippet: >>> >>> int i, j; >>> i = j; >>> >>> On the right-hand-side of the assignment operator, we find 'j' - that >>> refers >>> to the contents of the box at the location associated with the name 'j'. >>> In C, we call >>> that an "rvalue". On the left-hand-side, we find 'i'. That refers to >>> the location of 'i', >>> the location used for storing the value computed on the right-hand-side. >>> In C, we call than an "lvalue". Note that, in both instances, the >>> names do refer to the location >>> of the boxes - it is simply what is done with that location that >>> changes. In the rvalue >>> context, we fetch the contents of the box, on the lvalue side, we store >>> the value into >>> the box. >>> >>> (Note that 'j' in the assignment expression is first an "lvalue" and is >>> converted >>> into an "rvalue" by the rules of the language. It is this treatment >>> that indicates >>> that the value is to be retrieved from the box.) >>> >>> As you mentioned above, the context is critical to understanding what is >>> going >>> on. I commend you on recognizing that distinction. >>> >>> Thus - we now need to consider what it means in C/C++ when we encounter >>> an expression using the name of an array. >>> >>> The way this is encapsulated in the C/C++ language is the rule regarding >>> conversion of an lvalue with an array type to a pointer to the first >>> element >>> of the array. >>> >>> So - if we now consider this: >>> >>> int *ip; >>> int arr[5]; >>> >>> ip = arr; >>> >>> What would happen in our "shoebox" world? If we use your absolutely >>> correct >>> observation, then it would be this: >>> >>> define a box named "ip", say - box #52 - that box can contain the >>> location of >>> other `int'-typed boxes >>> define a space of 5 boxes, beginning at box #53 thru box #57; name >>> that >>> area 'arr' by associating 'arr' with box #53 >>> >>> Now - how do we evaluate the expression "arr" in the context of the >>> assignment statement? Well, according to the C language rules, when >>> you discover an lvalue that has a type 'array'; you convert that into >>> the address of its first element. >>> >>> Thus, we can say that: >>> >>> ip = arr; >>> >>> can be evaluated as: >>> >>> Look up the name 'arr' - oh, it is an array of 5 `int'-typed boxes. >>> According >>> to the rules, in this context, we should produce the location of >>> the >>> first box of the array, that would be location #53. >>> Look up the name 'ip' - oh - that is a box (at location #52) that >>> can contain the location >>> of other `int'-typed boxes. >>> Store the value previously found location (#53) into box #52. >>> >>> As you had correctly forseen, we are able to evaluate this using the >>> rules >>> of the programming language. >>> >>> Note that, there wasn't a "extra" shoebox allocated/needed to produce >>> the result. >>> >>> Note that the 'name' did not mean some other space was allocated... it >>> simply >>> refers to the location, as we have previously shown/agreed to. >>> >> >> This behaviour is different to other C++ names. >> For example given the name of an int or an int*: >> >> int x=7; >> int* p =7; >> >> When we use the names of a object in C++ we expect the the object to be >> addressed and the value accessed whether it be a read or write operation. >> With an arr the situation is different , when we use the name of an array >> we do not expect the array to be addressed , instead we expect a pointer >> to the array: >> int* = arr; >> >> The identifier or name 'arr' refers to an array of objects yet somehow >> its value is an address , not the same value as any of the objects it >> refers to. >> >> >> In C++ > > You are correct.. the reason for your correctness has been detailed > above. > > For arrays, there is a "special" rule.. this rule is only for arrays, the > rule > is that when the array name is used, it does not designate the entire > array, it designates the address of the first element. > > I am glad that you have reached this understanding, and that you have > expressed your agreement! > > That is, when you reference an array name, it does not denote the entire > array; nor is there any other special object that is created to point to > the > array - it is simply that the result of the reference is the address of > the > first element (which you pointed out above.) > > Now - given that understanding, I suggest that given this > declaration: > > int arr[5]; > > that the expression > > (&arr[0]) > > is also the address of the first element of 'arr' - do you not agree? > > Yes I agree.
[toc] | [prev] | [next] | [standalone]
| From | Thomas David Rivers <rivers@dignus.com> |
|---|---|
| Date | 2011-05-31 09:45 -0400 |
| Message-ID | <4DE4F114.9040801@dignus.com> |
| In reply to | #5832 |
Paul wrote:
>
> Yes I agree.
That's great!
So - now, given our understanding that an lvalue reference
to an array name is converted to be a pointer to the first element
of the array, we can examine things like array indexing (which
is really cool) and multiple dimension arrays...
I propose we take a look at array indexing... would that be interesting?
- 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-31 20:33 +0100 |
| Message-ID | <VnbFp.20543$f95.5956@newsfe02.ams2> |
| In reply to | #5903 |
"Thomas David Rivers" <rivers@dignus.com> wrote in message news:4DE4F114.9040801@dignus.com... > Paul wrote: > >> >> Yes I agree. > > > That's great! > > So - now, given our understanding that an lvalue reference > to an array name is converted to be a pointer to the first element > of the array, we can examine things like array indexing (which > is really cool) and multiple dimension arrays... > > I propose we take a look at array indexing... would that be interesting? > I agree given that an array name is converted to a pointer to the array and not ONLY to a first element of the array. Can you aggree that an array name converted to a pointer points to an array?
[toc] | [prev] | [next] | [standalone]
Page 8 of 21 — ← Prev page 1 … 6 7 [8] 9 10 … 21 Next page →
Back to top | Article view | comp.lang.c++
csiph-web