Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #3956 > unrolled thread
| Started by | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| First post | 2011-04-18 12:44 -0500 |
| Last post | 2011-05-12 13:31 +0100 |
| Articles | 20 on this page of 345 — 21 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-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
Page 14 of 18 — ← Prev page 1 … 12 13 [14] 15 16 … 18 Next page →
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-28 22:04 +0100 |
| Message-ID | <trdEp.7717$Tw4.4984@newsfe26.ams2> |
| In reply to | #5779 |
"Ian Collins" <ian-news@hotmail.com> wrote in message news:94d3qqFr1qU5@mid.individual.net... > On 05/28/11 11:24 PM, Paul wrote: >> >> "Ian Collins"<ian-news@hotmail.com> wrote in message >> news:94b8rkFr1qU2@mid.individual.net... >>> On 05/28/11 02:29 PM, Paul wrote: >>>> >>>> You are very quick to dismiss my opinion of what a pointer is in >>>> assembly >>>> as >>>> incorrect but what exactly is your opinion of what a pointer is? >>> >>> I was equally quick to dismiss the prediction that the world would end >>> last weekend. >>> >>> A pointer in x86 assembly is simply a memory location or register that >>> contains the address of another memory location. That's is not my >>> opinion, it is what it is. >> >> No that is your opinion. >> Other people have different opinions and I happen to be one of those >> people. > > I value the opinions of other professionals I have worked wit or known. So > tell me, how many x86 assembly projects have you worked on? > >> I have already posted a link to Randal Hydes Art of Assembly that >> describes >> what a pointer is, and RH defines that a pointer can be a simple offset. > > No, it does not. As usual you have chosen to misinterpret the link you > have posted. > I didn't interpret the link at all. I quoted it word for word. >> Here is another link that shows some other peoples opinions: >> http://stackoverflow.com/questions/5055619/pointers-seen-on-assembly-or-registries > > So these are trusted sources? If so answer two is the same as mine, > answer one is specific to PIC and answer 3 is a little vague, but contains > the key phrase "with a width appropriate for the addressable size of the > memory segment". So a pointer could be say 1000H, which could be used to > address location 1000H with an immediate access, or loaded to a register > as indirect access. This is analogous to writing > Answer two is nothing like yours. Answer 2 states: "Pointer is nothing but a unsigned integer indicating position in a memory (virtual address space to be precise)." > char c = (char*)0x1000; > > in C++. > >>> The pointers in your example are esp (the stack pointer) and ebp (the >>> base >>> pointer). >> >> These are hardware registers. > > Correct, look at their names again. We are talking about pointers in software, not a hardware pointer. > >>> The instruction >>> >>> mov DWORD PTR _arr$[ebp], 0 >>> >>> given the definition of the constant _arr$ >>> >>> _arr$ = -12 ; size = 12 >>> >>> writes zero the the memory location who's address is ebp-12. Here ebp >>> is >>> the pointer and -12 is the offset. >> >> _arr$ is a label that equates to the value of (-12) . > > That is what I said. You said this meant it was not not a pointer. > >> Here the label _arr$ is used as a pointer, > > No it is used as an offer to a pointer. It's used as an offset to a hardware pointer,because it points to an offset in the stack frame. This does not mean that the offset is not also pointer. > >>> The next assignment which is a bit messy in MASM, >>> >>> mov DWORD PTR _arr$[ebp+4], eax >>> >>> writes zero the the memory location who's address is ebp-12+4. >> >> This confirms that _arr$ is an offset, which is used to create a memory >> address. Therefore it's a pointer. > > No it isn't. It's no more a pointer than the 1 in *(p+1) = 0; No its more like: const int offset_to_array = 1; (p+offset_to_array) > > No tell me again, how many x86 assembly projects have you worked on? > Since when was this discussion limited to x86 processors?
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-29 09:17 +1200 |
| Message-ID | <94d73cFr2iU1@mid.individual.net> |
| In reply to | #5780 |
On 05/29/11 09:04 AM, Paul wrote: > "Ian Collins"<ian-news@hotmail.com> wrote: >> >> No tell me again, how many x86 assembly projects have you worked on? >> > > Since when was this discussion limited to x86 processors? Evasion again I see, so tell me again, how many assembly language projects have you worked on? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-29 09:32 +1200 |
| Message-ID | <94d804Fr2iU2@mid.individual.net> |
| In reply to | #5780 |
On 05/29/11 09:04 AM, Paul wrote: > "Ian Collins"<ian-news@hotmail.com> wrote: >> On 05/28/11 11:24 PM, Paul wrote: >>> >>> This confirms that _arr$ is an offset, which is used to create a memory >>> address. Therefore it's a pointer. >> >> No it isn't. It's no more a pointer than the 1 in *(p+1) = 0; > > No its more like: > const int offset_to_array = 1; > (p+offset_to_array) So offset_to_array is a pointer and 1 isn't? Interesting. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-28 22:58 +0100 |
| Message-ID | <OeeEp.10245$El6.1996@newsfe21.ams2> |
| In reply to | #5783 |
"Ian Collins" <ian-news@hotmail.com> wrote in message news:94d804Fr2iU2@mid.individual.net... > On 05/29/11 09:04 AM, Paul wrote: >> "Ian Collins"<ian-news@hotmail.com> wrote: >>> On 05/28/11 11:24 PM, Paul wrote: >>>> >>>> This confirms that _arr$ is an offset, which is used to create a memory >>>> address. Therefore it's a pointer. >>> >>> No it isn't. It's no more a pointer than the 1 in *(p+1) = 0; >> >> No its more like: >> const int offset_to_array = 1; >> (p+offset_to_array) > > So offset_to_array is a pointer and 1 isn't? Interesting. > offset_to_array is a pointer yes. because its value represents another memory location. It points to that location, albeit an offset to the location , it still points there. 1 is a number, more specifically its an integer.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-29 10:06 +1200 |
| Message-ID | <94d9v1Fr2iU3@mid.individual.net> |
| In reply to | #5784 |
On 05/29/11 09:58 AM, Paul wrote: > > "Ian Collins"<ian-news@hotmail.com> wrote in message > news:94d804Fr2iU2@mid.individual.net... >> On 05/29/11 09:04 AM, Paul wrote: >>> "Ian Collins"<ian-news@hotmail.com> wrote: >>>> On 05/28/11 11:24 PM, Paul wrote: >>>>> >>>>> This confirms that _arr$ is an offset, which is used to create a memory >>>>> address. Therefore it's a pointer. >>>> >>>> No it isn't. It's no more a pointer than the 1 in *(p+1) = 0; >>> >>> No its more like: >>> const int offset_to_array = 1; >>> (p+offset_to_array) >> >> So offset_to_array is a pointer and 1 isn't? Interesting. >> > offset_to_array is a pointer yes. because its value represents another > memory location. It points to that location, albeit an offset to the > location , it still points there. > > 1 is a number, more specifically its an integer. Well well. I think we'll leave it there before this degenerates further into farce. So tell me, how many software projects have you worked on? It's clear youve never done any assembly programming, how about C++? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-28 23:51 +0100 |
| Message-ID | <M%eEp.20729$h35.16116@newsfe19.ams2> |
| In reply to | #5785 |
"Ian Collins" <ian-news@hotmail.com> wrote in message news:94d9v1Fr2iU3@mid.individual.net... > On 05/29/11 09:58 AM, Paul wrote: >> >> "Ian Collins"<ian-news@hotmail.com> wrote in message >> news:94d804Fr2iU2@mid.individual.net... >>> On 05/29/11 09:04 AM, Paul wrote: >>>> "Ian Collins"<ian-news@hotmail.com> wrote: >>>>> On 05/28/11 11:24 PM, Paul wrote: >>>>>> >>>>>> This confirms that _arr$ is an offset, which is used to create a >>>>>> memory >>>>>> address. Therefore it's a pointer. >>>>> >>>>> No it isn't. It's no more a pointer than the 1 in *(p+1) = 0; >>>> >>>> No its more like: >>>> const int offset_to_array = 1; >>>> (p+offset_to_array) >>> >>> So offset_to_array is a pointer and 1 isn't? Interesting. >>> >> offset_to_array is a pointer yes. because its value represents another >> memory location. It points to that location, albeit an offset to the >> location , it still points there. >> >> 1 is a number, more specifically its an integer. > > Well well. I think we'll leave it there before this degenerates further > into farce. Yes you do that. > > So tell me, how many software projects have you worked on? It's clear > youve never done any assembly programming, how about C++? > 5327 . How many have you worked on?
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-28 03:20 +0100 |
| Message-ID | <KZYDp.20072$UY3.11443@newsfe20.ams2> |
| In reply to | #5747 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:8YadndAUkrEr233QnZ2dnUVZ8uKdnZ2d@giganews.com... > On 28/05/2011 01:32, Paul wrote: >> >> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >> news:oJudnW32uqDwpH3QnZ2dnUVZ8hCdnZ2d@giganews.com... >>> On 28/05/2011 00:40, Paul wrote: >>>> >>>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>>> news:UIOdnZ0SveH2iX3QnZ2dnUVZ8hmdnZ2d@giganews.com... >>> >>> [snip] >>> >>>>> It is an integer constant representing an offset to be applied to a >>>>> stack frame pointer; it is NOT a pointer for any definition of >>>>> "pointer"; it is like saying 'foo' below is a C++ pointer because we >>>>> add it to a C++ pointer: >>>>> >>>>> const std::size_t foo = 42; >>>>> int *p = ...; >>>>> int *p2 = p + foo; // is foo a pointer? don't be stupid. >>>>> >>>> No incorrect , you said it was not a pointer in assembly language. >>>> Ovbioustly its not a C++ pointer, its an array type object. >>> >>> Do you not understand the meaning of the words "it is like"? Do you >>> know what an "analogy" is? Have you ever bothered to try "lateral >>> thinking"? >>> >>> I never said it was a C++ pointer; I was giving you a C++ analogy of >>> why a pointer offset (for any definition of "pointer") is not a pointer. >>> >> But a pointer in assembly is not the same as a pointer in C++. A pointer >> in C++ is a pointer type object, or an object of pointer type. >> Assembly does not have types, a pointer in assembly is the same as any >> other variable or constant, except that its intended use is to store an >> address(or an offset) to another memory location. > > I gave you an analogy; you obviously do not understand analogies. An > analogy explains one thing by comparing it to something else and these two > things are *similar* in some respect not the *same*. > You cannot compare an elephants ability to lift objects with its trunk to that of an ant, because an ant doesn't have a trunk. Likewise you cannot compare a C++ type, to an assembler variable or constant because assembler doesn't have types. > Get a clue. > > A pointer in assembly is anything that is being used to store an address > and a constant being used as a stack frame pointer offset is not something > which is being used to store an address; such a constant is only being > used to emit machine code in the text segment. > No you are wrong a pointer is assembly does not necessarily store a real address, a variable that stores an offset or an index is also considered a pointer in assembly language. I refer you to section 5.5 Pointer data types in the following link: http://www.oopweb.com/Assembly/Documents/ArtOfAssembly/Volume/Chapter_5/CH05-1.html#HEADING1-197
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-28 12:34 +0100 |
| Message-ID | <WuidnU4B9qIoQH3QnZ2dnUVZ8nOdnZ2d@giganews.com> |
| In reply to | #5750 |
On 28/05/2011 03:20, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:8YadndAUkrEr233QnZ2dnUVZ8uKdnZ2d@giganews.com... >> On 28/05/2011 01:32, Paul wrote: >>> >>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>> news:oJudnW32uqDwpH3QnZ2dnUVZ8hCdnZ2d@giganews.com... >>>> On 28/05/2011 00:40, Paul wrote: >>>>> >>>>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>>>> news:UIOdnZ0SveH2iX3QnZ2dnUVZ8hmdnZ2d@giganews.com... >>>> >>>> [snip] >>>> >>>>>> It is an integer constant representing an offset to be applied to a >>>>>> stack frame pointer; it is NOT a pointer for any definition of >>>>>> "pointer"; it is like saying 'foo' below is a C++ pointer because we >>>>>> add it to a C++ pointer: >>>>>> >>>>>> const std::size_t foo = 42; >>>>>> int *p = ...; >>>>>> int *p2 = p + foo; // is foo a pointer? don't be stupid. >>>>>> >>>>> No incorrect , you said it was not a pointer in assembly language. >>>>> Ovbioustly its not a C++ pointer, its an array type object. >>>> >>>> Do you not understand the meaning of the words "it is like"? Do you >>>> know what an "analogy" is? Have you ever bothered to try "lateral >>>> thinking"? >>>> >>>> I never said it was a C++ pointer; I was giving you a C++ analogy of >>>> why a pointer offset (for any definition of "pointer") is not a >>>> pointer. >>>> >>> But a pointer in assembly is not the same as a pointer in C++. A pointer >>> in C++ is a pointer type object, or an object of pointer type. >>> Assembly does not have types, a pointer in assembly is the same as any >>> other variable or constant, except that its intended use is to store an >>> address(or an offset) to another memory location. >> >> I gave you an analogy; you obviously do not understand analogies. An >> analogy explains one thing by comparing it to something else and these >> two things are *similar* in some respect not the *same*. >> > You cannot compare an elephants ability to lift objects with its trunk > to that of an ant, because an ant doesn't have a trunk. > Likewise you cannot compare a C++ type, to an assembler variable or > constant because assembler doesn't have types. You still do not understand what an analogy is. Fail. > >> Get a clue. >> >> A pointer in assembly is anything that is being used to store an >> address and a constant being used as a stack frame pointer offset is >> not something which is being used to store an address; such a constant >> is only being used to emit machine code in the text segment. >> > No you are wrong a pointer is assembly does not necessarily store a real > address, a variable that stores an offset or an index is also considered > a pointer in assembly language. No it isn't; see Ian Collins' reply which agrees with what I have been saying with much clarity. > I refer you to section 5.5 Pointer data types in the following link: > http://www.oopweb.com/Assembly/Documents/ArtOfAssembly/Volume/Chapter_5/CH05-1.html#HEADING1-197 Again you are confusing two different terms with the same name: an Intel x86 segment offset is not the same as an offset used in conjunction with a pointer (or address). Read decent computer science books not ancient (i.e. mostly irrelevant) x86 online asm tutorials. lrn2asm. lrn2program. lrn2logic. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-28 12:56 +0100 |
| Message-ID | <5q5Ep.20851$UY3.9185@newsfe20.ams2> |
| In reply to | #5760 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:WuidnU4B9qIoQH3QnZ2dnUVZ8nOdnZ2d@giganews.com... > On 28/05/2011 03:20, Paul wrote: >> >> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >> news:8YadndAUkrEr233QnZ2dnUVZ8uKdnZ2d@giganews.com... >>> On 28/05/2011 01:32, Paul wrote: >>>> >>>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>>> news:oJudnW32uqDwpH3QnZ2dnUVZ8hCdnZ2d@giganews.com... >>>>> On 28/05/2011 00:40, Paul wrote: >>>>>> >>>>>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>>>>> news:UIOdnZ0SveH2iX3QnZ2dnUVZ8hmdnZ2d@giganews.com... >>>>> >>>>> [snip] >>>>> >>>>>>> It is an integer constant representing an offset to be applied to a >>>>>>> stack frame pointer; it is NOT a pointer for any definition of >>>>>>> "pointer"; it is like saying 'foo' below is a C++ pointer because we >>>>>>> add it to a C++ pointer: >>>>>>> >>>>>>> const std::size_t foo = 42; >>>>>>> int *p = ...; >>>>>>> int *p2 = p + foo; // is foo a pointer? don't be stupid. >>>>>>> >>>>>> No incorrect , you said it was not a pointer in assembly language. >>>>>> Ovbioustly its not a C++ pointer, its an array type object. >>>>> >>>>> Do you not understand the meaning of the words "it is like"? Do you >>>>> know what an "analogy" is? Have you ever bothered to try "lateral >>>>> thinking"? >>>>> >>>>> I never said it was a C++ pointer; I was giving you a C++ analogy of >>>>> why a pointer offset (for any definition of "pointer") is not a >>>>> pointer. >>>>> >>>> But a pointer in assembly is not the same as a pointer in C++. A >>>> pointer >>>> in C++ is a pointer type object, or an object of pointer type. >>>> Assembly does not have types, a pointer in assembly is the same as any >>>> other variable or constant, except that its intended use is to store an >>>> address(or an offset) to another memory location. >>> >>> I gave you an analogy; you obviously do not understand analogies. An >>> analogy explains one thing by comparing it to something else and these >>> two things are *similar* in some respect not the *same*. >>> >> You cannot compare an elephants ability to lift objects with its trunk >> to that of an ant, because an ant doesn't have a trunk. >> Likewise you cannot compare a C++ type, to an assembler variable or >> constant because assembler doesn't have types. > > You still do not understand what an analogy is. Fail. > >> >>> Get a clue. >>> >>> A pointer in assembly is anything that is being used to store an >>> address and a constant being used as a stack frame pointer offset is >>> not something which is being used to store an address; such a constant >>> is only being used to emit machine code in the text segment. >>> >> No you are wrong a pointer is assembly does not necessarily store a real >> address, a variable that stores an offset or an index is also considered >> a pointer in assembly language. > > No it isn't; see Ian Collins' reply which agrees with what I have been > saying with much clarity. > >> I refer you to section 5.5 Pointer data types in the following link: >> http://www.oopweb.com/Assembly/Documents/ArtOfAssembly/Volume/Chapter_5/CH05-1.html#HEADING1-197 > > Again you are confusing two different terms with the same name: an Intel > x86 segment offset is not the same as an offset used in conjunction with a > pointer (or address). I never even mentioned segment offsets. You are the one who seems confused. > > Read decent computer science books not ancient (i.e. mostly irrelevant) > x86 online asm tutorials. > I just posted a link to one, why don't you read it.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-28 13:49 +0100 |
| Message-ID | <nY2dnaT_JtLTcn3QnZ2dnUVZ8tadnZ2d@giganews.com> |
| In reply to | #5762 |
On 28/05/2011 12:56, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:WuidnU4B9qIoQH3QnZ2dnUVZ8nOdnZ2d@giganews.com... >> On 28/05/2011 03:20, Paul wrote: >>> >>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>> news:8YadndAUkrEr233QnZ2dnUVZ8uKdnZ2d@giganews.com... >>>> On 28/05/2011 01:32, Paul wrote: >>>>> >>>>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>>>> news:oJudnW32uqDwpH3QnZ2dnUVZ8hCdnZ2d@giganews.com... >>>>>> On 28/05/2011 00:40, Paul wrote: >>>>>>> >>>>>>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>>>>>> news:UIOdnZ0SveH2iX3QnZ2dnUVZ8hmdnZ2d@giganews.com... >>>>>> >>>>>> [snip] >>>>>> >>>>>>>> It is an integer constant representing an offset to be applied to a >>>>>>>> stack frame pointer; it is NOT a pointer for any definition of >>>>>>>> "pointer"; it is like saying 'foo' below is a C++ pointer >>>>>>>> because we >>>>>>>> add it to a C++ pointer: >>>>>>>> >>>>>>>> const std::size_t foo = 42; >>>>>>>> int *p = ...; >>>>>>>> int *p2 = p + foo; // is foo a pointer? don't be stupid. >>>>>>>> >>>>>>> No incorrect , you said it was not a pointer in assembly language. >>>>>>> Ovbioustly its not a C++ pointer, its an array type object. >>>>>> >>>>>> Do you not understand the meaning of the words "it is like"? Do you >>>>>> know what an "analogy" is? Have you ever bothered to try "lateral >>>>>> thinking"? >>>>>> >>>>>> I never said it was a C++ pointer; I was giving you a C++ analogy of >>>>>> why a pointer offset (for any definition of "pointer") is not a >>>>>> pointer. >>>>>> >>>>> But a pointer in assembly is not the same as a pointer in C++. A >>>>> pointer >>>>> in C++ is a pointer type object, or an object of pointer type. >>>>> Assembly does not have types, a pointer in assembly is the same as any >>>>> other variable or constant, except that its intended use is to >>>>> store an >>>>> address(or an offset) to another memory location. >>>> >>>> I gave you an analogy; you obviously do not understand analogies. An >>>> analogy explains one thing by comparing it to something else and these >>>> two things are *similar* in some respect not the *same*. >>>> >>> You cannot compare an elephants ability to lift objects with its trunk >>> to that of an ant, because an ant doesn't have a trunk. >>> Likewise you cannot compare a C++ type, to an assembler variable or >>> constant because assembler doesn't have types. >> >> You still do not understand what an analogy is. Fail. >> >>> >>>> Get a clue. >>>> >>>> A pointer in assembly is anything that is being used to store an >>>> address and a constant being used as a stack frame pointer offset is >>>> not something which is being used to store an address; such a constant >>>> is only being used to emit machine code in the text segment. >>>> >>> No you are wrong a pointer is assembly does not necessarily store a real >>> address, a variable that stores an offset or an index is also considered >>> a pointer in assembly language. >> >> No it isn't; see Ian Collins' reply which agrees with what I have been >> saying with much clarity. >> >>> I refer you to section 5.5 Pointer data types in the following link: >>> http://www.oopweb.com/Assembly/Documents/ArtOfAssembly/Volume/Chapter_5/CH05-1.html#HEADING1-197 >>> >> >> Again you are confusing two different terms with the same name: an >> Intel x86 segment offset is not the same as an offset used in >> conjunction with a pointer (or address). > > I never even mentioned segment offsets. You are the one who seems confused. The link you posted talks about x86 segment offsets so obviously one can only conclude that that is what you are referring to when you erroneously say an offset can be a pointer. Get a f**king clue. In x86 a segment offset can be considered a pointer as it forms part of a logical address but we are not talking about segment offsets; we are talking about offsets applied to already formed logical addresses. > > >> >> Read decent computer science books not ancient (i.e. mostly >> irrelevant) x86 online asm tutorials. >> > > I just posted a link to one, why don't you read it. You posted a link to a 15 year old book on x86 assembly language programming which is mostly irrelevant to what we are discussing. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-28 14:48 +0100 |
| Message-ID | <n37Ep.27957$yI6.3250@newsfe06.ams2> |
| In reply to | #5765 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:nY2dnaT_JtLTcn3QnZ2dnUVZ8tadnZ2d@giganews.com... > On 28/05/2011 12:56, Paul wrote: >> >>>>>>> [snip] >>>>>>> >>>>>>>>> It is an integer constant representing an offset to be applied to >>>>>>>>> a >>>>>>>>> stack frame pointer; it is NOT a pointer for any definition of >>>>>>>>> "pointer"; it is like saying 'foo' below is a C++ pointer >>>>>>>>> because we >>>>>>>>> add it to a C++ pointer: >>>>>>>>> >>>>>>>>> const std::size_t foo = 42; >>>>>>>>> int *p = ...; >>>>>>>>> int *p2 = p + foo; // is foo a pointer? don't be stupid. >>>>>>>>> >>>>>>>> No incorrect , you said it was not a pointer in assembly language. >>>>>>>> Ovbioustly its not a C++ pointer, its an array type object. >>>>>>> >>>>>>> Do you not understand the meaning of the words "it is like"? Do you >>>>>>> know what an "analogy" is? Have you ever bothered to try "lateral >>>>>>> thinking"? >>>>>>> >>>>>>> I never said it was a C++ pointer; I was giving you a C++ analogy of >>>>>>> why a pointer offset (for any definition of "pointer") is not a >>>>>>> pointer. >>>>>>> >>>>>> But a pointer in assembly is not the same as a pointer in C++. A >>>>>> pointer >>>>>> in C++ is a pointer type object, or an object of pointer type. >>>>>> Assembly does not have types, a pointer in assembly is the same as >>>>>> any >>>>>> other variable or constant, except that its intended use is to >>>>>> store an >>>>>> address(or an offset) to another memory location. >>>>> >>>>> I gave you an analogy; you obviously do not understand analogies. An >>>>> analogy explains one thing by comparing it to something else and these >>>>> two things are *similar* in some respect not the *same*. >>>>> >>>> You cannot compare an elephants ability to lift objects with its trunk >>>> to that of an ant, because an ant doesn't have a trunk. >>>> Likewise you cannot compare a C++ type, to an assembler variable or >>>> constant because assembler doesn't have types. >>> >>> You still do not understand what an analogy is. Fail. >>> >>>> >>>>> Get a clue. >>>>> >>>>> A pointer in assembly is anything that is being used to store an >>>>> address and a constant being used as a stack frame pointer offset is >>>>> not something which is being used to store an address; such a constant >>>>> is only being used to emit machine code in the text segment. >>>>> >>>> No you are wrong a pointer is assembly does not necessarily store a >>>> real >>>> address, a variable that stores an offset or an index is also >>>> considered >>>> a pointer in assembly language. >>> >>> No it isn't; see Ian Collins' reply which agrees with what I have been >>> saying with much clarity. >>> >>>> I refer you to section 5.5 Pointer data types in the following link: >>>> http://www.oopweb.com/Assembly/Documents/ArtOfAssembly/Volume/Chapter_5/CH05-1.html#HEADING1-197 >>>> >>> >>> Again you are confusing two different terms with the same name: an >>> Intel x86 segment offset is not the same as an offset used in >>> conjunction with a pointer (or address). >> >> I never even mentioned segment offsets. You are the one who seems >> confused. > > The link you posted talks about x86 segment offsets so obviously one can > only conclude that that is what you are referring to when you erroneously > say an offset can be a pointer. Get a f**king clue. In x86 a segment > offset can be considered a pointer as it forms part of a logical address > but we are not talking about segment offsets; we are talking about offsets > applied to already formed logical addresses. > No the example uses segment offset addressing as an example. You are confusing the term "offset" with this seg::offset addressing syntax. An "offset" is an integer value which is added to another integer value to create an address. An "offset" can be used in many contexts and the context in which I have been using the term "offset" is not in the context you incorrectly interpret as seg::offset addressing. This is also not to be confused with the asm OFFSET instruction which gets the address of a varaible, before you try and bring that into the debate. >> >> >>> >>> Read decent computer science books not ancient (i.e. mostly >>> irrelevant) x86 online asm tutorials. >>> >> >> I just posted a link to one, why don't you read it. > > You posted a link to a 15 year old book on x86 assembly language > programming which is mostly irrelevant to what we are discussing. > So what if its 15 years old there are very few up to date asm books available on the net. The value -12 is a pointer to the array on the main stack frame. It doesn't make any difference if it's declared as a variable i.e: a_ptr DD -12 ;as a variable b_ptr = -12 ;as a label. The value -12 is an offset to to the frame pointer ebp, which results in the address of the array.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-28 15:10 +0100 |
| Message-ID | <1MGdnVQL9Zv2n3zQnZ2dnUVZ8gSdnZ2d@giganews.com> |
| In reply to | #5766 |
On 28/05/2011 14:48, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:nY2dnaT_JtLTcn3QnZ2dnUVZ8tadnZ2d@giganews.com... >> On 28/05/2011 12:56, Paul wrote: >>> >>>>>>>> [snip] >>>>>>>> >>>>>>>>>> It is an integer constant representing an offset to be applied >>>>>>>>>> to a >>>>>>>>>> stack frame pointer; it is NOT a pointer for any definition of >>>>>>>>>> "pointer"; it is like saying 'foo' below is a C++ pointer >>>>>>>>>> because we >>>>>>>>>> add it to a C++ pointer: >>>>>>>>>> >>>>>>>>>> const std::size_t foo = 42; >>>>>>>>>> int *p = ...; >>>>>>>>>> int *p2 = p + foo; // is foo a pointer? don't be stupid. >>>>>>>>>> >>>>>>>>> No incorrect , you said it was not a pointer in assembly language. >>>>>>>>> Ovbioustly its not a C++ pointer, its an array type object. >>>>>>>> >>>>>>>> Do you not understand the meaning of the words "it is like"? Do you >>>>>>>> know what an "analogy" is? Have you ever bothered to try "lateral >>>>>>>> thinking"? >>>>>>>> >>>>>>>> I never said it was a C++ pointer; I was giving you a C++ >>>>>>>> analogy of >>>>>>>> why a pointer offset (for any definition of "pointer") is not a >>>>>>>> pointer. >>>>>>>> >>>>>>> But a pointer in assembly is not the same as a pointer in C++. A >>>>>>> pointer >>>>>>> in C++ is a pointer type object, or an object of pointer type. >>>>>>> Assembly does not have types, a pointer in assembly is the same >>>>>>> as any >>>>>>> other variable or constant, except that its intended use is to >>>>>>> store an >>>>>>> address(or an offset) to another memory location. >>>>>> >>>>>> I gave you an analogy; you obviously do not understand analogies. An >>>>>> analogy explains one thing by comparing it to something else and >>>>>> these >>>>>> two things are *similar* in some respect not the *same*. >>>>>> >>>>> You cannot compare an elephants ability to lift objects with its trunk >>>>> to that of an ant, because an ant doesn't have a trunk. >>>>> Likewise you cannot compare a C++ type, to an assembler variable or >>>>> constant because assembler doesn't have types. >>>> >>>> You still do not understand what an analogy is. Fail. >>>> >>>>> >>>>>> Get a clue. >>>>>> >>>>>> A pointer in assembly is anything that is being used to store an >>>>>> address and a constant being used as a stack frame pointer offset is >>>>>> not something which is being used to store an address; such a >>>>>> constant >>>>>> is only being used to emit machine code in the text segment. >>>>>> >>>>> No you are wrong a pointer is assembly does not necessarily store a >>>>> real >>>>> address, a variable that stores an offset or an index is also >>>>> considered >>>>> a pointer in assembly language. >>>> >>>> No it isn't; see Ian Collins' reply which agrees with what I have been >>>> saying with much clarity. >>>> >>>>> I refer you to section 5.5 Pointer data types in the following link: >>>>> http://www.oopweb.com/Assembly/Documents/ArtOfAssembly/Volume/Chapter_5/CH05-1.html#HEADING1-197 >>>>> >>>>> >>>> >>>> Again you are confusing two different terms with the same name: an >>>> Intel x86 segment offset is not the same as an offset used in >>>> conjunction with a pointer (or address). >>> >>> I never even mentioned segment offsets. You are the one who seems >>> confused. >> >> The link you posted talks about x86 segment offsets so obviously one >> can only conclude that that is what you are referring to when you >> erroneously say an offset can be a pointer. Get a f**king clue. In x86 >> a segment offset can be considered a pointer as it forms part of a >> logical address but we are not talking about segment offsets; we are >> talking about offsets applied to already formed logical addresses. >> > No the example uses segment offset addressing as an example. You are > confusing the term "offset" with this seg::offset addressing syntax. You are the one posting spurious links to irrelevent details of x86 assembly language programming; you are the one trying to force equivalence between the different terms "offset" and "pointer". > > An "offset" is an integer value which is added to another integer value > to create an address. No; an "offset" is added to an address to create another address. > An "offset" can be used in many contexts and the context in which I have > been using the term "offset" is not in the context you incorrectly > interpret as seg::offset addressing. So why post a link which implies that that was *your* interpretation? > > This is also not to be confused with the asm OFFSET instruction which > gets the address of a varaible, before you try and bring that into the > debate. You are the one bringing irrelevances into what you laughingly call a "debate". > > > >>> >>> >>>> >>>> Read decent computer science books not ancient (i.e. mostly >>>> irrelevant) x86 online asm tutorials. >>>> >>> >>> I just posted a link to one, why don't you read it. >> >> You posted a link to a 15 year old book on x86 assembly language >> programming which is mostly irrelevant to what we are discussing. >> > So what if its 15 years old there are very few up to date asm books > available on the net. > > The value -12 is a pointer to the array on the main stack frame. > It doesn't make any difference if it's declared as a variable i.e: > > a_ptr DD -12 ;as a variable > b_ptr = -12 ;as a label. > > > The value -12 is an offset to to the frame pointer ebp, which results in > the address of the array. A label being the name of a constant used as an offset applied to the stack frame pointer IS NOT A POINTER; it is an offset; an offset *applied* to a pointer. Get a f**king clue. One can simulate a pointer to an array element using array indices (offsets) but this is a purely a simulation; it is not a true pointer. lrn2asm. HTH. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-28 19:35 +0100 |
| Message-ID | <mgbEp.28410$%o4.26068@newsfe16.ams2> |
| In reply to | #5767 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:1MGdnVQL9Zv2n3zQnZ2dnUVZ8gSdnZ2d@giganews.com... > On 28/05/2011 14:48, Paul wrote: >> >>>>>>>>> [snip] >>>>>>>>> >>>>>>>>>>> It is an integer constant representing an offset to be applied >>>>>>>>>>> to a >>>>>>>>>>> stack frame pointer; it is NOT a pointer for any definition of >>>>>>>>>>> "pointer"; it is like saying 'foo' below is a C++ pointer >>>>>>>>>>> because we >>>>>>>>>>> add it to a C++ pointer: >>>>>>>>>>> >>>>>>>>>>> const std::size_t foo = 42; >>>>>>>>>>> int *p = ...; >>>>>>>>>>> int *p2 = p + foo; // is foo a pointer? don't be stupid. >>>>>>>>>>> >>>>>>>>>> No incorrect , you said it was not a pointer in assembly >>>>>>>>>> language. >>>>>>>>>> Ovbioustly its not a C++ pointer, its an array type object. >>>>>>>>> >>>>>>>>> Do you not understand the meaning of the words "it is like"? Do >>>>>>>>> you >>>>>>>>> know what an "analogy" is? Have you ever bothered to try "lateral >>>>>>>>> thinking"? >>>>>>>>> >>>>>>>>> I never said it was a C++ pointer; I was giving you a C++ >>>>>>>>> analogy of >>>>>>>>> why a pointer offset (for any definition of "pointer") is not a >>>>>>>>> pointer. >>>>>>>>> >>>>>>>> But a pointer in assembly is not the same as a pointer in C++. A >>>>>>>> pointer >>>>>>>> in C++ is a pointer type object, or an object of pointer type. >>>>>>>> Assembly does not have types, a pointer in assembly is the same >>>>>>>> as any >>>>>>>> other variable or constant, except that its intended use is to >>>>>>>> store an >>>>>>>> address(or an offset) to another memory location. >>>>>>> >>>>>>> I gave you an analogy; you obviously do not understand analogies. An >>>>>>> analogy explains one thing by comparing it to something else and >>>>>>> these >>>>>>> two things are *similar* in some respect not the *same*. >>>>>>> >>>>>> You cannot compare an elephants ability to lift objects with its >>>>>> trunk >>>>>> to that of an ant, because an ant doesn't have a trunk. >>>>>> Likewise you cannot compare a C++ type, to an assembler variable or >>>>>> constant because assembler doesn't have types. >>>>> >>>>> You still do not understand what an analogy is. Fail. >>>>> >>>>>> >>>>>>> Get a clue. >>>>>>> >>>>>>> A pointer in assembly is anything that is being used to store an >>>>>>> address and a constant being used as a stack frame pointer offset is >>>>>>> not something which is being used to store an address; such a >>>>>>> constant >>>>>>> is only being used to emit machine code in the text segment. >>>>>>> >>>>>> No you are wrong a pointer is assembly does not necessarily store a >>>>>> real >>>>>> address, a variable that stores an offset or an index is also >>>>>> considered >>>>>> a pointer in assembly language. >>>>> >>>>> No it isn't; see Ian Collins' reply which agrees with what I have been >>>>> saying with much clarity. >>>>> >>>>>> I refer you to section 5.5 Pointer data types in the following link: >>>>>> http://www.oopweb.com/Assembly/Documents/ArtOfAssembly/Volume/Chapter_5/CH05-1.html#HEADING1-197 >>>>>> >>>>>> >>>>> >>>>> Again you are confusing two different terms with the same name: an >>>>> Intel x86 segment offset is not the same as an offset used in >>>>> conjunction with a pointer (or address). >>>> >>>> I never even mentioned segment offsets. You are the one who seems >>>> confused. >>> >>> The link you posted talks about x86 segment offsets so obviously one >>> can only conclude that that is what you are referring to when you >>> erroneously say an offset can be a pointer. Get a f**king clue. In x86 >>> a segment offset can be considered a pointer as it forms part of a >>> logical address but we are not talking about segment offsets; we are >>> talking about offsets applied to already formed logical addresses. >>> >> No the example uses segment offset addressing as an example. You are >> confusing the term "offset" with this seg::offset addressing syntax. > > You are the one posting spurious links to irrelevent details of x86 > assembly language programming; you are the one trying to force equivalence > between the different terms "offset" and "pointer". > Its not a spurious link , it is a link that gives a general definition of a pointer in assembly language. >> >> An "offset" is an integer value which is added to another integer value >> to create an address. > > No; an "offset" is added to an address to create another address. An address is an integer. > >> An "offset" can be used in many contexts and the context in which I have >> been using the term "offset" is not in the context you incorrectly >> interpret as seg::offset addressing. > > So why post a link which implies that that was *your* interpretation? > The link didn't imply my interpretation of anything. It's a link that gives a general definiton of a pointer in assembly. . >> This is also not to be confused with the asm OFFSET instruction which >> gets the address of a varaible, before you try and bring that into the >> debate. > > You are the one bringing irrelevances into what you laughingly call a > "debate". > >> >> >> >>>> >>>> >>>>> >>>>> Read decent computer science books not ancient (i.e. mostly >>>>> irrelevant) x86 online asm tutorials. >>>>> >>>> >>>> I just posted a link to one, why don't you read it. >>> >>> You posted a link to a 15 year old book on x86 assembly language >>> programming which is mostly irrelevant to what we are discussing. >>> >> So what if its 15 years old there are very few up to date asm books >> available on the net. >> >> The value -12 is a pointer to the array on the main stack frame. >> It doesn't make any difference if it's declared as a variable i.e: >> >> a_ptr DD -12 ;as a variable >> b_ptr = -12 ;as a label. >> >> >> The value -12 is an offset to to the frame pointer ebp, which results in >> the address of the array. > > A label being the name of a constant used as an offset applied to the > stack frame pointer IS NOT A POINTER; it is an offset; an offset *applied* > to a pointer. Yes it is. A pointer is something that points to another location. _arr$ has the value -12 , so it points -12 bytes into the stack frame. ebp is the stack base pointer and it's a hardware register that stores the addrress of the stack frame. When _arr$ is added to ebp, _arr$ is being used as a pointer, relative to the stack base. Obviously you think a pointer is an object that resembles a C++ pointer and must be a memory location that stores a memory address or soemthing, so you disagree. That's your opinion on what a pointer is an your welcome to it. I disagree so stop spamming nonsense. > > Get a f**king clue. And abuse. > > One can simulate a pointer to an array element using array indices > (offsets) but this is a purely a simulation; it is not a true pointer. > A pointer is something that points to a location, whether it's relative or direct. You can go simulate something that points to something if you like. GL.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-28 19:59 +0100 |
| Message-ID | <s5ydnRn_jfmR23zQnZ2dnUVZ8qadnZ2d@giganews.com> |
| In reply to | #5773 |
On 28/05/2011 19:35, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:1MGdnVQL9Zv2n3zQnZ2dnUVZ8gSdnZ2d@giganews.com... >> >> Get a f**king clue. > > And abuse. You don't like abuse? You posted the following in February to this very newsgroup: "They lose an argument because I provide supporting links from Stroustrup and intellegnet arguments, while they provide no more than, they know it all therefor they are right, as an argument. They show nothing more than fear , they are cowards and lack intelligence and wit. This forum has turned into the most homosexual group of losers I ever seen in my life." If you don't like abuse then perhaps you should stop with the abuse yourself? A good start would be for you to try dealing with your own homophobia. Also look up the word "hypocrisy" in a dictionary. HTH. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-28 20:17 +0100 |
| Message-ID | <M9ydnS2JTZmo13zQnZ2dnUVZ8tqdnZ2d@giganews.com> |
| In reply to | #5775 |
On 28/05/2011 19:59, Leigh Johnston wrote: > On 28/05/2011 19:35, Paul wrote: >> >> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >> news:1MGdnVQL9Zv2n3zQnZ2dnUVZ8gSdnZ2d@giganews.com... >>> >>> Get a f**king clue. >> >> And abuse. > > You don't like abuse? > > You posted the following in February to this very newsgroup: > > "They lose an argument because I provide supporting links from > Stroustrup and intellegnet arguments, while they provide no more than, > they know it all therefor they are right, as an argument. They show > nothing more than fear , they are cowards and lack intelligence and wit. > This forum has turned into the most homosexual group of losers I ever > seen in my life." > > If you don't like abuse then perhaps you should stop with the abuse > yourself? A good start would be for you to try dealing with your own > homophobia. Also look up the word "hypocrisy" in a dictionary. > > HTH. If you are interested in other similar Paul abuse try the following Google search: http://lmgtfy.com/?q=pchristor+gay The Internet keeps records; you are a number; you are not a free man. HTH. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-28 20:44 +0100 |
| Message-ID | <zgcEp.19381$8A7.9124@newsfe12.ams2> |
| In reply to | #5775 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:s5ydnRn_jfmR23zQnZ2dnUVZ8qadnZ2d@giganews.com... > On 28/05/2011 19:35, Paul wrote: >> >> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >> news:1MGdnVQL9Zv2n3zQnZ2dnUVZ8gSdnZ2d@giganews.com... >>> >>> Get a f**king clue. >> >> And abuse. > > You don't like abuse? > > You posted the following in February to this very newsgroup: > > "They lose an argument because I provide supporting links from Stroustrup > and intellegnet arguments, while they provide no more than, they know it > all therefor they are right, as an argument. They show nothing more than > fear , they are cowards and lack intelligence and wit. This forum has > turned into the most homosexual group of losers I ever seen in my life." > > If you don't like abuse then perhaps you should stop with the abuse > yourself? A good start would be for you to try dealing with your own > homophobia. Also look up the word "hypocrisy" in a dictionary. > > HTH. > Obviously this has hit a raw nerve with you. If homosexuals now consider being called gay, abusive. Or homophobic or whatever then thats not my problem. I don't care what is the latest trend on gay street and what is or isn't considered acceptable to them. Go find a suitable newsgroup.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-05-28 21:00 +0100 |
| Message-ID | <4ZOdnQPeHY7yyXzQnZ2dnUVZ8kKdnZ2d@giganews.com> |
| In reply to | #5777 |
On 28/05/2011 20:44, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:s5ydnRn_jfmR23zQnZ2dnUVZ8qadnZ2d@giganews.com... >> On 28/05/2011 19:35, Paul wrote: >>> >>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>> news:1MGdnVQL9Zv2n3zQnZ2dnUVZ8gSdnZ2d@giganews.com... >>>> >>>> Get a f**king clue. >>> >>> And abuse. >> >> You don't like abuse? >> >> You posted the following in February to this very newsgroup: >> >> "They lose an argument because I provide supporting links from >> Stroustrup and intellegnet arguments, while they provide no more than, >> they know it all therefor they are right, as an argument. They show >> nothing more than fear , they are cowards and lack intelligence and >> wit. This forum has turned into the most homosexual group of losers I >> ever seen in my life." >> >> If you don't like abuse then perhaps you should stop with the abuse >> yourself? A good start would be for you to try dealing with your own >> homophobia. Also look up the word "hypocrisy" in a dictionary. >> >> HTH. >> > Obviously this has hit a raw nerve with you. > > If homosexuals now consider being called gay, abusive. Or homophobic or > whatever then thats not my problem. I don't care what is the latest > trend on gay street and what is or isn't considered acceptable to them. > > Go find a suitable newsgroup. > You really are dumb aren't you? You were obviously trying to use the words "homosexual" or "gay" as an insult which is homophobic, i.e. implying that being homosexual is somehow a negative thing making it suitable to be an insult in your tiny mind. But you are correct this is off-topic just stop being such a fucking hypocrite. BTW this is a perfect opportunity for you to apologize if you are man enough. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-28 22:07 +0100 |
| Message-ID | <iudEp.10176$El6.413@newsfe21.ams2> |
| In reply to | #5778 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:4ZOdnQPeHY7yyXzQnZ2dnUVZ8kKdnZ2d@giganews.com... > On 28/05/2011 20:44, Paul wrote: >> >> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >> news:s5ydnRn_jfmR23zQnZ2dnUVZ8qadnZ2d@giganews.com... >>> On 28/05/2011 19:35, Paul wrote: >>>> >>>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>>> news:1MGdnVQL9Zv2n3zQnZ2dnUVZ8gSdnZ2d@giganews.com... >>>>> >>>>> Get a f**king clue. >>>> >>>> And abuse. >>> >>> You don't like abuse? >>> >>> You posted the following in February to this very newsgroup: >>> >>> "They lose an argument because I provide supporting links from >>> Stroustrup and intellegnet arguments, while they provide no more than, >>> they know it all therefor they are right, as an argument. They show >>> nothing more than fear , they are cowards and lack intelligence and >>> wit. This forum has turned into the most homosexual group of losers I >>> ever seen in my life." >>> >>> If you don't like abuse then perhaps you should stop with the abuse >>> yourself? A good start would be for you to try dealing with your own >>> homophobia. Also look up the word "hypocrisy" in a dictionary. >>> >>> HTH. >>> >> Obviously this has hit a raw nerve with you. >> >> If homosexuals now consider being called gay, abusive. Or homophobic or >> whatever then thats not my problem. I don't care what is the latest >> trend on gay street and what is or isn't considered acceptable to them. >> >> Go find a suitable newsgroup. >> > > You really are dumb aren't you? You were obviously trying to use the > words "homosexual" or "gay" as an insult which is homophobic, i.e. > implying that being homosexual is somehow a negative thing making it > suitable to be an insult in your tiny mind. > > But you are correct this is off-topic just stop being such a fucking > hypocrite. > > BTW this is a perfect opportunity for you to apologize if you are man > enough. > Like i said if you wish to discuss these kind of things you should go find a suitable newsgroup. It does not interest me.
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-05-26 14:38 -0500 |
| Message-ID | <slrnittb1q.25so.aggedor@earl-grey.cloud9.net> |
| In reply to | #5520 |
On 2011-05-25, Paul <pchristor@yahoo.co.uk> wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrnitqfvi.10rf.aggedor@earl-grey.cloud9.net...
>> [snip]
>>> When you dereference a pointer to int you access the pointed to integer
>>> object like so :
>>> int x=5;
>>> int* px = &x;
>>> std::cout<< *px;
>>> //this will output 5 because dereferencing px accesses the object it
>>> points
>>> to.
>>>
>>>
>>> With an array the situation is not the same becasue an array cannot be
>>> accessed, as a whole. The only way we can point to an array is to point
>>> to
>>> one of its elements.
>>> int arr[3] = {1,2,3};
>>> int* parr = arr;
>>> int (*pparr)[3] = &arr;
>>>
>>> std::cout<< *parr;
>>> //outputs 1 because it points to the first element of the array.
>>> std::cout<<*pparr;
>>> //outputs a memory address because it points to an array-type object.
>>
>> The situation with the unary * and unary & operators is the same for
>> an array and for a non-array. The C++ standard does not specify
>> different behaviors depending on whether the operand of the unary *
>> and unary & operators is an array or non-array.
>>
>> Here is the paragraph from the C++ standard about the unary *
>> operator.
>>
>> The unary * operator performs indirection: the expression to which
>> it is applied shall be a pointer to an object type, or a pointer to
>> a function type and the result is an lvalue referring to the object
>> or function to which the expression points. If the type of the
>> expression is "pointer to T", the type of the result is "T".
>> [Note: a pointer to an incomplete type (other than cv void ) can be
>> dereferenced. The lvalue thus obtained can be used in limited ways
>> (to initialize a reference, for example); this lvalue must not be
>> converted to an rvalue, see 4.1. ]
>>
>> The C++ standard does not specify different behaviors for an array
>> and a non-array with the unary * operator.
>>
>> Here is the paragraph from the C++ standard about the unary &
>> operator.
>>
>> The result of the unary & operator is a pointer to its operand.
>> The operand shall be an lvalue or a qualified-id. In the first
>> case, if the type of the expression is "T", the type of the result
>> is "pointer to T". In particular, the address of an object of type
>> "cv T" is "pointer to cv T", with the same cv-qualifiers. For a
>> qualified-id, if the member is a static member of type "T", the
>> type of the result is plain "pointer to T". If the member is
>> a nonstatic member of class C of type T, the type of the result is
>> "pointer to member of class C of type T." [Example:
>>
>> struct A { int i; };
>> struct B : A { };
>> ... &B::i ... // has type int A::*
>>
>> --end example] [Note: a pointer to member formed from a mutable
>> nonstatic data member (7.1.1) does not reflect the mutable
>> specifier associated with the nonstatic data member. ]
>>
>> The C++ standard does not specify different behaviors for an array
>> and a non-array with the unary & operator.
>>
>> A difference with array and non-array results is that
>> array-to-pointer conversion is applied to an array result.
>>
>> In your example, the statement
>>
>> int* parr = arr;
>>
>> implicitly applies array-to-pointer conversion to the array result of
>> the expression arr. The result of that conversion is a pointer to
>> the first element of arr, not a pointer to arr. Because parr is a
>> pointer to int, the result of dereferencing it is an int.
>>
>> In your example, the statement
>>
>> int (*pparr)[3] = &arr;
>>
>> initializes pparr with a pointer to arr, not a pointer to an element
>> of arr. Because pparr is a pointer to an array of int, the result of
>> dereferencing it is an array of int. Array-to-pointer conversion is
>> implicitly applied to that result and the result of the conversion
>> is a pointer to int that points to the first element of arr.
>>
>>> An array identifier such as 'arr' is an array-type object. A pointer to
>>> this
>>> object points to a single object, not to an array of thi sobject type.
>>
>> The result of using the identifier 'arr' in an expression is an
>> array. An array is a single object that contains sub-objects. The
>> expression &arr points to the object that is the array named arr.
>>
>>>> Given the declaration
>>>>
>>>> int arr[4];
>>>>
>>>> a C++ implementaion creates an array object to represent the array,
>>>> but it does not also create an object that stores a pointer to the
>>>> array object, unless one is explicitly present, say due to the
>>>> declaration
>>>>
>>>> int (*pparr)[4] = &arr;
>>>>
>>>> Due to that statement a C++ implementation creates a pointer to
>>>> array object that is initialized to point to the array. The
>>>> pointer points directly to the array object.
>>>
>>> The pointer pparr above points to a single object not an array of
>>> objects.
>>> Consider this:
>>>
>>> int (*p)[3]=0;
>>> std::cout<<*p<<std::endl;
>>> std::cout<< typeid(*p).name()<<std::endl;
>>> std::cout<< sizeof(*p);
>>>
>>> Does the above pointer point to a valid object?
>>> Or is it completely UB because its dereferencing a null pointer?
>>
>> Having the value of a pointer be the null pointer is valid. The
>> effect of dereferencing the null pointer is undefined.
>>
>>>> A few followups ago I posted the code generated by a GNU C++ compiler
>>>> to show how an array object and a pointer to an array object were
>>>> implemented. I don't know of any compiler that adds an object that
>>>> stores a pointer to the array for each array. I don't know of
>>>> anything in the C++ standard that requires an object that stores
>>>> a pointer to an array for each array. If you do, please provide
>>>> details.
>>> An array object must store a pointer otherwise how does it know, where in
>>> memory, the array is?
>>
> The post you have replied to up till here was not a post by me.
> I believe the following is addressed toward sme.
The post that I replied to, and that is quoted above in the lines
starting with ">>>", was posted by you. If the newsreader you use
has a function to go back to the post that a reply is to, use that
function to go back 3 replys to get to the post in which the lines
above starting with ">>>" were originally written. Otherwise, open
http://groups.google.com/group/comp.lang.c++/msg/c53faaea6144e685?hl=en
>> In a previous post you asked: "So where does the memory address value
>> come from? Its not stored in the array of integer objects." My
>> answer was (see
>> http://groups.google.com/group/comp.lang.c++/msg/90a32f760cdfc958?hl=en)
>>
>> Where the memory address comes from depends on where the
>> implementation decides to store the array. For example, an object
>> with automatic storage duration, such a non-static array declared
>> in a function, is allocated on the stack in an implementation that
>> uses a stack for automatic storage.
>>
>> The compiler knows the compile-time constant offset in the stack
>> frame where it has decided to store the array. In places where a
>> program needs the memory address of the array, the compiler puts
>> in instructions to sum that compile-time constant offset and the
>> current value of the stack pointer.
>>
>> In the last sentence, "stack pointer" should have been "stack
>> frame pointer".
>>
>> For the program
>>
>> void foo() {
>> int arr[4], (*pparr)[4];
>>
>> pparr = &arr;
>> }
>>
>> the assembler output of the GNU C++ compiler for the assignment
>> statement for an i686 system is
>>
>> leal -20(%ebp), %eax
>> movl %eax, -4(%ebp)
>
> This is a very tiny piece of code and the compiler is allowed to optimise
> this .
> Look at some asm code where an array is passed to a function and you will
> see what the value pushed onto the stack is.
> Here is a simple program:
>
> void foo(int* p){ p[0]=7;}
>
> int main(){
> int arr[5]={0};
> foo(arr);
> }
When an array is used as an argument to a function, array-to-pointer
conversion occurs and what is passed is a pointer to the first
element of the array. In what I posted no optimizations were done.
If optimizations had been done, the body of the function foo that I
gave could have been eliminated, including the local variables of
the function.
> And here is the asm output:
>
> ; Listing generated by Microsoft (R) Optimizing Compiler Version
> 14.00.50727.762
>
> TITLE C:\cpp\public.cpp
> .686P
> .XMM
> include listing.inc
> .model flat
>
> INCLUDELIB LIBCMT
> INCLUDELIB OLDNAMES
>
> PUBLIC ?foo@@YAXPAH@Z ; foo
> ; Function compile flags: /Odtp
> _TEXT SEGMENT
> _p$ = 8 ; size = 4
> ?foo@@YAXPAH@Z PROC ; foo
> ; File c:\cpp\public.cpp
> ; Line 3
> push ebp
> mov ebp, esp
> ; Line 4
> mov eax, DWORD PTR _p$[ebp]
> mov DWORD PTR [eax], 7
> ; Line 5
> pop ebp
> ret 0
> ?foo@@YAXPAH@Z ENDP ; foo
> _TEXT ENDS
> PUBLIC _main
> ; Function compile flags: /Odtp
> _TEXT SEGMENT
> /*************************************/
> _arr$ = -20 ; size = 20
>
> /************************************/
> The above line is the array type object.
> This is a pointer in asm because array type objects do not exist in asm.
> /************************************/
The -20 is neither an array type object nor a pointer. It is an
offset in the stack frame where the C++ compiler has allocated the
array object. If you think it is an array type object in which a
pointer to an array is stored, have the C++ program output the
value stored in that array type object and see if the result is -20.
To a C++ compiler arr is an array of 5 int. In the assembler program
generated by the C++ compiler, arr is 20 bytes located at an offset
of -20 in a stack frame. That 20 bytes is the array object; the
type of that object is array of 5 int.
> _main PROC
> ; Line 7
> push ebp
> mov ebp, esp
> sub esp, 20 ; 00000014H
> ; Line 8
> mov DWORD PTR _arr$[ebp], 0
> xor eax, eax
> mov DWORD PTR _arr$[ebp+4], eax
> mov DWORD PTR _arr$[ebp+8], eax
> mov DWORD PTR _arr$[ebp+12], eax
> mov DWORD PTR _arr$[ebp+16], eax
> ; Line 9
> /**************************************/
> lea ecx, DWORD PTR _arr$[ebp]
> push ecx
> /*************************************/
> The above two lines push the address of the arrays first element onto the
> stack prior to invokation of foo.
> /*************************************/
That is exactly what it should happen due to the array-to-pointer
conversion done on the argument expression arr. The lea instruction
adds the offset where arr is in the stack frame to the stack frame
address in register ebp. That sum is placed where the function
being called expects its argument to be. Note that no value stored
in an object was loaded to determine the argument value.
> call ?foo@@YAXPAH@Z ; foo
> add esp, 4
> ; Line 11
> xor eax, eax
> mov esp, ebp
> pop ebp
> ret 0
> _main ENDP
> _TEXT ENDS
> END
>
>
> In the above asm listing arr is _arr$ , that is a pointer object that has
> the value of -20.
_arr$ is a symbolic constant in the assembler source with a value of
-20, like
#define _arr$ -20
would be in C++, if the character $ were allowed in a preprocessor
identifier.
_arr$ is not a pointer object. An object is a region of storage where
the value of the object is stored. The object named arr is the 20
bytes region of storage starting at an offset of -20 in the stack
frame of the function in which arr is declared.
>> The compiler has allocated arr at offset -20 in the stack frame and
>> pparr at offset -4 in the stack frame. The assembler instructions
>> store in pparr the sum of -20 and the stack frame address.
>> Determining the address of arr did not use a value stored in an
>> object.
>>
> You example was so simple that the compiler has optimised the array object
> into a temporary literal (-20).
In my example the compiler did no optimizations. -20 was the offset
in the stack frame where the compiler allocated the array of 4 int
named arr. What is a temporary literal?
Here is an example program where the compiler cannot optimize the
array object, because the compiler does not know what the bar
function does with the pointer to the array.
void bar(int (*)[4]);
int foo() {
int arr[4];
bar(&arr);
}
The generated assembler for the call is
leal -16(%ebp), %eax
movl %eax, (%esp)
call __Z3barPA4_i
Note that no value stored in an object was loaded to determine the
the address of arr, the argument passed to the function bar. There
is no array-type object whose value is the memory address of the
array.
[snip]
> As shown in the asm listing _arr$ is an object with a value of -20. This is
> a pointer object that points to the first element of the array, this object
> stores the address of the array.
What the asm listing shows is that _arr$ is an assembler symbolic
constant with a value -20. _arr$ is not an object. _arr$ is not a
pointer. _arr$ is used to indicate to someone reading the assembler
listing that an operand like
_arr$[ebp]
refers to the variable named arr in the current stack frame. If the
literal offset of -20 were used in the operand instead, it would not
be obvious to someone reading the assembler listing what local
variable the operand corresponds to.
> In C++ this object is not considered a pointer , it is an array type object.
> The C++ standards refers to it as a non modifiable object of array type.
That's right, in C++ an array is not a pointer, although in some
contexts array-to-pointer conversion is done and the result of the
conversion is a pointer to the first element of the array.
What is stored in an array type object is the contents of an array.
An array type object does not store a pointer to an array, unless, of
course, the array contains array pointers, such as an array with the
declarator (*x[5])[3].
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-05-26 21:15 +0100 |
| Message-ID | <zxyDp.16190$ZQ2.10618@newsfe11.ams2> |
| In reply to | #5642 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
news:slrnittb1q.25so.aggedor@earl-grey.cloud9.net...
> On 2011-05-25, Paul <pchristor@yahoo.co.uk> wrote:
>>
>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>> news:slrnitqfvi.10rf.aggedor@earl-grey.cloud9.net...
>>> [snip]
>>>> When you dereference a pointer to int you access the pointed to integer
>>>> object like so :
>>>> int x=5;
>>>> int* px = &x;
>>>> std::cout<< *px;
>>>> //this will output 5 because dereferencing px accesses the object it
>>>> points
>>>> to.
>>>>
>>>>
>>>> With an array the situation is not the same becasue an array cannot be
>>>> accessed, as a whole. The only way we can point to an array is to point
>>>> to
>>>> one of its elements.
>>>> int arr[3] = {1,2,3};
>>>> int* parr = arr;
>>>> int (*pparr)[3] = &arr;
>>>>
>>>> std::cout<< *parr;
>>>> //outputs 1 because it points to the first element of the array.
>>>> std::cout<<*pparr;
>>>> //outputs a memory address because it points to an array-type object.
>>>
>>> The situation with the unary * and unary & operators is the same for
>>> an array and for a non-array. The C++ standard does not specify
>>> different behaviors depending on whether the operand of the unary *
>>> and unary & operators is an array or non-array.
>>>
>>> Here is the paragraph from the C++ standard about the unary *
>>> operator.
>>>
>>> The unary * operator performs indirection: the expression to which
>>> it is applied shall be a pointer to an object type, or a pointer to
>>> a function type and the result is an lvalue referring to the object
>>> or function to which the expression points. If the type of the
>>> expression is "pointer to T", the type of the result is "T".
>>> [Note: a pointer to an incomplete type (other than cv void ) can be
>>> dereferenced. The lvalue thus obtained can be used in limited ways
>>> (to initialize a reference, for example); this lvalue must not be
>>> converted to an rvalue, see 4.1. ]
>>>
>>> The C++ standard does not specify different behaviors for an array
>>> and a non-array with the unary * operator.
>>>
>>> Here is the paragraph from the C++ standard about the unary &
>>> operator.
>>>
>>> The result of the unary & operator is a pointer to its operand.
>>> The operand shall be an lvalue or a qualified-id. In the first
>>> case, if the type of the expression is "T", the type of the result
>>> is "pointer to T". In particular, the address of an object of type
>>> "cv T" is "pointer to cv T", with the same cv-qualifiers. For a
>>> qualified-id, if the member is a static member of type "T", the
>>> type of the result is plain "pointer to T". If the member is
>>> a nonstatic member of class C of type T, the type of the result is
>>> "pointer to member of class C of type T." [Example:
>>>
>>> struct A { int i; };
>>> struct B : A { };
>>> ... &B::i ... // has type int A::*
>>>
>>> --end example] [Note: a pointer to member formed from a mutable
>>> nonstatic data member (7.1.1) does not reflect the mutable
>>> specifier associated with the nonstatic data member. ]
>>>
>>> The C++ standard does not specify different behaviors for an array
>>> and a non-array with the unary & operator.
>>>
>>> A difference with array and non-array results is that
>>> array-to-pointer conversion is applied to an array result.
>>>
>>> In your example, the statement
>>>
>>> int* parr = arr;
>>>
>>> implicitly applies array-to-pointer conversion to the array result of
>>> the expression arr. The result of that conversion is a pointer to
>>> the first element of arr, not a pointer to arr. Because parr is a
>>> pointer to int, the result of dereferencing it is an int.
>>>
>>> In your example, the statement
>>>
>>> int (*pparr)[3] = &arr;
>>>
>>> initializes pparr with a pointer to arr, not a pointer to an element
>>> of arr. Because pparr is a pointer to an array of int, the result of
>>> dereferencing it is an array of int. Array-to-pointer conversion is
>>> implicitly applied to that result and the result of the conversion
>>> is a pointer to int that points to the first element of arr.
>>>
>>>> An array identifier such as 'arr' is an array-type object. A pointer to
>>>> this
>>>> object points to a single object, not to an array of thi sobject type.
>>>
>>> The result of using the identifier 'arr' in an expression is an
>>> array. An array is a single object that contains sub-objects. The
>>> expression &arr points to the object that is the array named arr.
>>>
>>>>> Given the declaration
>>>>>
>>>>> int arr[4];
>>>>>
>>>>> a C++ implementaion creates an array object to represent the array,
>>>>> but it does not also create an object that stores a pointer to the
>>>>> array object, unless one is explicitly present, say due to the
>>>>> declaration
>>>>>
>>>>> int (*pparr)[4] = &arr;
>>>>>
>>>>> Due to that statement a C++ implementation creates a pointer to
>>>>> array object that is initialized to point to the array. The
>>>>> pointer points directly to the array object.
>>>>
>>>> The pointer pparr above points to a single object not an array of
>>>> objects.
>>>> Consider this:
>>>>
>>>> int (*p)[3]=0;
>>>> std::cout<<*p<<std::endl;
>>>> std::cout<< typeid(*p).name()<<std::endl;
>>>> std::cout<< sizeof(*p);
>>>>
>>>> Does the above pointer point to a valid object?
>>>> Or is it completely UB because its dereferencing a null pointer?
>>>
>>> Having the value of a pointer be the null pointer is valid. The
>>> effect of dereferencing the null pointer is undefined.
>>>
>>>>> A few followups ago I posted the code generated by a GNU C++ compiler
>>>>> to show how an array object and a pointer to an array object were
>>>>> implemented. I don't know of any compiler that adds an object that
>>>>> stores a pointer to the array for each array. I don't know of
>>>>> anything in the C++ standard that requires an object that stores
>>>>> a pointer to an array for each array. If you do, please provide
>>>>> details.
>>>> An array object must store a pointer otherwise how does it know, where
>>>> in
>>>> memory, the array is?
>>>
>> The post you have replied to up till here was not a post by me.
>> I believe the following is addressed toward sme.
>
> The post that I replied to, and that is quoted above in the lines
> starting with ">>>", was posted by you. If the newsreader you use
> has a function to go back to the post that a reply is to, use that
> function to go back 3 replys to get to the post in which the lines
> above starting with ">>>" were originally written. Otherwise, open
> http://groups.google.com/group/comp.lang.c++/msg/c53faaea6144e685?hl=en
Ok sorry I lost track of these threads a little bit there.
SO what exactly is your arguemnt about arrays again?
[toc] | [prev] | [next] | [standalone]
Page 14 of 18 — ← Prev page 1 … 12 13 [14] 15 16 … 18 Next page →
Back to top | Article view | comp.lang.c++
csiph-web