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 14 of 21 — ← Prev page 1 … 12 13 [14] 15 16 … 21 Next page →
| From | Michael Doubez <michael.doubez@free.fr> |
|---|---|
| Date | 2011-06-01 00:46 -0700 |
| Message-ID | <5ed7cb4a-f0ae-43d8-88db-4a47824d6edd@bl1g2000vbb.googlegroups.com> |
| In reply to | #5901 |
On 31 mai, 15:38, Leigh Johnston <le...@i42.co.uk> wrote: > On 31/05/2011 10:43, Michael Doubez wrote: > > On 31 mai, 05:39, Pete Becker<p...@versatilecoding.com> Â wrote: > >> On 2011-05-30 16:08:47 -1000, Paul said: > >>> "Leigh Johnston"<le...@i42.co.uk> Â wrote in message > >>>> On 29/05/2011 20:43, Paul wrote: > >>>> [snip] > >>>>> A pointer to an array of integer objects is of type int*. > >>>> Wrong; 'int*' is a pointer to a single 'int' not an array of 'int'. [snip] > > Well, to be totally fair, there is one occurrence where this is not > > true: > > int* p = new int[0]; > > p points to an array with no elements and p doesn't point to an int. > > 'p' is still a *pointer to an* 'int' even if it is not *pointing to* an > 'int'. We agree but you nonetheless need the value of the pointer to delete he array even though it doesn't *actually* point to an int. Well, just nitpicking. -- Michael
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-29 20:29 +0100 |
| Message-ID | <w8xEp.21468$8A7.19311@newsfe12.ams2> |
| In reply to | #5801 |
"Öö Tiib" <ootiib@hot.ee> wrote in message
news:c9cfe168-3af5-4573-b1d5-fdaafffa6198@p13g2000yqh.googlegroups.com...
On May 29, 2:50 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Öö Tiib" <oot...@hot.ee> wrote in message
>
> > "Joshua Maurice" <joshuamaur...@gmail.com> wrote in message
>
> > --His reason for believing so is one part of the C++ standard which
> > --mentions that array objects are not modifiable.
>
> > No you are incorrect. My opinion that the object 'arr' and the 5
> > contiguous
> > integer objects are different entites is bases on the fact that they
> > contain
> > contain different values.
>
> > in the following code:
> > int arr[5]={0};
> > std::cout<< arr;
> > std::cout<< arr[0];
>
> > The value accessed by arr is not any value that is stored within the 5
> > contiguous integer objects.
> > If 'arr' was truly the same as the 5 integer objects then it would store
> > the
> > same value.
>
> --Of course, arr stores all of them 5 integer objects. It is array after
> --all. Your example does not show it since ostream is not made to
> --display whole arrays. ostream can display a void* and that is into
> --what any array converts to as soon someone coughs at it (bloody legacy
> --from C). But we can help ostream out easily to accept int arrays too.
> --See:
>
> --#include<iostream>
>
> --/// Helping poor ostream to output int arrays
> -- template<int N>
> -- std::ostream& operator<<( std::ostream& o, int const (& a)[N] )
> -- {
> -- o << "{";
> -- for ( int i = 0; i < N; ++i )
> -- {
> -- o << a[i];
> -- if ( i < N-1 ) o << ",";
> -- }
> -- o << "}";
> -- return o;
> -- }
> --
> -- int main()
> -- {
> -- // Pauls code
> -- int arr[5]={0};
> -- std::cout << "arr =" << arr << std::endl;
> -- std::cout << "arr[0] =" << arr[0] << std::endl;
> -- // that is what arr converted to without our operator
> -- std::cout << "&arr[0] = " << &arr[0] << std::endl;
> -- }
>
> --The output is:
>
> --arr = {0,0,0,0,0}
> --arr[0] = 0
> --&arr[0] = 0012FF50
>
> -- arr is still array of 5 ints. Can't be Paul you are arguing even
> --against that?
>
> The problem is not just ostream operator << , its every operator in the
> C++
> language.
Yes. Lot of smart people have felt that it is a problem and made
classes to wrap raw arrays so to get rid of it in C++. Usage of raw
arrays in real C++ production code is relatively low these days.
> The identifier 'arr' is evaluated as an addresss in almost all situations
> except typeid and sizeof:
> int* p= arr; //This works
> int x = arr; //This does not work
--The 'p = arr' works, thanks to implicit arr to &arr[0] conversion. My
--template above does not accept 'p' as int array argument anymore since
--it is a true raw pointer unlike 'arr'. 'p' goes to cout as usual
--void*. The 'x = arr' should indeed not to work because assigning whole
--array to single int does not make sense.
> Also consider this :
> template <typename T>
> void foo(T t){
> std::cout<< typeid(t).name();}
>
> foo(arr);
> Given a free choice arr is passed as a pointer and not a reference.
--Yes. That is because C did not have references, so there were only two
--ways to pass arrays in C (1) as pointer to first element (+ size as
--separate argument) or (2) as member of struct. Both ways are indirect.
--So the C designer's felt that writing '&arr[0]' everytime they needed
--a pointer to first element of array too verbose syntax. C++ did not
--change that because one of objectives of C++ is making migrating from
--C to C++ as painless as possible and that is achieved by making most C
--code to compile with C++ compiler.
> The identifier 'arr' does not behave like identifiers to other objects in
> C++ it is somewhat special.
> I can agree that it is a non modifiable array-type object. But it does not
> identify an array in the same sense that other objects' names identify
> them,
> it indirectly identifies the array, because it must be dereferenced to
> access the array of objects that it identifies.
--Yes, the pointer to what array implicitly converts (as it only can)
--indirectly identifies the array. However array itself is located in
--memory exactly where it's elements are, starting from first element.
--Consider the code:
-- int arr[5]={0};
-- std::cout << "&arr[0] = " << &arr[0] << std::endl;
-- std::cout << "&arr = " << &arr << std::endl;
--By language rules the address of first element of array and address of
--array itself are same. So arr is object consisting of 5 ints and not a
--separate pointer-like object (residing in memory elsewhere) that
--points to the ints.
Its nothing to do with language rules its to do with the hardware abilities.
It is not possible to address an array as one complete entity, unless it's
size one or something silly.
An array is not an addressable object therefore in C++ an object
representation is created by the compiler .
[toc] | [prev] | [next] | [standalone]
| From | Joshua Maurice <joshuamaurice@gmail.com> |
|---|---|
| Date | 2011-05-29 23:11 -0700 |
| Message-ID | <1e302fdf-3e14-47ce-985f-0d6295622f4b@35g2000prp.googlegroups.com> |
| In reply to | #5801 |
On May 29, 7:21 am, Öö Tiib <oot...@hot.ee> wrote:
> Consider the code:
>
> Â Â Â int arr[5]={0};
> Â Â Â std::cout << "&arr[0] = " << &arr[0] << std::endl;
> Â Â Â std::cout << "&arr = " << &arr << std::endl;
>
> By language rules the address of first element of array and address of
> array itself are same.
Citation please? I am unaware of any rule that guarantees the
following:
#include <cassert>
int main()
{
int x[3];
int (*y)[3] = &x;
void* px = x;
void* py = y;
assert(px == py);
}
I think that this would be true on most desktops, but I am unsure if
this is guaranteed. I would guess that it is not.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-25 08:15 +1200 |
| Message-ID | <942hvfFuc5U3@mid.individual.net> |
| In reply to | #5446 |
On 05/25/11 08:04 AM, Paul wrote: > "Leigh Johnston"<leigh@i42.co.uk> wrote: >> On 24/05/2011 17:39, Paul wrote: >>> >>> What you say doesn't make sense. You say the compiler KNOWS the address >>> of the array(whether it be a relative address or otherwise is >>> irrelevant). >>> How does it KNOW this address? It cannot KNOW this address unless it >>> stores it someplace. >> >> What I said makes perfect sense if you are not dense. The address is >> calculated using an offset to something else (such as a stack frame >> pointer or a 'this' pointer). For example for an array on the stack the >> compiler KNOWS that array element n is located at stack frame pointer + o >> bytes; if n is a constant then o can be a constant known at compile time; >> if n is not a constant then all we need is a simple effective address >> calculation involving the stack frame pointer, n and the sizeof an element >> to determine the address of element n. >> > The address cannot be calculated with random numbers. The address must be > known, whether it is known as an offset or a real address is irrelevant. > This known address must be stored in an object someplace. On most common implementations, that place is the (or a) stack pointer. Why do find this so hard? or are you being deliberately obtuse? If I write "int n;" do you expect there to be some mythical object storing the address of n? Now here's the big one: If there is an object that stores the address, where is the address of that object stored? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-24 22:23 +0100 |
| Message-ID | <7lVCp.23666$%o4.10407@newsfe16.ams2> |
| In reply to | #5449 |
"Ian Collins" <ian-news@hotmail.com> wrote in message news:942hvfFuc5U3@mid.individual.net... > On 05/25/11 08:04 AM, Paul wrote: >> "Leigh Johnston"<leigh@i42.co.uk> wrote: >>> On 24/05/2011 17:39, Paul wrote: >>>> >>>> What you say doesn't make sense. You say the compiler KNOWS the address >>>> of the array(whether it be a relative address or otherwise is >>>> irrelevant). >>>> How does it KNOW this address? It cannot KNOW this address unless it >>>> stores it someplace. >>> >>> What I said makes perfect sense if you are not dense. The address is >>> calculated using an offset to something else (such as a stack frame >>> pointer or a 'this' pointer). For example for an array on the stack the >>> compiler KNOWS that array element n is located at stack frame pointer + >>> o >>> bytes; if n is a constant then o can be a constant known at compile >>> time; >>> if n is not a constant then all we need is a simple effective address >>> calculation involving the stack frame pointer, n and the sizeof an >>> element >>> to determine the address of element n. >>> >> The address cannot be calculated with random numbers. The address must be >> known, whether it is known as an offset or a real address is irrelevant. >> This known address must be stored in an object someplace. > > On most common implementations, that place is the (or a) stack pointer. > > Why do find this so hard? or are you being deliberately obtuse? > > If I write "int n;" do you expect there to be some mythical object storing > the address of n? > But this is not the same : int n; int* arr[5]; std::cout<< n <<std::endl << arr; An integer will output an integer value , an array will output a memory address. An integer object is not the same as an array object in the context of this discussion. > Now here's the big one: > > If there is an object that stores the address, where is the address of > that object stored? > Yes thats about as big as your cock, and that's not very big at all. :)
[toc] | [prev] | [next] | [standalone]
| From | Joshua Maurice <joshuamaurice@gmail.com> |
|---|---|
| Date | 2011-05-24 17:01 -0700 |
| Message-ID | <35b6e7dd-dfe1-4e71-bd6c-e043adb79538@35g2000prp.googlegroups.com> |
| In reply to | #5454 |
On May 24, 2:23Â pm, "Paul" <pchris...@yahoo.co.uk> wrote: > "Ian Collins" <ian-n...@hotmail.com> wrote in message > > Now here's the big one: > > > If there is an object that stores the address, where is the address of > > that object stored? > > Yes thats about as big as your cock, and that's not very big at all. > :) Ok. A good legitimate question, and he entirely avoids it. He has to be a troll, or he's so hopelessly gone. Either way, I feel bad now about replying in such detail to him recently. I would just feel bad if someone else came along and read this, thinking that Paul knows what he's talking about. Duty Calls http://xkcd.com/386/ Ugg. This is supposed to be a useful resource for others, right? Suppose I'll have to strike the right balance. Correct him once a thread if he doesn't spam, and ignore him when he does spam.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-25 11:48 +0100 |
| Message-ID | <w85Dp.9257$8_2.1486@newsfe17.ams2> |
| In reply to | #5468 |
"Joshua Maurice" <joshuamaurice@gmail.com> wrote in message news:35b6e7dd-dfe1-4e71-bd6c-e043adb79538@35g2000prp.googlegroups.com... On May 24, 2:23 pm, "Paul" <pchris...@yahoo.co.uk> wrote: > "Ian Collins" <ian-n...@hotmail.com> wrote in message > > Now here's the big one: > > > If there is an object that stores the address, where is the address of > > that object stored? > > Yes thats about as big as your cock, and that's not very big at all. > :) --Ok. A good legitimate question, and he entirely avoids it. He has to --be a troll, or he's so hopelessly gone. Either way, I feel bad now --about replying in such detail to him recently. I would just feel bad --if someone else came along and read this, thinking that Paul knows --what he's talking about. If you think this is a legitimate point please raise it in the new thread and I will address it. This is a place where you can hide so why are you discussing here when there is a new thread that directly addresses this point?
[toc] | [prev] | [next] | [standalone]
| From | gwowen <gwowen@gmail.com> |
|---|---|
| Date | 2011-05-25 04:06 -0700 |
| Message-ID | <867459ba-6c2f-4736-baf9-28ef4a5de825@e8g2000vbz.googlegroups.com> |
| In reply to | #5468 |
On May 25, 1:01Â am, Joshua Maurice <joshuamaur...@gmail.com> wrote: > Ok. A good legitimate question, and he entirely avoids it. He has to > be a troll, or he's so hopelessly gone. How astute you are!
[toc] | [prev] | [next] | [standalone]
| From | Joshua Maurice <joshuamaurice@gmail.com> |
|---|---|
| Date | 2011-05-25 13:50 -0700 |
| Message-ID | <77189418-84ca-4dd7-96d9-b6acc8e3cdcb@s16g2000prf.googlegroups.com> |
| In reply to | #5487 |
On May 25, 4:06Â am, gwowen <gwo...@gmail.com> wrote: > On May 25, 1:01Â am, Joshua Maurice <joshuamaur...@gmail.com> wrote: > > > Ok. A good legitimate question, and he entirely avoids it. He has to > > be a troll, or he's so hopelessly gone. > > How astute you are! I'm naive and have too much hope sometimes. Sorry.
[toc] | [prev] | [next] | [standalone]
| From | "io_x" <a@b.c.invalid> |
|---|---|
| Date | 2011-05-25 19:03 +0200 |
| Message-ID | <4ddd361d$0$18236$4fafbaef@reader2.news.tin.it> |
| In reply to | #5372 |
"Paul" <pchristor@yahoo.co.uk> ha scritto nel messaggio
news:bHACp.25543$IL2.14423@newsfe04.ams2...
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
#include <stdio.h>
#include <stdlib.h>
#include <iostream.h>
int main(void)
{int arr[3] = {1,2,3}, arr1[3] = {4,5,6};
int *parr = arr;
int (*pparr)[3] = &arr;
printf("arr=%p a[0]=%d a[1]=%d a[2]=%d\n", arr, arr[0], arr[1], arr[2]);
std::cout<< "*parr=" << *parr << "\n";
//outputs 1 because it points to the first element of the array.
std::cout<< "*pparr=" << *pparr << "\n";
*parr=*arr1;
printf("arr=%p a[0]=%d a[1]=%d a[2]=%d\n", arr, arr[0], arr[1], arr[2]);
//outputs a memory address because it points to an array-type object.
return 0;
}
here print
arr=0012FF5C a[0]=1 a[1]=2 a[2]=3
*parr=1
*pparr=12ff5c
arr=0012FF5C a[0]=4 a[1]=2 a[2]=3
this "*parr=*arr1;" change only the first int
what follow
(*pparr)[3] for copy is a pointer to int and not a pointer to 3 ints
arr1 for copy is a pointer to int and not a pointer to 3 ints
for copy pparr and arr dacay to a pointer to int? yes
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-05-25 12:44 -0500 |
| Message-ID | <slrnitqfvi.10rf.aggedor@earl-grey.cloud9.net> |
| In reply to | #5372 |
On 2011-05-23, Paul <pchristor@yahoo.co.uk> wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrnitlb8j.1ruu.aggedor@earl-grey.cloud9.net...
>> On 2011-05-20, Paul <pchristor@yahoo.co.uk> wrote:
>>>
>>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>>> news:slrnitans0.14gr.aggedor@earl-grey.cloud9.net...
>>>> On 2011-05-18, Paul <pchristor@yahoo.co.uk> wrote:
[snip]
> When you dereference a pointer to int you access the pointed to integer
> object like so :
> int x=5;
> int* px = &x;
> std::cout<< *px;
> //this will output 5 because dereferencing px accesses the object it points
> to.
>
>
> With an array the situation is not the same becasue an array cannot be
> accessed, as a whole. The only way we can point to an array is to point to
> one of its elements.
> int arr[3] = {1,2,3};
> int* parr = arr;
> int (*pparr)[3] = &arr;
>
> std::cout<< *parr;
> //outputs 1 because it points to the first element of the array.
> std::cout<<*pparr;
> //outputs a memory address because it points to an array-type object.
The situation with the unary * and unary & operators is the same for
an array and for a non-array. The C++ standard does not specify
different behaviors depending on whether the operand of the unary *
and unary & operators is an array or non-array.
Here is the paragraph from the C++ standard about the unary *
operator.
The unary * operator performs indirection: the expression to which
it is applied shall be a pointer to an object type, or a pointer to
a function type and the result is an lvalue referring to the object
or function to which the expression points. If the type of the
expression is "pointer to T", the type of the result is "T".
[Note: a pointer to an incomplete type (other than cv void ) can be
dereferenced. The lvalue thus obtained can be used in limited ways
(to initialize a reference, for example); this lvalue must not be
converted to an rvalue, see 4.1. ]
The C++ standard does not specify different behaviors for an array
and a non-array with the unary * operator.
Here is the paragraph from the C++ standard about the unary &
operator.
The result of the unary & operator is a pointer to its operand.
The operand shall be an lvalue or a qualified-id. In the first
case, if the type of the expression is "T", the type of the result
is "pointer to T". In particular, the address of an object of type
"cv T" is "pointer to cv T", with the same cv-qualifiers. For a
qualified-id, if the member is a static member of type "T", the
type of the result is plain "pointer to T". If the member is
a nonstatic member of class C of type T, the type of the result is
"pointer to member of class C of type T." [Example:
struct A { int i; };
struct B : A { };
... &B::i ... // has type int A::*
--end example] [Note: a pointer to member formed from a mutable
nonstatic data member (7.1.1) does not reflect the mutable
specifier associated with the nonstatic data member. ]
The C++ standard does not specify different behaviors for an array
and a non-array with the unary & operator.
A difference with array and non-array results is that
array-to-pointer conversion is applied to an array result.
In your example, the statement
int* parr = arr;
implicitly applies array-to-pointer conversion to the array result of
the expression arr. The result of that conversion is a pointer to
the first element of arr, not a pointer to arr. Because parr is a
pointer to int, the result of dereferencing it is an int.
In your example, the statement
int (*pparr)[3] = &arr;
initializes pparr with a pointer to arr, not a pointer to an element
of arr. Because pparr is a pointer to an array of int, the result of
dereferencing it is an array of int. Array-to-pointer conversion is
implicitly applied to that result and the result of the conversion
is a pointer to int that points to the first element of arr.
> An array identifier such as 'arr' is an array-type object. A pointer to this
> object points to a single object, not to an array of thi sobject type.
The result of using the identifier 'arr' in an expression is an
array. An array is a single object that contains sub-objects. The
expression &arr points to the object that is the array named arr.
>> Given the declaration
>>
>> int arr[4];
>>
>> a C++ implementaion creates an array object to represent the array,
>> but it does not also create an object that stores a pointer to the
>> array object, unless one is explicitly present, say due to the
>> declaration
>>
>> int (*pparr)[4] = &arr;
>>
>> Due to that statement a C++ implementation creates a pointer to
>> array object that is initialized to point to the array. The
>> pointer points directly to the array object.
>
> The pointer pparr above points to a single object not an array of objects.
> Consider this:
>
> int (*p)[3]=0;
> std::cout<<*p<<std::endl;
> std::cout<< typeid(*p).name()<<std::endl;
> std::cout<< sizeof(*p);
>
> Does the above pointer point to a valid object?
> Or is it completely UB because its dereferencing a null pointer?
Having the value of a pointer be the null pointer is valid. The
effect of dereferencing the null pointer is undefined.
>> A few followups ago I posted the code generated by a GNU C++ compiler
>> to show how an array object and a pointer to an array object were
>> implemented. I don't know of any compiler that adds an object that
>> stores a pointer to the array for each array. I don't know of
>> anything in the C++ standard that requires an object that stores
>> a pointer to an array for each array. If you do, please provide
>> details.
> An array object must store a pointer otherwise how does it know, where in
> memory, the array is?
In a previous post you asked: "So where does the memory address value
come from? Its not stored in the array of integer objects." My
answer was (see
http://groups.google.com/group/comp.lang.c++/msg/90a32f760cdfc958?hl=en)
Where the memory address comes from depends on where the
implementation decides to store the array. For example, an object
with automatic storage duration, such a non-static array declared
in a function, is allocated on the stack in an implementation that
uses a stack for automatic storage.
The compiler knows the compile-time constant offset in the stack
frame where it has decided to store the array. In places where a
program needs the memory address of the array, the compiler puts
in instructions to sum that compile-time constant offset and the
current value of the stack pointer.
In the last sentence, "stack pointer" should have been "stack
frame pointer".
For the program
void foo() {
int arr[4], (*pparr)[4];
pparr = &arr;
}
the assembler output of the GNU C++ compiler for the assignment
statement for an i686 system is
leal -20(%ebp), %eax
movl %eax, -4(%ebp)
The compiler has allocated arr at offset -20 in the stack frame and
pparr at offset -4 in the stack frame. The assembler instructions
store in pparr the sum of -20 and the stack frame address.
Determining the address of arr did not use a value stored in an
object.
[snip]
>> Avoiding the term "array-type" that you use but the C++ standard
>> doesn't: the object pointed to by pparr is an array. The type of
>> the object pointed to is an array of int. As with all arrays in C++,
>> in some contexts, array-to-pointer conversion is implicitly applied
>> and the result of the conversion is a pointer to the first element of
>> the array.
>>
> No the C++ standard states its an array type object.
>
> The object pointed to is an array TYPE.
That's right, pparr points to an array type object, an object that
stores an array (the one named arr, in this case). pparr does not
point to an object that stores the address of an array.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-25 21:04 +0100 |
| Message-ID | <EhdDp.18482$6K4.3422@newsfe14.ams2> |
| In reply to | #5515 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
news:slrnitqfvi.10rf.aggedor@earl-grey.cloud9.net...
> [snip]
>> When you dereference a pointer to int you access the pointed to integer
>> object like so :
>> int x=5;
>> int* px = &x;
>> std::cout<< *px;
>> //this will output 5 because dereferencing px accesses the object it
>> points
>> to.
>>
>>
>> With an array the situation is not the same becasue an array cannot be
>> accessed, as a whole. The only way we can point to an array is to point
>> to
>> one of its elements.
>> int arr[3] = {1,2,3};
>> int* parr = arr;
>> int (*pparr)[3] = &arr;
>>
>> std::cout<< *parr;
>> //outputs 1 because it points to the first element of the array.
>> std::cout<<*pparr;
>> //outputs a memory address because it points to an array-type object.
>
> The situation with the unary * and unary & operators is the same for
> an array and for a non-array. The C++ standard does not specify
> different behaviors depending on whether the operand of the unary *
> and unary & operators is an array or non-array.
>
> Here is the paragraph from the C++ standard about the unary *
> operator.
>
> The unary * operator performs indirection: the expression to which
> it is applied shall be a pointer to an object type, or a pointer to
> a function type and the result is an lvalue referring to the object
> or function to which the expression points. If the type of the
> expression is "pointer to T", the type of the result is "T".
> [Note: a pointer to an incomplete type (other than cv void ) can be
> dereferenced. The lvalue thus obtained can be used in limited ways
> (to initialize a reference, for example); this lvalue must not be
> converted to an rvalue, see 4.1. ]
>
> The C++ standard does not specify different behaviors for an array
> and a non-array with the unary * operator.
>
> Here is the paragraph from the C++ standard about the unary &
> operator.
>
> The result of the unary & operator is a pointer to its operand.
> The operand shall be an lvalue or a qualified-id. In the first
> case, if the type of the expression is "T", the type of the result
> is "pointer to T". In particular, the address of an object of type
> "cv T" is "pointer to cv T", with the same cv-qualifiers. For a
> qualified-id, if the member is a static member of type "T", the
> type of the result is plain "pointer to T". If the member is
> a nonstatic member of class C of type T, the type of the result is
> "pointer to member of class C of type T." [Example:
>
> struct A { int i; };
> struct B : A { };
> ... &B::i ... // has type int A::*
>
> --end example] [Note: a pointer to member formed from a mutable
> nonstatic data member (7.1.1) does not reflect the mutable
> specifier associated with the nonstatic data member. ]
>
> The C++ standard does not specify different behaviors for an array
> and a non-array with the unary & operator.
>
> A difference with array and non-array results is that
> array-to-pointer conversion is applied to an array result.
>
> In your example, the statement
>
> int* parr = arr;
>
> implicitly applies array-to-pointer conversion to the array result of
> the expression arr. The result of that conversion is a pointer to
> the first element of arr, not a pointer to arr. Because parr is a
> pointer to int, the result of dereferencing it is an int.
>
> In your example, the statement
>
> int (*pparr)[3] = &arr;
>
> initializes pparr with a pointer to arr, not a pointer to an element
> of arr. Because pparr is a pointer to an array of int, the result of
> dereferencing it is an array of int. Array-to-pointer conversion is
> implicitly applied to that result and the result of the conversion
> is a pointer to int that points to the first element of arr.
>
>> An array identifier such as 'arr' is an array-type object. A pointer to
>> this
>> object points to a single object, not to an array of thi sobject type.
>
> The result of using the identifier 'arr' in an expression is an
> array. An array is a single object that contains sub-objects. The
> expression &arr points to the object that is the array named arr.
>
>>> Given the declaration
>>>
>>> int arr[4];
>>>
>>> a C++ implementaion creates an array object to represent the array,
>>> but it does not also create an object that stores a pointer to the
>>> array object, unless one is explicitly present, say due to the
>>> declaration
>>>
>>> int (*pparr)[4] = &arr;
>>>
>>> Due to that statement a C++ implementation creates a pointer to
>>> array object that is initialized to point to the array. The
>>> pointer points directly to the array object.
>>
>> The pointer pparr above points to a single object not an array of
>> objects.
>> Consider this:
>>
>> int (*p)[3]=0;
>> std::cout<<*p<<std::endl;
>> std::cout<< typeid(*p).name()<<std::endl;
>> std::cout<< sizeof(*p);
>>
>> Does the above pointer point to a valid object?
>> Or is it completely UB because its dereferencing a null pointer?
>
> Having the value of a pointer be the null pointer is valid. The
> effect of dereferencing the null pointer is undefined.
>
>>> A few followups ago I posted the code generated by a GNU C++ compiler
>>> to show how an array object and a pointer to an array object were
>>> implemented. I don't know of any compiler that adds an object that
>>> stores a pointer to the array for each array. I don't know of
>>> anything in the C++ standard that requires an object that stores
>>> a pointer to an array for each array. If you do, please provide
>>> details.
>> An array object must store a pointer otherwise how does it know, where in
>> memory, the array is?
>
The post you have replied to up till here was not a post by me.
I believe the following is addressed toward sme.
> In a previous post you asked: "So where does the memory address value
> come from? Its not stored in the array of integer objects." My
> answer was (see
> http://groups.google.com/group/comp.lang.c++/msg/90a32f760cdfc958?hl=en)
>
> Where the memory address comes from depends on where the
> implementation decides to store the array. For example, an object
> with automatic storage duration, such a non-static array declared
> in a function, is allocated on the stack in an implementation that
> uses a stack for automatic storage.
>
> The compiler knows the compile-time constant offset in the stack
> frame where it has decided to store the array. In places where a
> program needs the memory address of the array, the compiler puts
> in instructions to sum that compile-time constant offset and the
> current value of the stack pointer.
>
> In the last sentence, "stack pointer" should have been "stack
> frame pointer".
>
> For the program
>
> void foo() {
> int arr[4], (*pparr)[4];
>
> pparr = &arr;
> }
>
> the assembler output of the GNU C++ compiler for the assignment
> statement for an i686 system is
>
> leal -20(%ebp), %eax
> movl %eax, -4(%ebp)
This is a very tiny piece of code and the compiler is allowed to optimise
this .
Look at some asm code where an array is passed to a function and you will
see what the value pushed onto the stack is.
Here is a simple program:
void foo(int* p){ p[0]=7;}
int main(){
int arr[5]={0};
foo(arr);
}
And here is the asm output:
; Listing generated by Microsoft (R) Optimizing Compiler Version
14.00.50727.762
TITLE C:\cpp\public.cpp
.686P
.XMM
include listing.inc
.model flat
INCLUDELIB LIBCMT
INCLUDELIB OLDNAMES
PUBLIC ?foo@@YAXPAH@Z ; foo
; Function compile flags: /Odtp
_TEXT SEGMENT
_p$ = 8 ; size = 4
?foo@@YAXPAH@Z PROC ; foo
; File c:\cpp\public.cpp
; Line 3
push ebp
mov ebp, esp
; Line 4
mov eax, DWORD PTR _p$[ebp]
mov DWORD PTR [eax], 7
; Line 5
pop ebp
ret 0
?foo@@YAXPAH@Z ENDP ; foo
_TEXT ENDS
PUBLIC _main
; Function compile flags: /Odtp
_TEXT SEGMENT
/*************************************/
_arr$ = -20 ; size = 20
/************************************/
The above line is the array type object.
This is a pointer in asm because array type objects do not exist in asm.
/************************************/
_main PROC
; Line 7
push ebp
mov ebp, esp
sub esp, 20 ; 00000014H
; Line 8
mov DWORD PTR _arr$[ebp], 0
xor eax, eax
mov DWORD PTR _arr$[ebp+4], eax
mov DWORD PTR _arr$[ebp+8], eax
mov DWORD PTR _arr$[ebp+12], eax
mov DWORD PTR _arr$[ebp+16], eax
; Line 9
/**************************************/
lea ecx, DWORD PTR _arr$[ebp]
push ecx
/*************************************/
The above two lines push the address of the arrays first element onto the
stack prior to invokation of foo.
/*************************************/
call ?foo@@YAXPAH@Z ; foo
add esp, 4
; Line 11
xor eax, eax
mov esp, ebp
pop ebp
ret 0
_main ENDP
_TEXT ENDS
END
In the above asm listing arr is _arr$ , that is a pointer object that has
the value of -20.
>
> The compiler has allocated arr at offset -20 in the stack frame and
> pparr at offset -4 in the stack frame. The assembler instructions
> store in pparr the sum of -20 and the stack frame address.
> Determining the address of arr did not use a value stored in an
> object.
>
You example was so simple that the compiler has optimised the array object
into a temporary literal (-20).
> [snip]
>
>>> Avoiding the term "array-type" that you use but the C++ standard
>>> doesn't: the object pointed to by pparr is an array. The type of
>>> the object pointed to is an array of int. As with all arrays in C++,
>>> in some contexts, array-to-pointer conversion is implicitly applied
>>> and the result of the conversion is a pointer to the first element of
>>> the array.
>>>
>> No the C++ standard states its an array type object.
>>
>> The object pointed to is an array TYPE.
>
> That's right, pparr points to an array type object, an object that
> stores an array (the one named arr, in this case). pparr does not
> point to an object that stores the address of an array.
As shown in the asm listing _arr$ is an object with a value of -20. This is
a pointer object that points to the first element of the array, this object
stores the address of the array.
In C++ this object is not considered a pointer , it is an array type object.
The C++ standards refers to it as a non modifiable object of array type.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-25 22:20 +0100 |
| Message-ID | <2qidnbU2Ld0u70DQnZ2dnUVZ8t2dnZ2d@giganews.com> |
| In reply to | #5520 |
On 25/05/2011 21:04, Paul wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrnitqfvi.10rf.aggedor@earl-grey.cloud9.net...
>> [snip]
>>> When you dereference a pointer to int you access the pointed to integer
>>> object like so :
>>> int x=5;
>>> int* px = &x;
>>> std::cout<< *px;
>>> //this will output 5 because dereferencing px accesses the object it
>>> points
>>> to.
>>>
>>>
>>> With an array the situation is not the same becasue an array cannot be
>>> accessed, as a whole. The only way we can point to an array is to
>>> point to
>>> one of its elements.
>>> int arr[3] = {1,2,3};
>>> int* parr = arr;
>>> int (*pparr)[3] = &arr;
>>>
>>> std::cout<< *parr;
>>> //outputs 1 because it points to the first element of the array.
>>> std::cout<<*pparr;
>>> //outputs a memory address because it points to an array-type object.
>>
>> The situation with the unary * and unary & operators is the same for
>> an array and for a non-array. The C++ standard does not specify
>> different behaviors depending on whether the operand of the unary *
>> and unary & operators is an array or non-array.
>>
>> Here is the paragraph from the C++ standard about the unary *
>> operator.
>>
>> The unary * operator performs indirection: the expression to which
>> it is applied shall be a pointer to an object type, or a pointer to
>> a function type and the result is an lvalue referring to the object
>> or function to which the expression points. If the type of the
>> expression is "pointer to T", the type of the result is "T".
>> [Note: a pointer to an incomplete type (other than cv void ) can be
>> dereferenced. The lvalue thus obtained can be used in limited ways
>> (to initialize a reference, for example); this lvalue must not be
>> converted to an rvalue, see 4.1. ]
>>
>> The C++ standard does not specify different behaviors for an array
>> and a non-array with the unary * operator.
>>
>> Here is the paragraph from the C++ standard about the unary &
>> operator.
>>
>> The result of the unary & operator is a pointer to its operand.
>> The operand shall be an lvalue or a qualified-id. In the first
>> case, if the type of the expression is "T", the type of the result
>> is "pointer to T". In particular, the address of an object of type
>> "cv T" is "pointer to cv T", with the same cv-qualifiers. For a
>> qualified-id, if the member is a static member of type "T", the
>> type of the result is plain "pointer to T". If the member is
>> a nonstatic member of class C of type T, the type of the result is
>> "pointer to member of class C of type T." [Example:
>>
>> struct A { int i; };
>> struct B : A { };
>> ... &B::i ... // has type int A::*
>>
>> --end example] [Note: a pointer to member formed from a mutable
>> nonstatic data member (7.1.1) does not reflect the mutable
>> specifier associated with the nonstatic data member. ]
>>
>> The C++ standard does not specify different behaviors for an array
>> and a non-array with the unary & operator.
>>
>> A difference with array and non-array results is that
>> array-to-pointer conversion is applied to an array result.
>>
>> In your example, the statement
>>
>> int* parr = arr;
>>
>> implicitly applies array-to-pointer conversion to the array result of
>> the expression arr. The result of that conversion is a pointer to
>> the first element of arr, not a pointer to arr. Because parr is a
>> pointer to int, the result of dereferencing it is an int.
>>
>> In your example, the statement
>>
>> int (*pparr)[3] = &arr;
>>
>> initializes pparr with a pointer to arr, not a pointer to an element
>> of arr. Because pparr is a pointer to an array of int, the result of
>> dereferencing it is an array of int. Array-to-pointer conversion is
>> implicitly applied to that result and the result of the conversion
>> is a pointer to int that points to the first element of arr.
>>
>>> An array identifier such as 'arr' is an array-type object. A pointer
>>> to this
>>> object points to a single object, not to an array of thi sobject type.
>>
>> The result of using the identifier 'arr' in an expression is an
>> array. An array is a single object that contains sub-objects. The
>> expression &arr points to the object that is the array named arr.
>>
>>>> Given the declaration
>>>>
>>>> int arr[4];
>>>>
>>>> a C++ implementaion creates an array object to represent the array,
>>>> but it does not also create an object that stores a pointer to the
>>>> array object, unless one is explicitly present, say due to the
>>>> declaration
>>>>
>>>> int (*pparr)[4] = &arr;
>>>>
>>>> Due to that statement a C++ implementation creates a pointer to
>>>> array object that is initialized to point to the array. The
>>>> pointer points directly to the array object.
>>>
>>> The pointer pparr above points to a single object not an array of
>>> objects.
>>> Consider this:
>>>
>>> int (*p)[3]=0;
>>> std::cout<<*p<<std::endl;
>>> std::cout<< typeid(*p).name()<<std::endl;
>>> std::cout<< sizeof(*p);
>>>
>>> Does the above pointer point to a valid object?
>>> Or is it completely UB because its dereferencing a null pointer?
>>
>> Having the value of a pointer be the null pointer is valid. The
>> effect of dereferencing the null pointer is undefined.
>>
>>>> A few followups ago I posted the code generated by a GNU C++ compiler
>>>> to show how an array object and a pointer to an array object were
>>>> implemented. I don't know of any compiler that adds an object that
>>>> stores a pointer to the array for each array. I don't know of
>>>> anything in the C++ standard that requires an object that stores
>>>> a pointer to an array for each array. If you do, please provide
>>>> details.
>>> An array object must store a pointer otherwise how does it know,
>>> where in
>>> memory, the array is?
>>
> The post you have replied to up till here was not a post by me.
> I believe the following is addressed toward sme.
>
>> In a previous post you asked: "So where does the memory address value
>> come from? Its not stored in the array of integer objects." My
>> answer was (see
>> http://groups.google.com/group/comp.lang.c++/msg/90a32f760cdfc958?hl=en)
>>
>> Where the memory address comes from depends on where the
>> implementation decides to store the array. For example, an object
>> with automatic storage duration, such a non-static array declared
>> in a function, is allocated on the stack in an implementation that
>> uses a stack for automatic storage.
>>
>> The compiler knows the compile-time constant offset in the stack
>> frame where it has decided to store the array. In places where a
>> program needs the memory address of the array, the compiler puts
>> in instructions to sum that compile-time constant offset and the
>> current value of the stack pointer.
>>
>> In the last sentence, "stack pointer" should have been "stack
>> frame pointer".
>>
>> For the program
>>
>> void foo() {
>> int arr[4], (*pparr)[4];
>>
>> pparr = &arr;
>> }
>>
>> the assembler output of the GNU C++ compiler for the assignment
>> statement for an i686 system is
>>
>> leal -20(%ebp), %eax
>> movl %eax, -4(%ebp)
>
> This is a very tiny piece of code and the compiler is allowed to
> optimise this .
> Look at some asm code where an array is passed to a function and you
> will see what the value pushed onto the stack is.
> Here is a simple program:
>
> void foo(int* p){ p[0]=7;}
>
> int main(){
> int arr[5]={0};
> foo(arr);
> }
>
> And here is the asm output:
>
> ; Listing generated by Microsoft (R) Optimizing Compiler Version
> 14.00.50727.762
>
> TITLE C:\cpp\public.cpp
> .686P
> .XMM
> include listing.inc
> .model flat
>
> INCLUDELIB LIBCMT
> INCLUDELIB OLDNAMES
>
> PUBLIC ?foo@@YAXPAH@Z ; foo
> ; Function compile flags: /Odtp
> _TEXT SEGMENT
> _p$ = 8 ; size = 4
> ?foo@@YAXPAH@Z PROC ; foo
> ; File c:\cpp\public.cpp
> ; Line 3
> push ebp
> mov ebp, esp
> ; Line 4
> mov eax, DWORD PTR _p$[ebp]
> mov DWORD PTR [eax], 7
> ; Line 5
> pop ebp
> ret 0
> ?foo@@YAXPAH@Z ENDP ; foo
> _TEXT ENDS
> PUBLIC _main
> ; Function compile flags: /Odtp
> _TEXT SEGMENT
> /*************************************/
> _arr$ = -20 ; size = 20
>
> /************************************/
> The above line is the array type object.
> This is a pointer in asm because array type objects do not exist in asm.
> /************************************/
> _main PROC
> ; Line 7
> push ebp
> mov ebp, esp
> sub esp, 20 ; 00000014H
> ; Line 8
> mov DWORD PTR _arr$[ebp], 0
> xor eax, eax
> mov DWORD PTR _arr$[ebp+4], eax
> mov DWORD PTR _arr$[ebp+8], eax
> mov DWORD PTR _arr$[ebp+12], eax
> mov DWORD PTR _arr$[ebp+16], eax
> ; Line 9
> /**************************************/
> lea ecx, DWORD PTR _arr$[ebp]
> push ecx
> /*************************************/
> The above two lines push the address of the arrays first element onto
> the stack prior to invokation of foo.
> /*************************************/
> call ?foo@@YAXPAH@Z ; foo
> add esp, 4
> ; Line 11
> xor eax, eax
> mov esp, ebp
> pop ebp
> ret 0
> _main ENDP
> _TEXT ENDS
> END
>
>
> In the above asm listing arr is _arr$ , that is a pointer object that
> has the value of -20.
It is not a pointer object; it is a constant.
>
>
>>
>> The compiler has allocated arr at offset -20 in the stack frame and
>> pparr at offset -4 in the stack frame. The assembler instructions
>> store in pparr the sum of -20 and the stack frame address.
>> Determining the address of arr did not use a value stored in an
>> object.
>>
> You example was so simple that the compiler has optimised the array
> object into a temporary literal (-20).
>
>
>> [snip]
>>
>>>> Avoiding the term "array-type" that you use but the C++ standard
>>>> doesn't: the object pointed to by pparr is an array. The type of
>>>> the object pointed to is an array of int. As with all arrays in C++,
>>>> in some contexts, array-to-pointer conversion is implicitly applied
>>>> and the result of the conversion is a pointer to the first element of
>>>> the array.
>>>>
>>> No the C++ standard states its an array type object.
>>>
>>> The object pointed to is an array TYPE.
>>
>> That's right, pparr points to an array type object, an object that
>> stores an array (the one named arr, in this case). pparr does not
>> point to an object that stores the address of an array.
>
> As shown in the asm listing _arr$ is an object with a value of -20. This
> is a pointer object that points to the first element of the array, this
> object stores the address of the array.
As I have already told you else-thread it is not an object; it is not a
pointer object; it is an *offset* embedded in the text segment; thanks
for proving me correct and yourself incorrect.
>
> In C++ this object is not considered a pointer , it is an array type
> object. The C++ standards refers to it as a non modifiable object of
> array type.
It is not an "array type object"; it is an offset use to calculate the
address of the array of array element relative to the stack frame pointer.
HTH.
/Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-26 11:00 +0100 |
| Message-ID | <ZwpDp.33268$IL2.3671@newsfe04.ams2> |
| In reply to | #5534 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message
news:2qidnbU2Ld0u70DQnZ2dnUVZ8t2dnZ2d@giganews.com...
> On 25/05/2011 21:04, Paul wrote:
>>
>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>> news:slrnitqfvi.10rf.aggedor@earl-grey.cloud9.net...
>>> [snip]
>>>> When you dereference a pointer to int you access the pointed to integer
>>>> object like so :
>>>> int x=5;
>>>> int* px = &x;
>>>> std::cout<< *px;
>>>> //this will output 5 because dereferencing px accesses the object it
>>>> points
>>>> to.
>>>>
>>>>
>>>> With an array the situation is not the same becasue an array cannot be
>>>> accessed, as a whole. The only way we can point to an array is to
>>>> point to
>>>> one of its elements.
>>>> int arr[3] = {1,2,3};
>>>> int* parr = arr;
>>>> int (*pparr)[3] = &arr;
>>>>
>>>> std::cout<< *parr;
>>>> //outputs 1 because it points to the first element of the array.
>>>> std::cout<<*pparr;
>>>> //outputs a memory address because it points to an array-type object.
>>>
>>> The situation with the unary * and unary & operators is the same for
>>> an array and for a non-array. The C++ standard does not specify
>>> different behaviors depending on whether the operand of the unary *
>>> and unary & operators is an array or non-array.
>>>
>>> Here is the paragraph from the C++ standard about the unary *
>>> operator.
>>>
>>> The unary * operator performs indirection: the expression to which
>>> it is applied shall be a pointer to an object type, or a pointer to
>>> a function type and the result is an lvalue referring to the object
>>> or function to which the expression points. If the type of the
>>> expression is "pointer to T", the type of the result is "T".
>>> [Note: a pointer to an incomplete type (other than cv void ) can be
>>> dereferenced. The lvalue thus obtained can be used in limited ways
>>> (to initialize a reference, for example); this lvalue must not be
>>> converted to an rvalue, see 4.1. ]
>>>
>>> The C++ standard does not specify different behaviors for an array
>>> and a non-array with the unary * operator.
>>>
>>> Here is the paragraph from the C++ standard about the unary &
>>> operator.
>>>
>>> The result of the unary & operator is a pointer to its operand.
>>> The operand shall be an lvalue or a qualified-id. In the first
>>> case, if the type of the expression is "T", the type of the result
>>> is "pointer to T". In particular, the address of an object of type
>>> "cv T" is "pointer to cv T", with the same cv-qualifiers. For a
>>> qualified-id, if the member is a static member of type "T", the
>>> type of the result is plain "pointer to T". If the member is
>>> a nonstatic member of class C of type T, the type of the result is
>>> "pointer to member of class C of type T." [Example:
>>>
>>> struct A { int i; };
>>> struct B : A { };
>>> ... &B::i ... // has type int A::*
>>>
>>> --end example] [Note: a pointer to member formed from a mutable
>>> nonstatic data member (7.1.1) does not reflect the mutable
>>> specifier associated with the nonstatic data member. ]
>>>
>>> The C++ standard does not specify different behaviors for an array
>>> and a non-array with the unary & operator.
>>>
>>> A difference with array and non-array results is that
>>> array-to-pointer conversion is applied to an array result.
>>>
>>> In your example, the statement
>>>
>>> int* parr = arr;
>>>
>>> implicitly applies array-to-pointer conversion to the array result of
>>> the expression arr. The result of that conversion is a pointer to
>>> the first element of arr, not a pointer to arr. Because parr is a
>>> pointer to int, the result of dereferencing it is an int.
>>>
>>> In your example, the statement
>>>
>>> int (*pparr)[3] = &arr;
>>>
>>> initializes pparr with a pointer to arr, not a pointer to an element
>>> of arr. Because pparr is a pointer to an array of int, the result of
>>> dereferencing it is an array of int. Array-to-pointer conversion is
>>> implicitly applied to that result and the result of the conversion
>>> is a pointer to int that points to the first element of arr.
>>>
>>>> An array identifier such as 'arr' is an array-type object. A pointer
>>>> to this
>>>> object points to a single object, not to an array of thi sobject type.
>>>
>>> The result of using the identifier 'arr' in an expression is an
>>> array. An array is a single object that contains sub-objects. The
>>> expression &arr points to the object that is the array named arr.
>>>
>>>>> Given the declaration
>>>>>
>>>>> int arr[4];
>>>>>
>>>>> a C++ implementaion creates an array object to represent the array,
>>>>> but it does not also create an object that stores a pointer to the
>>>>> array object, unless one is explicitly present, say due to the
>>>>> declaration
>>>>>
>>>>> int (*pparr)[4] = &arr;
>>>>>
>>>>> Due to that statement a C++ implementation creates a pointer to
>>>>> array object that is initialized to point to the array. The
>>>>> pointer points directly to the array object.
>>>>
>>>> The pointer pparr above points to a single object not an array of
>>>> objects.
>>>> Consider this:
>>>>
>>>> int (*p)[3]=0;
>>>> std::cout<<*p<<std::endl;
>>>> std::cout<< typeid(*p).name()<<std::endl;
>>>> std::cout<< sizeof(*p);
>>>>
>>>> Does the above pointer point to a valid object?
>>>> Or is it completely UB because its dereferencing a null pointer?
>>>
>>> Having the value of a pointer be the null pointer is valid. The
>>> effect of dereferencing the null pointer is undefined.
>>>
>>>>> A few followups ago I posted the code generated by a GNU C++ compiler
>>>>> to show how an array object and a pointer to an array object were
>>>>> implemented. I don't know of any compiler that adds an object that
>>>>> stores a pointer to the array for each array. I don't know of
>>>>> anything in the C++ standard that requires an object that stores
>>>>> a pointer to an array for each array. If you do, please provide
>>>>> details.
>>>> An array object must store a pointer otherwise how does it know,
>>>> where in
>>>> memory, the array is?
>>>
>> The post you have replied to up till here was not a post by me.
>> I believe the following is addressed toward sme.
>>
>>> In a previous post you asked: "So where does the memory address value
>>> come from? Its not stored in the array of integer objects." My
>>> answer was (see
>>> http://groups.google.com/group/comp.lang.c++/msg/90a32f760cdfc958?hl=en)
>>>
>>> Where the memory address comes from depends on where the
>>> implementation decides to store the array. For example, an object
>>> with automatic storage duration, such a non-static array declared
>>> in a function, is allocated on the stack in an implementation that
>>> uses a stack for automatic storage.
>>>
>>> The compiler knows the compile-time constant offset in the stack
>>> frame where it has decided to store the array. In places where a
>>> program needs the memory address of the array, the compiler puts
>>> in instructions to sum that compile-time constant offset and the
>>> current value of the stack pointer.
>>>
>>> In the last sentence, "stack pointer" should have been "stack
>>> frame pointer".
>>>
>>> For the program
>>>
>>> void foo() {
>>> int arr[4], (*pparr)[4];
>>>
>>> pparr = &arr;
>>> }
>>>
>>> the assembler output of the GNU C++ compiler for the assignment
>>> statement for an i686 system is
>>>
>>> leal -20(%ebp), %eax
>>> movl %eax, -4(%ebp)
>>
>> This is a very tiny piece of code and the compiler is allowed to
>> optimise this .
>> Look at some asm code where an array is passed to a function and you
>> will see what the value pushed onto the stack is.
>> Here is a simple program:
>>
>> void foo(int* p){ p[0]=7;}
>>
>> int main(){
>> int arr[5]={0};
>> foo(arr);
>> }
>>
>> And here is the asm output:
>>
>> ; Listing generated by Microsoft (R) Optimizing Compiler Version
>> 14.00.50727.762
>>
>> TITLE C:\cpp\public.cpp
>> .686P
>> .XMM
>> include listing.inc
>> .model flat
>>
>> INCLUDELIB LIBCMT
>> INCLUDELIB OLDNAMES
>>
>> PUBLIC ?foo@@YAXPAH@Z ; foo
>> ; Function compile flags: /Odtp
>> _TEXT SEGMENT
>> _p$ = 8 ; size = 4
>> ?foo@@YAXPAH@Z PROC ; foo
>> ; File c:\cpp\public.cpp
>> ; Line 3
>> push ebp
>> mov ebp, esp
>> ; Line 4
>> mov eax, DWORD PTR _p$[ebp]
>> mov DWORD PTR [eax], 7
>> ; Line 5
>> pop ebp
>> ret 0
>> ?foo@@YAXPAH@Z ENDP ; foo
>> _TEXT ENDS
>> PUBLIC _main
>> ; Function compile flags: /Odtp
>> _TEXT SEGMENT
>> /*************************************/
>> _arr$ = -20 ; size = 20
>>
>> /************************************/
>> The above line is the array type object.
>> This is a pointer in asm because array type objects do not exist in asm.
>> /************************************/
>> _main PROC
>> ; Line 7
>> push ebp
>> mov ebp, esp
>> sub esp, 20 ; 00000014H
>> ; Line 8
>> mov DWORD PTR _arr$[ebp], 0
>> xor eax, eax
>> mov DWORD PTR _arr$[ebp+4], eax
>> mov DWORD PTR _arr$[ebp+8], eax
>> mov DWORD PTR _arr$[ebp+12], eax
>> mov DWORD PTR _arr$[ebp+16], eax
>> ; Line 9
>> /**************************************/
>> lea ecx, DWORD PTR _arr$[ebp]
>> push ecx
>> /*************************************/
>> The above two lines push the address of the arrays first element onto
>> the stack prior to invokation of foo.
>> /*************************************/
>> call ?foo@@YAXPAH@Z ; foo
>> add esp, 4
>> ; Line 11
>> xor eax, eax
>> mov esp, ebp
>> pop ebp
>> ret 0
>> _main ENDP
>> _TEXT ENDS
>> END
>>
>>
>> In the above asm listing arr is _arr$ , that is a pointer object that
>> has the value of -20.
>
> It is not a pointer object; it is a constant.
>
No Leigh it's a pointer.
Funny sense of Deja vu here.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-26 12:07 +0100 |
| Message-ID | <qNqdnRAjHt_CqUPQnZ2dnUVZ7tOdnZ2d@giganews.com> |
| In reply to | #5599 |
On 26/05/2011 11:00, Paul wrote: >>> >>> And here is the asm output: >>> >>> ; Listing generated by Microsoft (R) Optimizing Compiler Version >>> 14.00.50727.762 >>> >>> TITLE C:\cpp\public.cpp >>> .686P >>> .XMM >>> include listing.inc >>> .model flat >>> >>> INCLUDELIB LIBCMT >>> INCLUDELIB OLDNAMES >>> >>> PUBLIC ?foo@@YAXPAH@Z ; foo >>> ; Function compile flags: /Odtp >>> _TEXT SEGMENT >>> _p$ = 8 ; size = 4 >>> ?foo@@YAXPAH@Z PROC ; foo >>> ; File c:\cpp\public.cpp >>> ; Line 3 >>> push ebp >>> mov ebp, esp >>> ; Line 4 >>> mov eax, DWORD PTR _p$[ebp] >>> mov DWORD PTR [eax], 7 >>> ; Line 5 >>> pop ebp >>> ret 0 >>> ?foo@@YAXPAH@Z ENDP ; foo >>> _TEXT ENDS >>> PUBLIC _main >>> ; Function compile flags: /Odtp >>> _TEXT SEGMENT >>> /*************************************/ >>> _arr$ = -20 ; size = 20 >>> >>> /************************************/ >>> The above line is the array type object. >>> This is a pointer in asm because array type objects do not exist in asm. >>> /************************************/ >>> _main PROC >>> ; Line 7 >>> push ebp >>> mov ebp, esp >>> sub esp, 20 ; 00000014H >>> ; Line 8 >>> mov DWORD PTR _arr$[ebp], 0 >>> xor eax, eax >>> mov DWORD PTR _arr$[ebp+4], eax >>> mov DWORD PTR _arr$[ebp+8], eax >>> mov DWORD PTR _arr$[ebp+12], eax >>> mov DWORD PTR _arr$[ebp+16], eax >>> ; Line 9 >>> /**************************************/ >>> lea ecx, DWORD PTR _arr$[ebp] >>> push ecx >>> /*************************************/ >>> The above two lines push the address of the arrays first element onto >>> the stack prior to invokation of foo. >>> /*************************************/ >>> call ?foo@@YAXPAH@Z ; foo >>> add esp, 4 >>> ; Line 11 >>> xor eax, eax >>> mov esp, ebp >>> pop ebp >>> ret 0 >>> _main ENDP >>> _TEXT ENDS >>> END >>> >>> >>> In the above asm listing arr is _arr$ , that is a pointer object that >>> has the value of -20. >> >> It is not a pointer object; it is a constant. >> > No Leigh it's a pointer. No it is a constant; an offset used in conjunction with the stack frame pointer. You obviously do not understand assembly in addition to not understanding C++. > > Funny sense of Deja vu here. Indeed: your inability to learn from your mistakes leads to deja vu. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-26 13:09 +0100 |
| Message-ID | <2qrDp.5646$Tw4.3@newsfe26.ams2> |
| In reply to | #5606 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:qNqdnRAjHt_CqUPQnZ2dnUVZ7tOdnZ2d@giganews.com... > On 26/05/2011 11:00, Paul wrote: >>>> >>>> And here is the asm output: >>>> >>>> ; Listing generated by Microsoft (R) Optimizing Compiler Version >>>> 14.00.50727.762 >>>> >>>> TITLE C:\cpp\public.cpp >>>> .686P >>>> .XMM >>>> include listing.inc >>>> .model flat >>>> >>>> INCLUDELIB LIBCMT >>>> INCLUDELIB OLDNAMES >>>> >>>> PUBLIC ?foo@@YAXPAH@Z ; foo >>>> ; Function compile flags: /Odtp >>>> _TEXT SEGMENT >>>> _p$ = 8 ; size = 4 >>>> ?foo@@YAXPAH@Z PROC ; foo >>>> ; File c:\cpp\public.cpp >>>> ; Line 3 >>>> push ebp >>>> mov ebp, esp >>>> ; Line 4 >>>> mov eax, DWORD PTR _p$[ebp] >>>> mov DWORD PTR [eax], 7 >>>> ; Line 5 >>>> pop ebp >>>> ret 0 >>>> ?foo@@YAXPAH@Z ENDP ; foo >>>> _TEXT ENDS >>>> PUBLIC _main >>>> ; Function compile flags: /Odtp >>>> _TEXT SEGMENT >>>> /*************************************/ >>>> _arr$ = -20 ; size = 20 >>>> >>>> /************************************/ >>>> The above line is the array type object. >>>> This is a pointer in asm because array type objects do not exist in >>>> asm. >>>> /************************************/ >>>> _main PROC >>>> ; Line 7 >>>> push ebp >>>> mov ebp, esp >>>> sub esp, 20 ; 00000014H >>>> ; Line 8 >>>> mov DWORD PTR _arr$[ebp], 0 >>>> xor eax, eax >>>> mov DWORD PTR _arr$[ebp+4], eax >>>> mov DWORD PTR _arr$[ebp+8], eax >>>> mov DWORD PTR _arr$[ebp+12], eax >>>> mov DWORD PTR _arr$[ebp+16], eax >>>> ; Line 9 >>>> /**************************************/ >>>> lea ecx, DWORD PTR _arr$[ebp] >>>> push ecx >>>> /*************************************/ >>>> The above two lines push the address of the arrays first element onto >>>> the stack prior to invokation of foo. >>>> /*************************************/ >>>> call ?foo@@YAXPAH@Z ; foo >>>> add esp, 4 >>>> ; Line 11 >>>> xor eax, eax >>>> mov esp, ebp >>>> pop ebp >>>> ret 0 >>>> _main ENDP >>>> _TEXT ENDS >>>> END >>>> >>>> >>>> In the above asm listing arr is _arr$ , that is a pointer object that >>>> has the value of -20. >>> >>> It is not a pointer object; it is a constant. >>> >> No Leigh it's a pointer. > > No it is a constant; an offset used in conjunction with the stack frame > pointer. You obviously do not understand assembly in addition to not > understanding C++. > > Im assembly langauge a pointer is a variable whose value is the address, or offset, of some other memory location.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-26 09:32 +1200 |
| Message-ID | <945aqkFn9oU2@mid.individual.net> |
| In reply to | #5520 |
On 05/26/11 08:04 AM, Paul wrote:
>
> This is a very tiny piece of code and the compiler is allowed to optimise
> this .
> Look at some asm code where an array is passed to a function and you will
> see what the value pushed onto the stack is.
> Here is a simple program:
>
> void foo(int* p){ p[0]=7;}
>
> int main(){
> int arr[5]={0};
> foo(arr);
> }
>
> And here is the asm output:
>
> ; Listing generated by Microsoft (R) Optimizing Compiler Version
> 14.00.50727.762
>
> TITLE C:\cpp\public.cpp
> .686P
> .XMM
> include listing.inc
> .model flat
>
> INCLUDELIB LIBCMT
> INCLUDELIB OLDNAMES
>
> PUBLIC ?foo@@YAXPAH@Z ; foo
> ; Function compile flags: /Odtp
> _TEXT SEGMENT
> _p$ = 8 ; size = 4
> ?foo@@YAXPAH@Z PROC ; foo
> ; File c:\cpp\public.cpp
> ; Line 3
> push ebp
> mov ebp, esp
> ; Line 4
> mov eax, DWORD PTR _p$[ebp]
> mov DWORD PTR [eax], 7
> ; Line 5
> pop ebp
> ret 0
> ?foo@@YAXPAH@Z ENDP ; foo
> _TEXT ENDS
> PUBLIC _main
> ; Function compile flags: /Odtp
> _TEXT SEGMENT
> /*************************************/
> _arr$ = -20 ; size = 20
>
> /************************************/
> The above line is the array type object.
That's where you are very, very wrong. _arr$ is a constant with the
value -20. The MASM term is a "Manifest Constant", look it up.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-26 11:10 +0100 |
| Message-ID | <CGpDp.13978$Ky.12356@newsfe24.ams2> |
| In reply to | #5537 |
"Ian Collins" <ian-news@hotmail.com> wrote in message
news:945aqkFn9oU2@mid.individual.net...
> On 05/26/11 08:04 AM, Paul wrote:
>>
>> This is a very tiny piece of code and the compiler is allowed to optimise
>> this .
>> Look at some asm code where an array is passed to a function and you will
>> see what the value pushed onto the stack is.
>> Here is a simple program:
>>
>> void foo(int* p){ p[0]=7;}
>>
>> int main(){
>> int arr[5]={0};
>> foo(arr);
>> }
>>
>> And here is the asm output:
>>
>> ; Listing generated by Microsoft (R) Optimizing Compiler Version
>> 14.00.50727.762
>>
>> TITLE C:\cpp\public.cpp
>> .686P
>> .XMM
>> include listing.inc
>> .model flat
>>
>> INCLUDELIB LIBCMT
>> INCLUDELIB OLDNAMES
>>
>> PUBLIC ?foo@@YAXPAH@Z ; foo
>> ; Function compile flags: /Odtp
>> _TEXT SEGMENT
>> _p$ = 8 ; size = 4
>> ?foo@@YAXPAH@Z PROC ; foo
>> ; File c:\cpp\public.cpp
>> ; Line 3
>> push ebp
>> mov ebp, esp
>> ; Line 4
>> mov eax, DWORD PTR _p$[ebp]
>> mov DWORD PTR [eax], 7
>> ; Line 5
>> pop ebp
>> ret 0
>> ?foo@@YAXPAH@Z ENDP ; foo
>> _TEXT ENDS
>> PUBLIC _main
>> ; Function compile flags: /Odtp
>> _TEXT SEGMENT
>> /*************************************/
>> _arr$ = -20 ; size = 20
>>
>> /************************************/
>> The above line is the array type object.
>
> That's where you are very, very wrong. _arr$ is a constant with the
> value -20. The MASM term is a "Manifest Constant", look it up.
>
No _arr$ is a pointer.
Constantness is a term that defines whether it's modifiable or not. It may
be a constant pointer.
WTF is Manifest constant , and you accuse me of using terminology nobody
understands. Thats utter bullshit _arr$ is a pointer the same as px is a
pointer in the following:
int main(){
int x=5;
int* px= &x;
}
PUBLIC _main
; Function compile flags: /Odtp
_TEXT SEGMENT
_px$ = -8 ; size = 4
_x$ = -4 ; size = 4
_main PROC
; File c:\cpp\public.cpp
; Line 5
push ebp
mov ebp, esp
sub esp, 8
; Line 6
mov DWORD PTR _x$[ebp], 5
; Line 7
lea eax, DWORD PTR _x$[ebp]
mov DWORD PTR _px$[ebp], eax
; Line 8
xor eax, eax
mov esp, ebp
pop ebp
ret 0
_main ENDP
_TEXT ENDS
END
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-26 23:07 +1200 |
| Message-ID | <946qj4Fn9oU7@mid.individual.net> |
| In reply to | #5601 |
On 05/26/11 10:10 PM, Paul wrote: > "Ian Collins"<ian-news@hotmail.com> wrote: >> On 05/26/11 08:04 AM, Paul wrote: >>> _TEXT SEGMENT >>> /*************************************/ >>> _arr$ = -20 ; size = 20 >>> >>> /************************************/ >>> The above line is the array type object. >> >> That's where you are very, very wrong. _arr$ is a constant with the >> value -20. The MASM term is a "Manifest Constant", look it up. >> > No _arr$ is a pointer. > Constantness is a term that defines whether it's modifiable or not. It may > be a constant pointer. No, it is a constant value. How much x86 assembly programming have you actually done? Not a lot I'd guess. > WTF is Manifest constant , and you accuse me of using terminology nobody > understands. Thats utter bullshit _arr$ is a pointer the same as px is a > pointer in the following: Did you (I sometimes doubt if you are capable) bother to look it up? I know you find it hard, so I've done it for you: http://www.oopweb.com/Assembly/Documents/ArtOfAssembly/Volume/Chapter_8/CH08-1.html#HEADING1-206 -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-26 13:22 +0100 |
| Message-ID | <8CrDp.10555$2E6.4861@newsfe18.ams2> |
| In reply to | #5607 |
"Ian Collins" <ian-news@hotmail.com> wrote in message news:946qj4Fn9oU7@mid.individual.net... > On 05/26/11 10:10 PM, Paul wrote: >> "Ian Collins"<ian-news@hotmail.com> wrote: >>> On 05/26/11 08:04 AM, Paul wrote: > >>>> _TEXT SEGMENT >>>> /*************************************/ >>>> _arr$ = -20 ; size = 20 >>>> >>>> /************************************/ >>>> The above line is the array type object. >>> >>> That's where you are very, very wrong. _arr$ is a constant with the >>> value -20. The MASM term is a "Manifest Constant", look it up. >>> >> No _arr$ is a pointer. >> Constantness is a term that defines whether it's modifiable or not. It >> may >> be a constant pointer. > > No, it is a constant value. How much x86 assembly programming have you > actually done? Not a lot I'd guess. > >> WTF is Manifest constant , and you accuse me of using terminology nobody >> understands. Thats utter bullshit _arr$ is a pointer the same as px is a >> pointer in the following: > > Did you (I sometimes doubt if you are capable) bother to look it up? I > know you find it hard, so I've done it for you: > > http://www.oopweb.com/Assembly/Documents/ArtOfAssembly/Volume/Chapter_8/CH08-1.html#HEADING1-206 > > -- From the link you have posted you should refer to chapter 5.5 Pointer Data types. http://www.oopweb.com/Assembly/Documents/ArtOfAssembly/Volume/Chapter_5/CH05-1.html#HEADING1-197 "A pointer is simply a memory location whose value is the address (or index if you prefer) of some other memory location. Pointers are very easy to declare and use in an assembly language program. You don't even have to worry about array indices or anything like that. In fact the only complication you're going to run into is that the 80x86 supports two kinds of pointers: near pointers and far pointers. A near pointer is a 16 bit value that provides an offset into a segment. It could be any segment but you will generally use the data segment (dseg in SHELL.ASM). If you have a word variable p that contains 1000h then p "points" at memory location 1000h in dseg. To access the word that p points at you could use code like the following: " The pointer _arr$ happens to be an offset into the text segment, but this does not change the fact that it is a pointer. It's value is -20 , that is a memory index or an offset. A manifest constant is not a pointer. I found this thread discussing manifest constants where nobody had even heard of it before, including our friend Alf http://www.velocityreviews.com/forums/t677955-what-are-literal-values-and-symbolic-and-manifest-constants.html
[toc] | [prev] | [next] | [standalone]
Page 14 of 21 — ← Prev page 1 … 12 13 [14] 15 16 … 21 Next page →
Back to top | Article view | comp.lang.c++
csiph-web