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 15 of 21 — ← Prev page 1 … 13 14 [15] 16 17 … 21 Next page →
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-26 14:14 +0100 |
| Message-ID | <tYOdnZGgbM-8z0PQnZ2dnUVZ8madnZ2d@giganews.com> |
| In reply to | #5613 |
On 26/05/2011 13:22, Paul wrote: > > "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: " That is all fine and correct. > > The pointer _arr$ happens to be an offset into the text segment, but Yet again you are confusing different meanings of the term "segment". 'arr$' is certainly not a pointer and it is certainly not an offset into the text segment. > this does not change the fact that it is a pointer. > It's value is -20 , that is a memory index or an offset. '_arr$' is not a pointer in either sense (assembly or C++); '_arr$' is a constant, an offset used in conjunction with the stack frame pointer. <snip> YOU NEED TO READ TWO BOOKS: One on assembly language programming and one on C++ programming (or compiler design). HTH. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-26 15:27 +0100 |
| Message-ID | <FrtDp.23218$Am5.1433@newsfe05.ams2> |
| In reply to | #5617 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message
news:tYOdnZGgbM-8z0PQnZ2dnUVZ8madnZ2d@giganews.com...
> On 26/05/2011 13:22, Paul wrote:
>>
>> "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: "
>
> That is all fine and correct.
>
>>
>> The pointer _arr$ happens to be an offset into the text segment, but
>
> Yet again you are confusing different meanings of the term "segment".
> 'arr$' is certainly not a pointer and it is certainly not an offset into
> the text segment.
>
>> this does not change the fact that it is a pointer.
>> It's value is -20 , that is a memory index or an offset.
>
> '_arr$' is not a pointer in either sense (assembly or C++); '_arr$' is a
> constant, an offset used in conjunction with the stack frame pointer.
>
> <snip>
>
> YOU NEED TO READ TWO BOOKS: One on assembly language programming and one
> on C++ programming (or compiler design).
>
arr is a pointer , the same as px in the following code:
int main(){
int x=5;
int arr[3];
int* px= &x;
px=arr;
}
; 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 _main
; Function compile flags: /Odtp
_TEXT SEGMENT
_px$ = -20 ; size = 4
_arr$ = -16 ; size = 12
_x$ = -4 ; size = 4
_main PROC
; File c:\cpp\public.cpp
; Line 5
push ebp
mov ebp, esp
sub esp, 20 ; 00000014H
; Line 6
mov DWORD PTR _x$[ebp], 5
; Line 8
lea eax, DWORD PTR _x$[ebp]
mov DWORD PTR _px$[ebp], eax
; Line 9
lea ecx, DWORD PTR _arr$[ebp]
mov DWORD PTR _px$[ebp], ecx
; Line 10
xor eax, eax
mov esp, ebp
pop ebp
ret 0
_main ENDP
_TEXT ENDS
END
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-26 15:52 +0100 |
| Message-ID | <L5-dnTeJldna9EPQnZ2dnUVZ8kCdnZ2d@giganews.com> |
| In reply to | #5620 |
On 26/05/2011 15:27, Paul wrote:
>
> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
> news:tYOdnZGgbM-8z0PQnZ2dnUVZ8madnZ2d@giganews.com...
>> On 26/05/2011 13:22, Paul wrote:
>>>
>>> "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: "
>>
>> That is all fine and correct.
>>
>>>
>>> The pointer _arr$ happens to be an offset into the text segment, but
>>
>> Yet again you are confusing different meanings of the term "segment".
>> 'arr$' is certainly not a pointer and it is certainly not an offset
>> into the text segment.
>>
>>> this does not change the fact that it is a pointer.
>>> It's value is -20 , that is a memory index or an offset.
>>
>> '_arr$' is not a pointer in either sense (assembly or C++); '_arr$' is
>> a constant, an offset used in conjunction with the stack frame pointer.
>>
>> <snip>
>>
>> YOU NEED TO READ TWO BOOKS: One on assembly language programming and
>> one on C++ programming (or compiler design).
>>
> arr is a pointer , the same as px in the following code:
No it isn't. Just because similar assembly is produced for
dereferencing a pointer on the stack and accessing an array element on
the stack that doesn't mean that a stack frame pointer offset (constant)
is a pointer.
Basically you don't have one iota of a clue. You are clueless when it
comes to both assembly and how C++ compilers are implemented; you need
to read books to overcome this cluelessness and to stop yourself from
looking like such a fool in this newsgroup.
>
> int main(){
> int x=5;
> int arr[3];
> int* px= &x;
> px=arr;
> }
>
>
> ; 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 _main
> ; Function compile flags: /Odtp
> _TEXT SEGMENT
> _px$ = -20 ; size = 4
> _arr$ = -16 ; size = 12
> _x$ = -4 ; size = 4
> _main PROC
> ; File c:\cpp\public.cpp
> ; Line 5
> push ebp
> mov ebp, esp
> sub esp, 20 ; 00000014H
> ; Line 6
> mov DWORD PTR _x$[ebp], 5
> ; Line 8
> lea eax, DWORD PTR _x$[ebp]
> mov DWORD PTR _px$[ebp], eax
> ; Line 9
> lea ecx, DWORD PTR _arr$[ebp]
> mov DWORD PTR _px$[ebp], ecx
> ; Line 10
> xor eax, eax
> mov esp, ebp
> pop ebp
> ret 0
> _main ENDP
> _TEXT ENDS
> END
>
All this assembly proves is that you are incorrect and we are correct:
'arr$' is an offset used in conjunction with the stack frame pointer
('ebp').
/Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-26 16:45 +0100 |
| Message-ID | <PAuDp.17795$h35.5479@newsfe19.ams2> |
| In reply to | #5621 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:L5-dnTeJldna9EPQnZ2dnUVZ8kCdnZ2d@giganews.com... > On 26/05/2011 15:27, 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: " >>> >>> That is all fine and correct. >>> >>>> >>>> The pointer _arr$ happens to be an offset into the text segment, but >>> >>> Yet again you are confusing different meanings of the term "segment". >>> 'arr$' is certainly not a pointer and it is certainly not an offset >>> into the text segment. >>> >>>> this does not change the fact that it is a pointer. >>>> It's value is -20 , that is a memory index or an offset. >>> >>> '_arr$' is not a pointer in either sense (assembly or C++); '_arr$' is >>> a constant, an offset used in conjunction with the stack frame pointer. >>> >>> <snip> >>> >>> YOU NEED TO READ TWO BOOKS: One on assembly language programming and >>> one on C++ programming (or compiler design). >>> >> arr is a pointer , the same as px in the following code: > > No it isn't. Just because similar assembly is produced for dereferencing > a pointer on the stack and accessing an array element on the stack that > doesn't mean that a stack frame pointer offset (constant) is a pointer. > The assembly code pointer is what we are talking about here. Stop being an idiot.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-26 17:04 +0100 |
| Message-ID | <N4ednfDTLumX50PQnZ2dnUVZ8hSdnZ2d@giganews.com> |
| In reply to | #5623 |
On 26/05/2011 16:45, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:L5-dnTeJldna9EPQnZ2dnUVZ8kCdnZ2d@giganews.com... >> On 26/05/2011 15:27, 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: " >>>> >>>> That is all fine and correct. >>>> >>>>> >>>>> The pointer _arr$ happens to be an offset into the text segment, but >>>> >>>> Yet again you are confusing different meanings of the term "segment". >>>> 'arr$' is certainly not a pointer and it is certainly not an offset >>>> into the text segment. >>>> >>>>> this does not change the fact that it is a pointer. >>>>> It's value is -20 , that is a memory index or an offset. >>>> >>>> '_arr$' is not a pointer in either sense (assembly or C++); '_arr$' is >>>> a constant, an offset used in conjunction with the stack frame pointer. >>>> >>>> <snip> >>>> >>>> YOU NEED TO READ TWO BOOKS: One on assembly language programming and >>>> one on C++ programming (or compiler design). >>>> >>> arr is a pointer , the same as px in the following code: >> >> No it isn't. Just because similar assembly is produced for >> dereferencing a pointer on the stack and accessing an array element on >> the stack that doesn't mean that a stack frame pointer offset >> (constant) is a pointer. >> > The assembly code pointer is what we are talking about here. > Stop being an idiot. As usual you start mixing terminology to try and hide the fact that you have been proven wrong; you are the one trying to equate C++ pointers with array objects (in your C++ code and assembly output that you have conveniently snipped from your subsequent reply). What you call an "assembly code pointer" is actually just an integer constant which is added to the stack frame pointer in order to obtain a value off the stack. This same mechanism is used to obtain the value of any type of object not just arrays. Basically you don't know what you are talking about. An object of array type does *not* have a special hidden associated object containing the address of the object just as an object of *any* type doesn't have a special hidden associated object containing the address of the object. HTH. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-26 17:41 +0100 |
| Message-ID | <4pvDp.16540$8A7.14547@newsfe12.ams2> |
| In reply to | #5625 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:N4ednfDTLumX50PQnZ2dnUVZ8hSdnZ2d@giganews.com... > On 26/05/2011 16:45, Paul wrote: >> >> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >> news:L5-dnTeJldna9EPQnZ2dnUVZ8kCdnZ2d@giganews.com... >>> On 26/05/2011 15:27, 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: " >>>>> >>>>> That is all fine and correct. >>>>> >>>>>> >>>>>> The pointer _arr$ happens to be an offset into the text segment, but >>>>> >>>>> Yet again you are confusing different meanings of the term "segment". >>>>> 'arr$' is certainly not a pointer and it is certainly not an offset >>>>> into the text segment. >>>>> >>>>>> this does not change the fact that it is a pointer. >>>>>> It's value is -20 , that is a memory index or an offset. >>>>> >>>>> '_arr$' is not a pointer in either sense (assembly or C++); '_arr$' is >>>>> a constant, an offset used in conjunction with the stack frame >>>>> pointer. >>>>> >>>>> <snip> >>>>> >>>>> YOU NEED TO READ TWO BOOKS: One on assembly language programming and >>>>> one on C++ programming (or compiler design). >>>>> >>>> arr is a pointer , the same as px in the following code: >>> >>> No it isn't. Just because similar assembly is produced for >>> dereferencing a pointer on the stack and accessing an array element on >>> the stack that doesn't mean that a stack frame pointer offset >>> (constant) is a pointer. >>> >> The assembly code pointer is what we are talking about here. >> Stop being an idiot. > > As usual you start mixing terminology to try and hide the fact that you > have been proven wrong; you are the one trying to equate C++ pointers with > array objects (in your C++ code and assembly output that you have > conveniently snipped from your subsequent reply). > > What you call an "assembly code pointer" is actually just an integer > constant which is added to the stack frame pointer in order to obtain a > value off the stack. This same mechanism is used to obtain the value of > any type of object not just arrays. Basically you don't know what you are > talking about. Thats what a pointer is in assembly is just a varaible that stores an offset value.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-27 07:44 +1200 |
| Message-ID | <947otdF9stU1@mid.individual.net> |
| In reply to | #5613 |
On 05/27/11 12:22 AM, Paul wrote: > > "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. Man you really don't have a clue, do you? I'll ask again, How much x86 assembly programming have you actually done? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-26 21:10 +0100 |
| Message-ID | <vtyDp.13261$h_.5519@newsfe30.ams2> |
| In reply to | #5643 |
"Ian Collins" <ian-news@hotmail.com> wrote in message news:947otdF9stU1@mid.individual.net... > On 05/27/11 12:22 AM, Paul wrote: >> >> "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. > > Man you really don't have a clue, do you? I'll ask again, How much x86 > assembly programming have you actually done? > > -- It doesn't matter how much I claim to have done or how much you claim to have done. The fact of the matter is, apparently I know what a pointer is and you don't. A variable whose value is an address(or an offset) to another memory location is a pointer in assembly language.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-27 09:05 +1200 |
| Message-ID | <947tl0F9stU3@mid.individual.net> |
| In reply to | #5645 |
On 05/27/11 08:10 AM, Paul wrote: > "Ian Collins"<ian-news@hotmail.com> wrote: >> >> Man you really don't have a clue, do you? I'll ask again, How much x86 >> assembly programming have you actually done? >> > It doesn't matter how much I claim to have done or how much you claim to > have done. The fact of the matter is, apparently I know what a pointer is > and you don't. I'll take that as "none". > A variable whose value is an address(or an offset) to another memory > location is a pointer in assembly language. The *number* -20 isn't a variable any more than arr in "#define arr 20" is. _arr$ = -20 ; size = 20 is the MASM equivalent of #define arr = -20 // is arr a pointer? It is declared in the text segment, it is not an offset into the text segment. Get a clue, please. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-27 00:15 +0100 |
| Message-ID | <SaBDp.12912$ue1.5403@newsfe28.ams2> |
| In reply to | #5648 |
"Ian Collins" <ian-news@hotmail.com> wrote in message news:947tl0F9stU3@mid.individual.net... > On 05/27/11 08:10 AM, Paul wrote: >> "Ian Collins"<ian-news@hotmail.com> wrote: >>> >>> Man you really don't have a clue, do you? I'll ask again, How much x86 >>> assembly programming have you actually done? >>> >> It doesn't matter how much I claim to have done or how much you claim to >> have done. The fact of the matter is, apparently I know what a pointer >> is >> and you don't. > > I'll take that as "none". > >> A variable whose value is an address(or an offset) to another memory >> location is a pointer in assembly language. > > The *number* -20 isn't a variable any more than arr in "#define arr 20" > is. Correct -20 is not a variable , it is the value of the variable. > > _arr$ = -20 ; size = 20 > > is the MASM equivalent of > > #define arr = -20 // is arr a pointer? > > It is declared in the text segment, it is not an offset into the text > segment. > _arr$ is a variable that stores the value -20. -20 is a value that represents an offset memory address. This is pointer variable that holds an offset which points to another memory location.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-27 11:32 +1200 |
| Message-ID | <948694Fmt0U1@mid.individual.net> |
| In reply to | #5650 |
On 05/27/11 11:15 AM, Paul wrote: > "Ian Collins"<ian-news@hotmail.com> wrote: >> On 05/27/11 08:10 AM, Paul wrote: >>> "Ian Collins"<ian-news@hotmail.com> wrote: >>>> >>>> Man you really don't have a clue, do you? I'll ask again, How much x86 >>>> assembly programming have you actually done? >>>> >>> It doesn't matter how much I claim to have done or how much you claim to >>> have done. The fact of the matter is, apparently I know what a pointer >>> is >>> and you don't. >> >> I'll take that as "none". >> >>> A variable whose value is an address(or an offset) to another memory >>> location is a pointer in assembly language. >> >> The *number* -20 isn't a variable any more than arr in "#define arr 20" >> is. > Correct -20 is not a variable , it is the value of the variable. It is the value of a constant. By your definition, if I write #define arr -20 arr is a variable. >> _arr$ = -20 ; size = 20 >> >> is the MASM equivalent of >> >> #define arr = -20 // is arr a pointer? >> >> It is declared in the text segment, it is not an offset into the text >> segment. >> > _arr$ is a variable that stores the value -20. No, for the last time it is a constant. Please study a topic before posting about it. From the link I posted earlier: "A manifest constant is a symbol name that represents some fixed quantity during the assembly process. That is it is a symbolic name that represents some value. Equates are the mechanism MASM uses to declare symbolic constants." This is now way off topic. I suggest you find an assembly programming group and see how far you get there. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-27 01:39 +0100 |
| Message-ID | <XoCDp.13270$f95.8241@newsfe02.ams2> |
| In reply to | #5652 |
"Ian Collins" <ian-news@hotmail.com> wrote in message
news:948694Fmt0U1@mid.individual.net...
> On 05/27/11 11:15 AM, Paul wrote:
>> "Ian Collins"<ian-news@hotmail.com> wrote:
>>> On 05/27/11 08:10 AM, Paul wrote:
>>>> "Ian Collins"<ian-news@hotmail.com> wrote:
>>>>>
>>>>> Man you really don't have a clue, do you? I'll ask again, How much
>>>>> x86
>>>>> assembly programming have you actually done?
>>>>>
>>>> It doesn't matter how much I claim to have done or how much you claim
>>>> to
>>>> have done. The fact of the matter is, apparently I know what a pointer
>>>> is
>>>> and you don't.
>>>
>>> I'll take that as "none".
>>>
>>>> A variable whose value is an address(or an offset) to another memory
>>>> location is a pointer in assembly language.
>>>
>>> The *number* -20 isn't a variable any more than arr in "#define arr 20"
>>> is.
>> Correct -20 is not a variable , it is the value of the variable.
>
> It is the value of a constant. By your definition, if I write
>
> #define arr -20
>
> arr is a variable.
>
>>> _arr$ = -20 ; size = 20
>>>
>>> is the MASM equivalent of
>>>
>>> #define arr = -20 // is arr a pointer?
>>>
>>> It is declared in the text segment, it is not an offset into the text
>>> segment.
>>>
>> _arr$ is a variable that stores the value -20.
>
> No, for the last time it is a constant. Please study a topic before
> posting about it. From the link I posted earlier:
>
> "A manifest constant is a symbol name that represents some fixed quantity
> during the assembly process. That is it is a symbolic name that represents
> some value. Equates are the mechanism MASM uses to declare symbolic
> constants."
>
> This is now way off topic. I suggest you find an assembly programming
> group and see how far you get there.
>
Its you that brought it up. And now you seem to be ruinning away from the
argument because you are maybe starting to realise that _arr$ is a pointer.
Look at the following code:
int main(){
int arr[3]={0};
int* px= arr;
px[1] = 7;
}
; 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 _main
; Function compile flags: /Odtp
_TEXT SEGMENT
_px$ = -16 ; size = 4
_arr$ = -12 ; size = 12
_main PROC
; File c:\cpp\public.cpp
; Line 5
push ebp
mov ebp, esp
sub esp, 16 ; 00000010H
; Line 6
mov DWORD PTR _arr$[ebp], 0
xor eax, eax
mov DWORD PTR _arr$[ebp+4], eax
mov DWORD PTR _arr$[ebp+8], eax
; Line 7
lea ecx, DWORD PTR _arr$[ebp]
mov DWORD PTR _px$[ebp], ecx
; Line 8
mov edx, DWORD PTR _px$[ebp]
mov DWORD PTR [edx+4], 7
; Line 9
xor eax, eax
mov esp, ebp
pop ebp
ret 0
_main ENDP
_TEXT ENDS
END
Line 5-6 Creates a stack frame similar to below. It preserves ebp on the
stack, then assgins the esp value to ebp and then decrements esp by 16
bytes.
Line 6-7 Initialises the 3 integer objects , of the array, to 0.
Line 7-8 Stores the address of the first element at the location _px$ points
to.
Line 8-9 Moves the literal value of 7 into the 2nd element of the array.
00001C [-------------]
000018 [--orig ebp---]<- orig esp
000014 [------0------] <-ebp
000010 [------7------]
00000C [------0------]
000008 [---00000C---] <- esp
000004 [-------------]
000000 [-------------]
After that ebp is popped and esp is back to its original value.
Face the facts about what a pointer is in assembly programming.
If you still do not accept these facts then I urge you to refer to the link
I posted about pointer data types by Randy Hyde.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-27 01:56 +0100 |
| Message-ID | <PECDp.23676$Am5.433@newsfe05.ams2> |
| In reply to | #5657 |
"Paul" <pchristor@yahoo.co.uk> wrote in message news:XoCDp.13270$f95.8241@newsfe02.ams2... > Thats should be: > > 00001C [-------------]<- original esp > 000018 [--orig ebp---]<- ebp > 000014 [------0------] 000010 [------7------] > 00000C [------0------] > 000008 [---00000C---] <- esp > 000004 [-------------] > 000000 [-------------] > I had ebp pointing to the wrong location.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-27 13:18 +1200 |
| Message-ID | <948cftFmt0U2@mid.individual.net> |
| In reply to | #5657 |
On 05/27/11 12:39 PM, Paul wrote:
> "Ian Collins"<ian-news@hotmail.com> wrote:
>> On 05/27/11 11:15 AM, Paul wrote:
>>>>
>>> _arr$ is a variable that stores the value -20.
>>
>> No, for the last time it is a constant. Please study a topic before
>> posting about it. From the link I posted earlier:
>>
>> "A manifest constant is a symbol name that represents some fixed quantity
>> during the assembly process. That is it is a symbolic name that represents
>> some value. Equates are the mechanism MASM uses to declare symbolic
>> constants."
>>
>> This is now way off topic. I suggest you find an assembly programming
>> group and see how far you get there.
>>
> Its you that brought it up.
Did I? It was you who claimed a constant was a pointer.
> And now you seem to be ruinning away from the
> argument because you are maybe starting to realise that _arr$ is a pointer.
No I'm not because it isn't.
> Look at the following code:
>
> int main(){
> int arr[3]={0};
> int* px= arr;
> px[1] = 7;
> }
Let's see the output from a less verbose compiler:
.file "x.cc"
.text
.globl main
.type main, @function
main:
.LFB0:
pushl %ebp
.LCFI0:
movl %esp, %ebp
.LCFI1:
subl $16, %esp
.LCFI2:
movl $0, -16(%ebp)
movl $0, -12(%ebp)
movl $0, -8(%ebp)
leal -16(%ebp), %eax
movl %eax, -4(%ebp)
movl -4(%ebp), %eax
addl $4, %eax
movl $7, (%eax)
movl $0, %eax
leave
.LCFI3:
ret
.LFE0:
.size main, .-main
Much more concise, don't you agree? I guess by your reasoning, -16,
-12, -8 and -4 are pointers? The compiler could have used symbolic
constants like VCC, but is chooses not to.
How about another that uses symbolic constants for the array initialiser?
/ FILE x.cc
/ 1 !int main(){
push %rbp
.CG4:
movq %rsp,%rbp
.CG5:
subq $16,%rsp
/ 2 ! int arr[3]={0};
movq .LI1(%rip),%rcx
movl .LI1+8(%rip),%eax
movq %rcx,-16(%rbp) / sym=__1fEmain1ADarr_
movl %eax,-8(%rbp) / sym=__1fEmain1ADarr_
/ 3 ! int* px= arr;
/ 4 ! px[1] = 7;
movl $7,-12(%rbp) / sym=__1fEmain1ADarr_
/ 5 !}
xorl %eax,%eax
leave
ret
.CG6:
.size main, . - main
.CG7:
.CG8:
.section .data,"aw"
Ddata.data: / Offset 0
.align 8
.LI1: / Offset 0
.type .LI1, @object
.size .LI1, 12
.zero 12
.section .bss,"aw"
Just because one implementation uses symbolic constants for offsets,
they don't morph into pointers.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-27 11:06 +0100 |
| Message-ID | <9JKDp.19824$6K4.8966@newsfe14.ams2> |
| In reply to | #5659 |
"Ian Collins" <ian-news@hotmail.com> wrote in message
news:948cftFmt0U2@mid.individual.net...
> On 05/27/11 12:39 PM, Paul wrote:
>> "Ian Collins"<ian-news@hotmail.com> wrote:
>>> On 05/27/11 11:15 AM, Paul wrote:
>>>>>
>>>> _arr$ is a variable that stores the value -20.
>>>
>>> No, for the last time it is a constant. Please study a topic before
>>> posting about it. From the link I posted earlier:
>>>
>>> "A manifest constant is a symbol name that represents some fixed
>>> quantity
>>> during the assembly process. That is it is a symbolic name that
>>> represents
>>> some value. Equates are the mechanism MASM uses to declare symbolic
>>> constants."
>>>
>>> This is now way off topic. I suggest you find an assembly programming
>>> group and see how far you get there.
>>>
>> Its you that brought it up.
>
> Did I? It was you who claimed a constant was a pointer.
No I claimed that _arr$ was a pointer, you are arguing that is it s not a
poiter and it is just a constant.
So what do you think a pointer is in assembly?
>
>> And now you seem to be ruinning away from the
>> argument because you are maybe starting to realise that _arr$ is a
>> pointer.
>
> No I'm not because it isn't.
_arr$ IS a pointer, its value is an offset to anothe rmemory location.
>
>> Look at the following code:
>>
>> int main(){
>> int arr[3]={0};
>> int* px= arr;
>> px[1] = 7;
>> }
>
> Let's see the output from a less verbose compiler:
There is nothing wrong with the code I posted, it was very simple. The code
you have posted below does away with the varaible altogether so how can you
argue about whether or not its a pointer if it doesn't even exist?
>
> .file "x.cc"
> .text
> .globl main
> .type main, @function
> main:
> .LFB0:
> pushl %ebp
> .LCFI0:
> movl %esp, %ebp
> .LCFI1:
> subl $16, %esp
> .LCFI2:
> movl $0, -16(%ebp)
> movl $0, -12(%ebp)
> movl $0, -8(%ebp)
> leal -16(%ebp), %eax
> movl %eax, -4(%ebp)
> movl -4(%ebp), %eax
> addl $4, %eax
> movl $7, (%eax)
> movl $0, %eax
> leave
> .LCFI3:
> ret
> .LFE0:
> .size main, .-main
>
> Much more concise, don't you agree? I guess by your
> reasoning, -16, -12, -8 and -4 are pointers? The compiler could have used
> symbolic constants like VCC, but is chooses not to.
No its not concise, my listing was well commented and initially started by
telling you the source of the code. Where does your code come from?
So it does away with all variables and replaces them with literals, does
this mean that _arr$ in my code is not a pointer, NO.
>
> How about another that uses symbolic constants for the array initialiser?
Now you are just spamming shite.
>
> / FILE x.cc
>
> / 1 !int main(){
>
> push %rbp
> .CG4: movq %rsp,%rbp
> .CG5: subq $16,%rsp
> / 2 ! int arr[3]={0};
>
> movq .LI1(%rip),%rcx movl .LI1+8(%rip),%eax movq
> %rcx,-16(%rbp) / sym=__1fEmain1ADarr_
> movl %eax,-8(%rbp) / sym=__1fEmain1ADarr_
>
> / 3 ! int* px= arr;
> / 4 ! px[1] = 7;
>
> movl $7,-12(%rbp) / sym=__1fEmain1ADarr_
>
> / 5 !}
>
> xorl %eax,%eax leave ret
> .CG6:
> .size main, . - main
> .CG7:
>
> .CG8:
> .section .data,"aw"
> Ddata.data: / Offset 0
>
> .align 8
> .LI1: / Offset 0
> .type .LI1, @object
> .size .LI1, 12
>
> .zero 12
> .section .bss,"aw"
>
> Just because one implementation uses symbolic constants for offsets, they
> don't morph into pointers.
>
You don't know what a pointer is.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-27 22:28 +1200 |
| Message-ID | <949cmgFg7rU1@mid.individual.net> |
| In reply to | #5675 |
On 05/27/11 10:06 PM, Paul wrote:
> "Ian Collins"<ian-news@hotmail.com> wrote;
>>
>>> Look at the following code:
>>>
>>> int main(){
>>> int arr[3]={0};
>>> int* px= arr;
>>> px[1] = 7;
>>> }
>>
>> Let's see the output from a less verbose compiler:
> There is nothing wrong with the code I posted, it was very simple. The code
> you have posted below does away with the varaible altogether so how can you
> argue about whether or not its a pointer if it doesn't even exist?
It's you code compiled with gcc.
>>
>> .file "x.cc"
>> .text
>> .globl main
>> .type main, @function
>> main:
>> .LFB0:
>> pushl %ebp
>> .LCFI0:
>> movl %esp, %ebp
>> .LCFI1:
>> subl $16, %esp
>> .LCFI2:
>> movl $0, -16(%ebp)
>> movl $0, -12(%ebp)
>> movl $0, -8(%ebp)
>> leal -16(%ebp), %eax
>> movl %eax, -4(%ebp)
>> movl -4(%ebp), %eax
>> addl $4, %eax
>> movl $7, (%eax)
>> movl $0, %eax
>> leave
>> .LCFI3:
>> ret
>> .LFE0:
>> .size main, .-main
>>
>> Much more concise, don't you agree? I guess by your
>> reasoning, -16, -12, -8 and -4 are pointers? The compiler could have used
>> symbolic constants like VCC, but is chooses not to.
>
> No its not concise, my listing was well commented and initially started by
> telling you the source of the code. Where does your code come from?
It's you code compiled with gcc.
> So it does away with all variables and replaces them with literals, does
> this mean that _arr$ in my code is not a pointer, NO.
Well yes and no, because it never was. As everyone one who has ever
worked with this assembler (no you, obviously) knows, it is a symbolic
constant.
>> How about another that uses symbolic constants for the array initialiser?
>
> Now you are just spamming shite.
Well maybe, it is your code after all!
Your code, compiled with Sun CC:
>> / FILE x.cc
>>
>> / 1 !int main(){
>>
>> push %rbp
>> .CG4: movq %rsp,%rbp
>> .CG5: subq $16,%rsp
>> / 2 ! int arr[3]={0};
>>
>> movq .LI1(%rip),%rcx movl .LI1+8(%rip),%eax movq
>> %rcx,-16(%rbp) / sym=__1fEmain1ADarr_
>> movl %eax,-8(%rbp) / sym=__1fEmain1ADarr_
>>
>> / 3 ! int* px= arr;
>> / 4 ! px[1] = 7;
>>
>> movl $7,-12(%rbp) / sym=__1fEmain1ADarr_
>>
>> / 5 !}
>>
>> xorl %eax,%eax leave ret
>> .CG6:
>> .size main, . - main
>> .CG7:
>>
>> .CG8:
>> .section .data,"aw"
>> Ddata.data: / Offset 0
>>
>> .align 8
>> .LI1: / Offset 0
>> .type .LI1, @object
>> .size .LI1, 12
>>
>> .zero 12
>> .section .bss,"aw"
>>
>> Just because one implementation uses symbolic constants for offsets, they
>> don't morph into pointers.
>>
> You don't know what a pointer is.
Oh no! The past 30 years have been a delusion!
But I know a fool when I see one.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-27 12:51 +0100 |
| Message-ID | <pfMDp.25302$%o4.5062@newsfe16.ams2> |
| In reply to | #5677 |
"Ian Collins" <ian-news@hotmail.com> wrote in message news:949cmgFg7rU1@mid.individual.net... > On 05/27/11 10:06 PM, Paul wrote: >> You don't know what a pointer is. > > Oh no! The past 30 years have been a delusion! > > But I know a fool when I see one. > I bet you do , everytime you look in the mirror
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-27 13:58 +0100 |
| Message-ID | <wuCdnfZkaex0AkLQnZ2dnUVZ8mydnZ2d@giganews.com> |
| In reply to | #5657 |
On 27/05/2011 01:39, Paul wrote:
>
> "Ian Collins" <ian-news@hotmail.com> wrote in message
> news:948694Fmt0U1@mid.individual.net...
>> On 05/27/11 11:15 AM, Paul wrote:
>>> "Ian Collins"<ian-news@hotmail.com> wrote:
>>>> On 05/27/11 08:10 AM, Paul wrote:
>>>>> "Ian Collins"<ian-news@hotmail.com> wrote:
>>>>>>
>>>>>> Man you really don't have a clue, do you? I'll ask again, How much
>>>>>> x86
>>>>>> assembly programming have you actually done?
>>>>>>
>>>>> It doesn't matter how much I claim to have done or how much you
>>>>> claim to
>>>>> have done. The fact of the matter is, apparently I know what a pointer
>>>>> is
>>>>> and you don't.
>>>>
>>>> I'll take that as "none".
>>>>
>>>>> A variable whose value is an address(or an offset) to another memory
>>>>> location is a pointer in assembly language.
>>>>
>>>> The *number* -20 isn't a variable any more than arr in "#define arr 20"
>>>> is.
>>> Correct -20 is not a variable , it is the value of the variable.
>>
>> It is the value of a constant. By your definition, if I write
>>
>> #define arr -20
>>
>> arr is a variable.
>>
>>>> _arr$ = -20 ; size = 20
>>>>
>>>> is the MASM equivalent of
>>>>
>>>> #define arr = -20 // is arr a pointer?
>>>>
>>>> It is declared in the text segment, it is not an offset into the text
>>>> segment.
>>>>
>>> _arr$ is a variable that stores the value -20.
>>
>> No, for the last time it is a constant. Please study a topic before
>> posting about it. From the link I posted earlier:
>>
>> "A manifest constant is a symbol name that represents some fixed
>> quantity during the assembly process. That is it is a symbolic name
>> that represents some value. Equates are the mechanism MASM uses to
>> declare symbolic constants."
>>
>> This is now way off topic. I suggest you find an assembly programming
>> group and see how far you get there.
>>
> Its you that brought it up. And now you seem to be ruinning away from
> the argument because you are maybe starting to realise that _arr$ is a
> pointer.
>
>
> Look at the following code:
>
> int main(){
> int arr[3]={0};
> int* px= arr;
> px[1] = 7;
> }
>
> ; 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 _main
> ; Function compile flags: /Odtp
> _TEXT SEGMENT
> _px$ = -16 ; size = 4
> _arr$ = -12 ; size = 12
> _main PROC
> ; File c:\cpp\public.cpp
> ; Line 5
> push ebp
> mov ebp, esp
> sub esp, 16 ; 00000010H
> ; Line 6
> mov DWORD PTR _arr$[ebp], 0
> xor eax, eax
> mov DWORD PTR _arr$[ebp+4], eax
> mov DWORD PTR _arr$[ebp+8], eax
> ; Line 7
> lea ecx, DWORD PTR _arr$[ebp]
> mov DWORD PTR _px$[ebp], ecx
> ; Line 8
> mov edx, DWORD PTR _px$[ebp]
> mov DWORD PTR [edx+4], 7
> ; Line 9
> xor eax, eax
> mov esp, ebp
> pop ebp
> ret 0
> _main ENDP
> _TEXT ENDS
> END
>
> Line 5-6 Creates a stack frame similar to below. It preserves ebp on the
> stack, then assgins the esp value to ebp and then decrements esp by 16
> bytes.
> Line 6-7 Initialises the 3 integer objects , of the array, to 0.
> Line 7-8 Stores the address of the first element at the location _px$
> points to.
> Line 8-9 Moves the literal value of 7 into the 2nd element of the array.
>
>
> 00001C [-------------]
> 000018 [--orig ebp---]<- orig esp
> 000014 [------0------] <-ebp
> 000010 [------7------]
> 00000C [------0------]
> 000008 [---00000C---] <- esp
> 000004 [-------------]
> 000000 [-------------]
>
> After that ebp is popped and esp is back to its original value.
> Face the facts about what a pointer is in assembly programming.
> If you still do not accept these facts then I urge you to refer to the
> link I posted about pointer data types by Randy Hyde.
Now you are arguing with yourself: you have just shown that there is no
special hidden object which containing the address of the array object;
the only thing that contains the address of the array object above is
the pointer 'px'.
For:
lea ecx, DWORD PTR _arr$[ebp]
what will actually be emitted is:
lea ecx, DWORD PTR [ebp-12]
as '_arr$' is a constant; not a variable or a "pointer".
lrn2asm.
Get a clue and stop wasting everyone's time in this newsgroup.
/Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-27 14:34 +0100 |
| Message-ID | <ILNDp.19833$UY3.3476@newsfe20.ams2> |
| In reply to | #5683 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message
news:wuCdnfZkaex0AkLQnZ2dnUVZ8mydnZ2d@giganews.com...
> On 27/05/2011 01:39, Paul wrote:
>>
>> "Ian Collins" <ian-news@hotmail.com> wrote in message
>> news:948694Fmt0U1@mid.individual.net...
>>> On 05/27/11 11:15 AM, Paul wrote:
>>>> "Ian Collins"<ian-news@hotmail.com> wrote:
>>>>> On 05/27/11 08:10 AM, Paul wrote:
>>>>>> "Ian Collins"<ian-news@hotmail.com> wrote:
>>>>>>>
>>>>>>> Man you really don't have a clue, do you? I'll ask again, How much
>>>>>>> x86
>>>>>>> assembly programming have you actually done?
>>>>>>>
>>>>>> It doesn't matter how much I claim to have done or how much you
>>>>>> claim to
>>>>>> have done. The fact of the matter is, apparently I know what a
>>>>>> pointer
>>>>>> is
>>>>>> and you don't.
>>>>>
>>>>> I'll take that as "none".
>>>>>
>>>>>> A variable whose value is an address(or an offset) to another memory
>>>>>> location is a pointer in assembly language.
>>>>>
>>>>> The *number* -20 isn't a variable any more than arr in "#define arr
>>>>> 20"
>>>>> is.
>>>> Correct -20 is not a variable , it is the value of the variable.
>>>
>>> It is the value of a constant. By your definition, if I write
>>>
>>> #define arr -20
>>>
>>> arr is a variable.
>>>
>>>>> _arr$ = -20 ; size = 20
>>>>>
>>>>> is the MASM equivalent of
>>>>>
>>>>> #define arr = -20 // is arr a pointer?
>>>>>
>>>>> It is declared in the text segment, it is not an offset into the text
>>>>> segment.
>>>>>
>>>> _arr$ is a variable that stores the value -20.
>>>
>>> No, for the last time it is a constant. Please study a topic before
>>> posting about it. From the link I posted earlier:
>>>
>>> "A manifest constant is a symbol name that represents some fixed
>>> quantity during the assembly process. That is it is a symbolic name
>>> that represents some value. Equates are the mechanism MASM uses to
>>> declare symbolic constants."
>>>
>>> This is now way off topic. I suggest you find an assembly programming
>>> group and see how far you get there.
>>>
>> Its you that brought it up. And now you seem to be ruinning away from
>> the argument because you are maybe starting to realise that _arr$ is a
>> pointer.
>>
>>
>> Look at the following code:
>>
>> int main(){
>> int arr[3]={0};
>> int* px= arr;
>> px[1] = 7;
>> }
>>
>> ; 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 _main
>> ; Function compile flags: /Odtp
>> _TEXT SEGMENT
>> _px$ = -16 ; size = 4
>> _arr$ = -12 ; size = 12
>> _main PROC
>> ; File c:\cpp\public.cpp
>> ; Line 5
>> push ebp
>> mov ebp, esp
>> sub esp, 16 ; 00000010H
>> ; Line 6
>> mov DWORD PTR _arr$[ebp], 0
>> xor eax, eax
>> mov DWORD PTR _arr$[ebp+4], eax
>> mov DWORD PTR _arr$[ebp+8], eax
>> ; Line 7
>> lea ecx, DWORD PTR _arr$[ebp]
>> mov DWORD PTR _px$[ebp], ecx
>> ; Line 8
>> mov edx, DWORD PTR _px$[ebp]
>> mov DWORD PTR [edx+4], 7
>> ; Line 9
>> xor eax, eax
>> mov esp, ebp
>> pop ebp
>> ret 0
>> _main ENDP
>> _TEXT ENDS
>> END
>>
>> Line 5-6 Creates a stack frame similar to below. It preserves ebp on the
>> stack, then assgins the esp value to ebp and then decrements esp by 16
>> bytes.
>> Line 6-7 Initialises the 3 integer objects , of the array, to 0.
>> Line 7-8 Stores the address of the first element at the location _px$
>> points to.
>> Line 8-9 Moves the literal value of 7 into the 2nd element of the array.
>>
>>
>> 00001C [-------------]
>> 000018 [--orig ebp---]<- orig esp
>> 000014 [------0------] <-ebp
>> 000010 [------7------]
>> 00000C [------0------]
>> 000008 [---00000C---] <- esp
>> 000004 [-------------]
>> 000000 [-------------]
>>
>> After that ebp is popped and esp is back to its original value.
>> Face the facts about what a pointer is in assembly programming.
>> If you still do not accept these facts then I urge you to refer to the
>> link I posted about pointer data types by Randy Hyde.
>
> Now you are arguing with yourself: you have just shown that there is no
> special hidden object which containing the address of the array object;
> the only thing that contains the address of the array object above is the
> pointer 'px'.
>
No there is a pointer named _arr$, which happens to be in the text segment,
it is not on the stack.
Just the same as the pointer _px$ is not on the stack.
Look at the value of _px$, it is -16, this doesn't mean it's not a pointer.
Its just a pointer that stores an offset, or an index into the stack.
> For:
>
> lea ecx, DWORD PTR _arr$[ebp]
>
> what will actually be emitted is:
>
> lea ecx, DWORD PTR [ebp-12]
>
> as '_arr$' is a constant; not a variable or a "pointer".
_arr$ holds an offset which is added to ebp to create the real address.
_arr$ is a constant only because it is stored in the read only text segment.
This does not mean it is not a pointer , it stores an offset that points to
the begining of the array.
A pointer does not need to store a real address a pointer can also store an
offset, as in this case.
Given my stack frame illustration _arr$ points to here:
00001C [-------------]
000018 [--orig ebp---] <- ebp
000014 [------0------]
000010 [------7------]
00000C [------0------] <- _arr$
000008 [---00000C---] <- esp
000004 [-------------]
000000 [-------------]
-12 is an offset into the stack frame, which is the location where the array
begins.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-27 15:14 +0100 |
| Message-ID | <YO-dndRDz9U1LELQnZ2dnUVZ8n2dnZ2d@giganews.com> |
| In reply to | #5691 |
On 27/05/2011 14:34, Paul wrote:
>
> "Leigh Johnston" <leigh@i42.co.uk> wrote in message
> news:wuCdnfZkaex0AkLQnZ2dnUVZ8mydnZ2d@giganews.com...
>> On 27/05/2011 01:39, Paul wrote:
>>>
>>> "Ian Collins" <ian-news@hotmail.com> wrote in message
>>> news:948694Fmt0U1@mid.individual.net...
>>>> On 05/27/11 11:15 AM, Paul wrote:
>>>>> "Ian Collins"<ian-news@hotmail.com> wrote:
>>>>>> On 05/27/11 08:10 AM, Paul wrote:
>>>>>>> "Ian Collins"<ian-news@hotmail.com> wrote:
>>>>>>>>
>>>>>>>> Man you really don't have a clue, do you? I'll ask again, How much
>>>>>>>> x86
>>>>>>>> assembly programming have you actually done?
>>>>>>>>
>>>>>>> It doesn't matter how much I claim to have done or how much you
>>>>>>> claim to
>>>>>>> have done. The fact of the matter is, apparently I know what a
>>>>>>> pointer
>>>>>>> is
>>>>>>> and you don't.
>>>>>>
>>>>>> I'll take that as "none".
>>>>>>
>>>>>>> A variable whose value is an address(or an offset) to another memory
>>>>>>> location is a pointer in assembly language.
>>>>>>
>>>>>> The *number* -20 isn't a variable any more than arr in "#define
>>>>>> arr 20"
>>>>>> is.
>>>>> Correct -20 is not a variable , it is the value of the variable.
>>>>
>>>> It is the value of a constant. By your definition, if I write
>>>>
>>>> #define arr -20
>>>>
>>>> arr is a variable.
>>>>
>>>>>> _arr$ = -20 ; size = 20
>>>>>>
>>>>>> is the MASM equivalent of
>>>>>>
>>>>>> #define arr = -20 // is arr a pointer?
>>>>>>
>>>>>> It is declared in the text segment, it is not an offset into the text
>>>>>> segment.
>>>>>>
>>>>> _arr$ is a variable that stores the value -20.
>>>>
>>>> No, for the last time it is a constant. Please study a topic before
>>>> posting about it. From the link I posted earlier:
>>>>
>>>> "A manifest constant is a symbol name that represents some fixed
>>>> quantity during the assembly process. That is it is a symbolic name
>>>> that represents some value. Equates are the mechanism MASM uses to
>>>> declare symbolic constants."
>>>>
>>>> This is now way off topic. I suggest you find an assembly programming
>>>> group and see how far you get there.
>>>>
>>> Its you that brought it up. And now you seem to be ruinning away from
>>> the argument because you are maybe starting to realise that _arr$ is a
>>> pointer.
>>>
>>>
>>> Look at the following code:
>>>
>>> int main(){
>>> int arr[3]={0};
>>> int* px= arr;
>>> px[1] = 7;
>>> }
>>>
>>> ; 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 _main
>>> ; Function compile flags: /Odtp
>>> _TEXT SEGMENT
>>> _px$ = -16 ; size = 4
>>> _arr$ = -12 ; size = 12
>>> _main PROC
>>> ; File c:\cpp\public.cpp
>>> ; Line 5
>>> push ebp
>>> mov ebp, esp
>>> sub esp, 16 ; 00000010H
>>> ; Line 6
>>> mov DWORD PTR _arr$[ebp], 0
>>> xor eax, eax
>>> mov DWORD PTR _arr$[ebp+4], eax
>>> mov DWORD PTR _arr$[ebp+8], eax
>>> ; Line 7
>>> lea ecx, DWORD PTR _arr$[ebp]
>>> mov DWORD PTR _px$[ebp], ecx
>>> ; Line 8
>>> mov edx, DWORD PTR _px$[ebp]
>>> mov DWORD PTR [edx+4], 7
>>> ; Line 9
>>> xor eax, eax
>>> mov esp, ebp
>>> pop ebp
>>> ret 0
>>> _main ENDP
>>> _TEXT ENDS
>>> END
>>>
>>> Line 5-6 Creates a stack frame similar to below. It preserves ebp on the
>>> stack, then assgins the esp value to ebp and then decrements esp by 16
>>> bytes.
>>> Line 6-7 Initialises the 3 integer objects , of the array, to 0.
>>> Line 7-8 Stores the address of the first element at the location _px$
>>> points to.
>>> Line 8-9 Moves the literal value of 7 into the 2nd element of the array.
>>>
>>>
>>> 00001C [-------------]
>>> 000018 [--orig ebp---]<- orig esp
>>> 000014 [------0------] <-ebp
>>> 000010 [------7------]
>>> 00000C [------0------]
>>> 000008 [---00000C---] <- esp
>>> 000004 [-------------]
>>> 000000 [-------------]
>>>
>>> After that ebp is popped and esp is back to its original value.
>>> Face the facts about what a pointer is in assembly programming.
>>> If you still do not accept these facts then I urge you to refer to the
>>> link I posted about pointer data types by Randy Hyde.
>>
>> Now you are arguing with yourself: you have just shown that there is
>> no special hidden object which containing the address of the array
>> object; the only thing that contains the address of the array object
>> above is the pointer 'px'.
>>
> No there is a pointer named _arr$, which happens to be in the text
> segment, it is not on the stack.
No, '_arr$' is not a pointer; '_arr$' is a constant used when emitting
machine code in the text segment. If does not exist as a separate
entity in the text segment. lrn2asm.
> Just the same as the pointer _px$ is not on the stack.
> Look at the value of _px$, it is -16, this doesn't mean it's not a
> pointer. Its just a pointer that stores an offset, or an index into the
> stack.
The value of the pointer 'px' is stored on the stack at a location stack
frame pointer + '_px$' (a constant whose value is -16); we have already
told you this.
>
>> For:
>>
>> lea ecx, DWORD PTR _arr$[ebp]
>>
>> what will actually be emitted is:
>>
>> lea ecx, DWORD PTR [ebp-12]
>>
>> as '_arr$' is a constant; not a variable or a "pointer".
>
> _arr$ holds an offset which is added to ebp to create the real address.
Correct we have already told you this.
> _arr$ is a constant only because it is stored in the read only text
> segment. This does not mean it is not a pointer , it stores an offset
> that points to the begining of the array.
As I have already said '_arr$' does not exist as a distinct separate
entity in the text segment; it used when emitting machine code in the
text segment.
> A pointer does not need to store a real address a pointer can also store
> an offset, as in this case.
It is not a pointer; it is a constant used when emitting machine code.
>
>
> Given my stack frame illustration _arr$ points to here:
>
> 00001C [-------------]
> 000018 [--orig ebp---] <- ebp
> 000014 [------0------]
> 000010 [------7------]
> 00000C [------0------] <- _arr$
> 000008 [---00000C---] <- esp
> 000004 [-------------]
> 000000 [-------------]
>
> -12 is an offset into the stack frame, which is the location where the
> array begins.
Finally. Yes -12 is an offset into the stack frame; we have been trying
to tell you this for the past couple of days; -12 is not a pointer or a
variable it is a constant offset. A realistic and correct stack frame
illustration is:
123000 [-------------]
122FFC [--orig ebp---] <- ebp
123FF8 [------0------]
123FF4 [------7------]
123FF0 [------0------] <- ebp + _arr$
123FEC [---123FEC---] <- esp
123FE8 [-------------]
123FE4 [-------------]
Notice how I have replaced your deliberately misleading value of 12
(00000C) with a more realistic value that shows that the contents of the
pointer 'px' is unrelated to the number 12; its value is ebp + _arr$ as
encoded into the emitted machine code in the text segment.
HTH.
/Leigh
[toc] | [prev] | [next] | [standalone]
Page 15 of 21 — ← Prev page 1 … 13 14 [15] 16 17 … 21 Next page →
Back to top | Article view | comp.lang.c++
csiph-web