Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #2800 > unrolled thread
| Started by | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| First post | 2011-03-29 12:27 -0500 |
| Last post | 2011-04-11 14:27 -0700 |
| Articles | 20 on this page of 404 — 24 participants |
Back to article view | Back to comp.lang.c++
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-03-29 12:27 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-03-30 00:03 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-03-30 12:39 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-03-30 20:42 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-03-31 12:38 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-03-31 19:28 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-01 12:40 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-02 02:33 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-04 12:42 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-04 20:12 +0100
Re: Problem with array objects cg_chas <cg_chas@hotmail.com> - 2011-04-04 16:31 -0400
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-05 12:39 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-05 19:13 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-05 20:16 +0100
Re: Problem with array objects Garrett Hartshaw <ghartshaw@gmail.com> - 2011-04-06 01:36 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-06 10:32 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-06 12:20 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-06 18:42 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-06 14:47 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-06 23:51 +0100
Re: Problem with array objects Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-07 09:44 +0200
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-07 12:28 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-07 21:39 +0100
Re: Problem with array objects cg_chas <cg_chas@hotmail.com> - 2011-04-07 18:16 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-08 01:14 +0100
Re: Problem with array objects cg_chas <cg_chas@hotmail.com> - 2011-04-07 23:03 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-08 08:48 +0100
Re: Problem with array objects cg_chas <cg_chas@hotmail.com> - 2011-04-08 04:15 -0400
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-08 12:39 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-08 21:04 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-09 13:15 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-09 20:32 +0100
Re: Problem with array objects cg_chas <cg_chas@hotmail.com> - 2011-04-09 22:05 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-10 03:44 +0100
Re: Problem with array objects cg_chas <cg_chas@hotmail.com> - 2011-04-09 23:07 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-10 13:32 +0100
Re: Problem with array objects cg_chas <cg_chas@hotmail.com> - 2011-04-10 10:15 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-10 18:29 +0100
Re: Problem with array objects cg_chas <cg_chas@hotmail.com> - 2011-04-10 17:55 -0400
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-11 12:40 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-11 22:07 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-12 12:51 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 19:53 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-13 12:32 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-14 14:02 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-14 12:53 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-14 19:17 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-15 12:25 -0500
Re: Problem with array objects gwowen <gwowen@gmail.com> - 2011-04-15 11:07 -0700
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-16 08:02 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 22:21 +0100
Re: Problem with array objects gwowen <gwowen@gmail.com> - 2011-04-15 14:22 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 23:01 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-16 10:10 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 23:24 +0100
Re: Problem with array objects drew@furrfu.invalid (Drew Lawson) - 2011-04-15 21:48 +0000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 23:16 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 19:05 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-18 12:44 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-18 21:35 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-19 13:46 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-20 17:29 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-23 12:59 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-23 20:31 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-24 09:26 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-24 00:04 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-24 11:24 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-24 02:16 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-24 14:10 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-24 04:37 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-24 16:11 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-24 13:31 +0100
Re: Problem with array objects Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-24 17:57 +0200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-24 17:39 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-25 10:19 +1200
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-25 10:12 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-25 00:46 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-25 11:59 +1200
Re: Problem with array objects "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-04-25 05:01 +0200
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-04-25 14:56 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-25 10:57 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-26 12:36 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-26 22:42 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-27 12:53 -0500
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-04-27 19:06 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-27 20:09 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-04-29 12:57 -0500
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-04-29 19:10 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-04-29 19:56 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-02 13:20 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-02 22:43 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-05 14:13 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-05 22:21 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-06 10:49 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-06 12:29 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-07 11:34 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-08 04:05 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-10 12:31 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-10 22:10 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-12 12:19 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-13 09:54 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-14 11:20 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-14 23:59 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-17 12:59 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-18 19:36 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-19 13:20 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-20 14:29 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-23 13:53 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-23 22:53 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-23 23:04 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-23 23:19 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-24 02:26 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-24 13:16 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-24 14:58 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-24 15:05 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-24 17:39 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-24 17:58 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-24 21:04 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-24 21:11 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 00:12 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-25 00:33 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 11:39 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-25 12:04 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 12:56 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-25 13:15 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 16:36 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-25 16:47 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 17:15 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-25 17:39 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 21:09 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-25 22:24 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 01:28 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-25 09:57 -0400
Re: Problem with array objects "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-05-25 16:50 +0200
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-25 12:01 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 16:59 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-25 12:56 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 21:46 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-25 20:02 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 01:37 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-26 09:08 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 15:19 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-26 14:45 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 21:02 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-27 09:34 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 14:46 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-27 15:07 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 21:42 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-27 19:34 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 01:24 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-28 10:58 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 19:41 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-28 20:38 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-29 12:32 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-29 10:05 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-29 20:13 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-29 19:38 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-30 17:01 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-05-31 09:45 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 20:33 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-06-01 09:57 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 15:53 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 16:46 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 19:44 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 19:59 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 21:41 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 22:10 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:39 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 23:21 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:32 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-06-01 12:33 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 19:18 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 19:38 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 20:10 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 20:18 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:01 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 22:25 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:43 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-06-02 09:49 +1200
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 23:27 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 00:26 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-02 00:33 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 08:52 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-06-01 15:37 -0400
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-06-02 07:46 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 21:22 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-01 10:31 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:10 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-06-02 09:28 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:59 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 15:05 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:35 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-06-02 10:51 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 00:28 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 16:33 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 09:03 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-02 01:23 -0700
Re: Problem with array objects Miles Bader <miles@gnu.org> - 2011-06-02 17:31 +0900
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-02 01:39 -0700
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-01 11:28 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:54 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-01 12:08 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:41 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 14:56 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:17 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:17 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 15:32 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:58 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 16:31 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 08:50 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 21:05 +0100
Re: Problem with array objects Thomas David Rivers <rivers@dignus.com> - 2011-06-01 16:38 -0400
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:20 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 14:42 -0700
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-27 17:44 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 03:11 +0100
Re: Problem with array objects Öö Tiib <ootiib@hot.ee> - 2011-05-28 19:21 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-29 12:50 +0100
Re: Problem with array objects Öö Tiib <ootiib@hot.ee> - 2011-05-29 07:21 -0700
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-29 15:30 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-29 20:43 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-29 21:51 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 03:08 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-05-30 17:39 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 06:05 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-05-31 09:38 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 20:50 +0100
Re: Problem with array objects SG <s.gesemann@gmail.com> - 2011-05-31 02:23 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 13:29 +0100
Re: Problem with array objects "Fred Zwarts \(KVI\)" <F.Zwarts@KVI.nl> - 2011-05-31 15:17 +0200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 20:43 +0100
Re: Problem with array objects Michael Doubez <michael.doubez@free.fr> - 2011-05-31 02:43 -0700
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-31 14:38 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 20:45 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-31 21:11 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 10:23 +0100
Re: Problem with array objects gwowen <gwowen@gmail.com> - 2011-06-01 03:08 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 15:59 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 13:45 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 14:23 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 16:02 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 16:33 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 19:52 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-01 20:02 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-01 09:16 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 21:00 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-01 10:09 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 22:31 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-01 11:58 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:21 +0100
Re: Problem with array objects crisgoogle <crisd@telus.net> - 2011-06-01 16:22 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 00:48 +0100
Re: Problem with array objects crisgoogle <crisd@telus.net> - 2011-06-02 11:06 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 19:58 +0100
Re: Problem with array objects crisgoogle <crisd@telus.net> - 2011-06-02 13:28 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-03 01:16 +0100
Re: Problem with array objects crisgoogle <crisd@telus.net> - 2011-06-02 18:51 -0700
Re: Problem with array objects PaulR <pchristor@yahoo.co.uk> - 2011-06-03 04:59 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 23:21 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-01 14:46 -0700
Re: Problem with array objects Michael Doubez <michael.doubez@free.fr> - 2011-06-01 00:46 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-29 20:29 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-29 23:11 -0700
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-25 08:15 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-24 22:23 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-24 17:01 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 11:48 +0100
Re: Problem with array objects gwowen <gwowen@gmail.com> - 2011-05-25 04:06 -0700
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-25 13:50 -0700
Re: Problem with array objects "io_x" <a@b.c.invalid> - 2011-05-25 19:03 +0200
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-25 12:44 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-25 21:04 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-25 22:20 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 11:00 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-26 12:07 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 13:09 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-26 09:32 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 11:10 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-26 23:07 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 13:22 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-26 14:14 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 15:27 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-26 15:52 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 16:45 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-26 17:04 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 17:41 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-27 07:44 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 21:10 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-27 09:05 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 00:15 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-27 11:32 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 01:39 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 01:56 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-27 13:18 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 11:06 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-27 22:28 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 12:51 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-27 13:58 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 14:34 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-27 15:14 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-27 15:18 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 15:24 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-27 15:31 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 15:53 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-27 16:18 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 20:35 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-27 21:23 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 22:04 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-27 22:15 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 00:40 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 00:53 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 01:32 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 01:49 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-28 13:17 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 03:29 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-28 15:35 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 12:24 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-29 08:21 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 22:04 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-29 09:17 +1200
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-29 09:32 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 22:58 +0100
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-29 10:06 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 23:51 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 03:20 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 12:34 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 12:56 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 13:49 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 14:48 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 15:10 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 19:35 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 19:59 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 20:17 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 20:44 +0100
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-05-28 21:00 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 22:07 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-26 14:38 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-26 21:15 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-27 12:43 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-27 20:20 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-28 11:41 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-28 19:10 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-05-31 12:26 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-31 20:49 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-01 12:46 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-01 20:26 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-02 12:36 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-02 20:23 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-02 10:34 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-03 01:41 +0100
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-02 16:06 -1000
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-02 16:12 -1000
Re: Problem with array objects Pete Becker <pete@versatilecoding.com> - 2011-06-02 16:21 -1000
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-03 14:17 +0100
Re: Problem with array objects hanukas <jukka@liimatta.org> - 2011-06-04 10:34 -0700
Re: Problem with array objects hanukas <jukka@liimatta.org> - 2011-06-04 10:45 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-04 21:02 +0100
Re: Problem with array objects hanukas <jukka@liimatta.org> - 2011-06-04 14:11 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-04 22:35 +0100
Re: Problem with array objects hanukas <jukka@liimatta.org> - 2011-06-04 15:43 -0700
Re: Problem with array objects "io_x" <a@b.c.invalid> - 2011-06-05 06:39 +0200
Re: Problem with array objects "io_x" <a@b.c.invalid> - 2011-06-05 07:55 +0200
Re: Problem with array objects "Alf P. Steinbach /Usenet" <alf.p.steinbach+usenet@gmail.com> - 2011-06-03 11:14 +0200
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-06-03 21:08 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-03 14:25 +0100
Re: Problem with array objects hanukas <jukka@liimatta.org> - 2011-06-04 10:52 -0700
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-04 19:52 -0700
Re: Problem with array objects Leigh Johnston <leigh@i42.co.uk> - 2011-06-05 13:48 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-05 14:52 +0100
Re: Problem with array objects "Thomas J. Gritzan" <phygon_antispam@gmx.de> - 2011-06-05 18:03 +0200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-05 19:23 +0100
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-05 14:49 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-03 12:37 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-03 19:49 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-04 11:46 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-04 18:42 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-06 14:27 -0500
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-06 14:04 -0700
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-06 14:04 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-07 02:26 +0100
Re: Problem with array objects hanukas <jukka@liimatta.org> - 2011-06-06 23:30 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-07 13:13 +0100
Re: Problem with array objects hanukas <jukka@liimatta.org> - 2011-06-08 01:20 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-08 11:39 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-08 17:03 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-08 23:51 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-11 11:41 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-12 00:56 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-14 13:44 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-14 23:01 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-16 13:41 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-16 23:01 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-18 12:23 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-18 19:50 +0100
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-21 13:38 -0500
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-06-22 00:29 +0100
Re: Problem with array objects Keith H Duggar <duggar@alum.mit.edu> - 2011-06-18 12:58 -0700
Re: Problem with array objects "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> - 2011-06-21 13:40 -0500
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-10 15:56 -0700
Re: Problem with array objects Ian Collins <ian-news@hotmail.com> - 2011-05-11 12:25 +1200
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-11 10:56 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-11 14:09 -0700
Re: Problem with array objects "Paul" <pchristor@yahoo.co.uk> - 2011-05-12 13:31 +0100
Re: Problem with array objects Joshua Maurice <joshuamaurice@gmail.com> - 2011-04-11 14:27 -0700
Page 20 of 21 — ← Prev page 1 … 18 19 [20] 21 Next page →
| From | hanukas <jukka@liimatta.org> |
|---|---|
| Date | 2011-06-06 23:30 -0700 |
| Message-ID | <5f147b1f-e60d-46f1-91a3-05ab9542db16@x3g2000yqj.googlegroups.com> |
| In reply to | #6324 |
On Jun 7, 4:26 am, "Paul" <pchris...@yahoo.co.uk> wrote:
> > p1 is a pointer to an integer.
>
> No its a pointer to 7 integers.
Hey, Paul.. pssst.. I have some code for you:
int compute(int *p)
{
// what does "p" point to here?
Tell me ASAP what the "p" points to, please.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-06-07 13:13 +0100 |
| Message-ID | <TBoHp.5561$r52.1410@newsfe02.ams2> |
| In reply to | #6329 |
"hanukas" <jukka@liimatta.org> wrote in message
news:5f147b1f-e60d-46f1-91a3-05ab9542db16@x3g2000yqj.googlegroups.com...
On Jun 7, 4:26 am, "Paul" <pchris...@yahoo.co.uk> wrote:
> > p1 is a pointer to an integer.
>
> No its a pointer to 7 integers.
Hey, Paul.. pssst.. I have some code for you:
int compute(int *p)
{
// what does "p" point to here?
Tell me ASAP what the "p" points to, please.
..................................................................................
I dunno , maybe its a null pointer and points to nothing.
[toc] | [prev] | [next] | [standalone]
| From | hanukas <jukka@liimatta.org> |
|---|---|
| Date | 2011-06-08 01:20 -0700 |
| Message-ID | <cb57ce4a-0728-40e1-8d3a-78dcece5d5dc@j23g2000yqc.googlegroups.com> |
| In reply to | #6348 |
On Jun 7, 3:13 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "hanukas" <ju...@liimatta.org> wrote in message
>
> news:5f147b1f-e60d-46f1-91a3-05ab9542db16@x3g2000yqj.googlegroups.com...
> On Jun 7, 4:26 am, "Paul" <pchris...@yahoo.co.uk> wrote:
>
> > > p1 is a pointer to an integer.
>
> > No its a pointer to 7 integers.
>
> Hey, Paul.. pssst.. I have some code for you:
>
> int compute(int *p)
> {
> // what does "p" point to here?
>
> Tell me ASAP what the "p" points to, please.
> ........................................................................... .......
>
> I dunno , maybe its a null pointer and points to nothing.
Wrong! It points to array of herring. xD
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-06-08 11:39 +0100 |
| Message-ID | <8kIHp.2191$b91.1737@newsfe19.ams2> |
| In reply to | #6400 |
"hanukas" <jukka@liimatta.org> wrote in message
news:cb57ce4a-0728-40e1-8d3a-78dcece5d5dc@j23g2000yqc.googlegroups.com...
On Jun 7, 3:13 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "hanukas" <ju...@liimatta.org> wrote in message
>
> news:5f147b1f-e60d-46f1-91a3-05ab9542db16@x3g2000yqj.googlegroups.com...
> On Jun 7, 4:26 am, "Paul" <pchris...@yahoo.co.uk> wrote:
>
> > > p1 is a pointer to an integer.
>
> > No its a pointer to 7 integers.
>
> Hey, Paul.. pssst.. I have some code for you:
>
> int compute(int *p)
> {
> // what does "p" point to here?
>
> Tell me ASAP what the "p" points to, please.
> ...........................................................................
> .......
>
> I dunno , maybe its a null pointer and points to nothing.
Wrong! It points to array of herring. xD
No that would be a :
><{{{°>
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-06-08 17:03 -0500 |
| Message-ID | <slrniuvscs.2fsr.aggedor@earl-grey.cloud9.net> |
| In reply to | #6324 |
On 2011-06-07, Paul <pchristor@yahoo.co.uk> wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrniuqah1.16ra.aggedor@earl-grey.cloud9.net...
>> On 2011-06-04, Paul <pchristor@yahoo.co.uk> wrote:
>>>
>>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>>> news:slrniukoa8.1fj5.aggedor@earl-grey.cloud9.net...
>>>> On 2011-06-03, Paul <pchristor@yahoo.co.uk> wrote:
>>
>> [snip]
>>
>>>> The C++ sees it as: "An object of array type contains a
>>>> contiguously allocated nonempty set of N sub-objects of type T."
>>>> Pointing to an array is pointing to an object of array type.
>>>> Pointing to a sub-object in an array is pointing to something other
>>>> than an object of the array type of the array that the sub-object is
>>>> in.
>>>>
>>> You have quoted some text from that seems to describe an object of array
>>> type.
>>> As I said , and you have proved me correct, you can only see an array as
>>> "a
>>> single array type object". You cannot see it at as array of integer
>>> objects( or whatever type it is).
>>
>> I have quoted the C++ standard. Seeing it as the C++ standard does
>> is the proper way to see it when discussing C++, such as in the
>> comp.lang.c++ newsgroup. Seeing it another way is seeing it in a
>> way different from the C++ standard.
>
> This is not a definition of the term "array", this piece of text you have
> quoted is not the C++ std's way of saying an array is definitely not an
> sequence of objects, this is saying and array TYPE object is ....and it
> doesn't mean this is the only possible way to consider an array.
Because an array is an object of array type, and not of any other
type, what the C++ standard states about an object of array type is
about an array.
What I quoted says that an array is a sequence of objects. The
phrase used in the standard is "a contiguously allocated set of
sub-objects". Here is part of a standard definition of the word
contiguous (the word from which the adverb contituously is derived):
"next or together in sequence" (from
http://oxforddictionaries.com/definition/contiguous). The
sub-objects an (object of type) array contains are together in a
sequence.
The C++ standard considers an array to be a sequence of sub-objects.
That is what an array should be considered to be when discussing C++.
>>>>> With the following code..
>>>>> int arr[7];
>>>>> int* p1 = arr;
>>>>> int (*p2)[7] = &arr;
>>>>>
>>>>> Both the pointers point-to the first element in the array, and both
>>>>> pointers
>>>>> also point-to the array of integer objects. They are just different
>>>>> types
>>>>> of
>>>>> pointers.
>>>>> They both point to exactly the same location.
>>>>
>>>> Both pointers do not point to the first element of the array. p1
>>>> points to the first element of the array; p2 points to the array.
>>>> An array is not the same as its first element.
>>> The address of an array is the same as the address of the first element,
>>> and
>>> a pointer is this address.
>>
>> The first element of an array is at the same memory location as the
>> array. The value of a C++ pointer is not only a memory location; it
>> is a typed memory location.
> Rubbish the value of a pointer object does not contain any typeinfo. Its a
> simple integer value that represents the address of the pointed to object.
The typeinfo is associated with the type of the pointer. In C++ a
pointer is not a simple integer value; it a typed value.
[Continuing with what I wrote in a single paragraph that you split.]
>> Ignoring their types, the p1 and p2 have
>> the same value; however because p1 and p2 have different types, they
>> do not point to the same entity. p1 points to the first element of
>> the array, not to the array; p2 points to the array.
>
> They point to exactly the same location.
> The type of a pointer does not define what is pointed to.
In C++ the type of the pointer determines the type of the result of
dereferencing the pointer. Here, again, is what the C++ standard
states about the unary * operator: "If the type of the expression is
pointer to T, the type of the result is T."
If the type of the expression is a pointer is to an array of T, the
result of dereferencing its is type array of T. An attempt to access
the result of dereferencing a pointer to array of T when the value of
the pointer is not the address of an array of T object is undefined
behavior (see paragraph 15 of 3.10 (Lvalues and rvalues) of the C++
standard).
These posts are long enough without having to mention undefined
behavior when a value is not valid.
>>> They both point to exactly the same place and they both point to exactly
>>> the
>>> same array. Whether you view it as pointing to an array of pointing to
>>> the
>>> first element is just a POV.
>>
>> They do not both point to exactly the same array. One points to an
>> array; the other may point to an element of that array. The point of
>> view of the C++ standard is that a
>>
>> int (*)[]
>>
>> points to an array of int while a
>>
>> int *
>>
>> points to an int, the int it points to may be an element in an array
>> of int.
>>
> This is completely made up. Where does the standard define that a pointer
> type defines what is pointed to?
> In fact where does the C++ standard define the term "points to"? It doesn't.
One place the C++ standard uses the term "points to" is paragraph 2 of
4.10 (Pointer conversions):
An rvalue of type "pointer to cv T," where T is an object type, can
be converted to an rvalue of type "pointer to cv void." The result
of converting a "pointer to cv T" to a "pointer to cv void" points
to the start of the storage location where the object of type T
resides, as if the object is a most derived object (1.8) of type T
(that is, not a base class subobject)."
"Points to" the start of a storage location is what a value of a
pointer type does. A pointer to int points to an int, accessing what
it points to when its value is not the address of an int is undefined
behavior (see paragraph 15 of 3.10 (Lvalues and rvalues) of the C++
standard.)
[snip]
>> The declarations were
>>
>> int arr[7];
>> int* p1 = arr;
>> int (*p2)[7] = &arr;
>>
>> p1 is a pointer to an integer.
> No its a pointer to 7 integers.
The type of p1 is int*; it is a pointer to int. The values of p1 and
p2 are the same storage location. Because p1 and p2 havd different
types, they point to different entties. p1 to and int and p2 to an
array of 7 int.
Saying that a pointer is to whatever is at the storage starting at
the value of the pointer ignores the fact that C++ pointer are typed.
Ignoring the pointer type would mean that for the declaration
int arr[3][5], *p;
setting the value of p to the address of the first integer in the
2-dimensional array would mean that p is a pointer to 1, 5, and 15
integers at the same time. It is a pointer to 15 integers because
15 were allocated starting at the storage location that p has as
its value. It is a pointer to 5 integers because the first of 3
arrays of 5 integers were allocated starting at the same storage
location. It is a pointer to 1 integer because the first integer
in the first of 3 arrays of 5 integers were allocated starting at
the same storage location.
For the declaration
int arr[3][5][7][9][11], *p;
setting the value of p to the address of the first integer in the
5-dimensional array would mean that p is a pointer to 1, 11, 99,
693, 3465, and 10395 integers at the same time.
A pointer to a member of a POD (plain old data) struct is a similar
situation. Ignoring its type, with
struct s_t {
int a, b, c, d, e;
} s;
int* pi = &s.a;
pi points to 5 integers.
With
struct s_t {
int a, b;
double c, d
long e;
} s;
int* pi = &s.a;
pi points to 2 integers, 2 doubles, and a long. What versitility
an int* has in a view that ignores the pointer type!
Because pointers are typed in C++, an int* points to an int. Just
because a pointer to int is treated as if it is to an element of an
array of int when an integral value is added to the pointer does not
mean that it does not point to an int.
This is similar to just because array-to-pointer conversion is
implicitly done in some contexts that an array is the same as a
pointer.
>> What C++ has available as a pointer to
>> multiple integers is a pointer to an array of integers, such as p2.
>> p1 is a pointer to an integer, accessing what p1 points to access
>> that integer.
>
> Accessing what p2 points to also accesses the same integer.
> They are just different types of pointer but they both point to exactly the
> same thing.
p1 and p2 do not point to the same thing. p1 points to an int, p2
points to an array of int. If p1 an p2 pointed to the same thing,
it would not be necessary to dereference p2 twice to get the same
int that is gotten by dereferencing p1 once.
[snip]
>> An element in an array has a different type than the array the
>> element is in. The type of p1 is int*. When p1 points to an element
>> of an array of int, it is pointing to an an int, not to an array.
>> The type of a pointer to an array of int is of the form int(*)[].
>> The C++ standard is clear about this in the following example from
>> 8.1 (Types).
>>
>> int // int i
>> int * // int *pi
>> int *[3] // int *p[3]
>> int (*)[3] // int (*p3i)[3]
>> int *() // int *f()
>> int (*)(double) // int (*pf)(double)
>>
>> name respectively the types "int," "pointer to int," "array of 3
>> pointers to int," "pointer to array of 3 int," "function of (no
>> parameters) returning pointer to int," and "pointer to a function
>> of (double) returning int.
>
> That is the TYPE of pointer, nobody is disputing the pointer TYPE. But a
> pointer TYPE does not define what is pointed to by that pointer.
Writing, as you did above that "No its a pointer to 7 integers." as a
response to "p1 is a pointer to an integer.", where p1 is to type
int*, is disputing that in C++ the result of dereferencing a pointer to
T is a T, as opposed to many Ts. A pointer type defines what may be
validly pointed to. Dereferencing a pointer to T whose value is not
an address of T is undefined behavior.
> A pointers' type simply tells us that that pointer is capable of addressing
> objects of the given type.
> For example:
> char* cp;
> This pointer is capable of addressing char objects, it doesn't point to a
> char object.
The value cp may validly be the address of a char object, the address
of a char object +1, or NULL. Dereferencing cp when its value is not
the address of a char object is undefined behavior. These posts are
long enough without having to mention undefined behavior when a value
is not valid.
>> The distinction between a pointer to an array and a pointer to an
>> element of that array is important for multidimensional arrays as
>> arrays of arrays in C++. The declaration
>>
>> int x[3][5];
>>
>> declares an array of 3 array of 5 int. The expression x[i][j] is
>> equivalent to *(*(x+i)+j). When that expression is evaluated
>
> This is not what the Std says. The standard says that each subsctipt will be
> calucalated individually.
> i has a multiplier of 5xsizeof(int), j has the multiplier of 1xsizeof(int).
Where is what follows are the subscripts not calculated individually?
>>
>> - x is an array of 3 array of 5 int
>> - array-to-pointer conversion results in a pointer to the first array
>> of 5 int in x
>> - adding i results in a pointer to the i-th array of 5 int in x
>> - dereferencing that results in the i-th array of 5 int in x
>> - array-to-pointer conversion results in a pointer to the first int in
>> the i-th array of 5 int in x
>> - adding j results in a pointer to the j-th int in the i-th array of
>> 5 int in x
>> - dereferencing that result in the j-th int in the i-th array of 5 int
>> in x
>>
>> Multidimensional arrays in C++ depend on the distinction between a
>> pointer to an array and a pointer to an element of that array. Not
>> understanding this distinction may lead to confusion.
>>
>>>> Unlike p1, p2 is a pointer to an array type object. p2 points to an
>>>> array. p1 does not point to an array; it points to the first
>>>> element of the array that p2 points to.
>>>
>>> p1 and p2 point to exactly the same place, and the same array.
>>
>> p1 and p2 have different types. p1 points to an int, not to an
>> array. p2 points to an array of 7 int.
>
> They have different types, but they both point to the same location.
In C++ pointers are typed; they are not only a storage location value.
The type of the pointer determines type used when accessing what the
pointer points to.
>>>>> Consider a stack frame pointer, pointing to the stack. It doesn't
>>>>> actually
>>>>> point the whole stack at the same time but nonetheless its still
>>>>> considered
>>>>> to be pointing to the stack.
>>>>
>>>> There is a significant difference between a stack frame pointer and a
>>>> C++ pointer: a C++ pointer is typed. In C++, the result of
>>>> dereferencing a pointer to T, where T is a type, is a T.
>>>
>>> No, dereferencing a pointer of type pointer-to-T, will result in a T if
>>> it
>>> points to a valid T object.
>>> The pointer type declares a pointer object that can address an object of
>>> the
>>> decalred type , for example:
>>> int *p = 0;
>>> p = &ix; /*assume x is valid int*/
>>> p = new int[64];
>>
>> What I have written is about what a C++ compiler does, along the
>> lines of what the C++ standard does in the folliwng sentence about
>> the unary * operator: "If the type of the expression is pointer to T,
>> the type of the result is T." These post are long enough without
>> adding possible undefined behaviors when the program runs due to the
>> value of a pointer to a non-polymorphic type.
>
> This is explaining just what I said, if the type of the pointer is T then
> derefernecing it addresses a T.
> Assuming it points to a valid T type object.
> This is not defining what p points to. p points to a location and whatever
> is stored there is what is pointed to.
Whatever is at the storage location that is the value of a pointer to
T is treated as being of type T. The type of the pointer defines how
what is pointed to is treated. If what is at the storage location is
not an object of the appropriate type, the behavior is undefined.
These posts are long enough without having to mention undefined
behavior when a value is not valid.
>>> Here the pointer p is declared to be a pointer of type ptr-to-int, it
>>> means
>>> this pointer must be capable of pointing to a valid int object., It has
>>> nothing to do with what it points to.
>>> The above the pointer is shown pointing to nothing, an integer and an
>>> array
>>> of integers.
>>
>> What is shown is p having the null pointer value, pointing to an
>> integer, and pointing to the first integer in an array of integers
>> (the result of the expression (new int[64]) is a pointer to int,
>> not a pointer to array of int).
>
> No what is returned from the new expression is a pointer to the first
> element *of an array* of integers.
> When the pointer is used as a pointer to the array like so:
> p[3];
> The expression is evaluated as:
> *(p+ 3xsizeof(int))
> Where p is a pointer to the beginning of the array , and the offset to the
> individual element is added.
The pointer to the first element of the array is a pointer to int (type
int*). The expression
(p + 3xsizeof(int))
is a pointer to the 3xsizeof(int) element relative to the array element
that p is treated as pointing to. If p points to the first element of
and array and sizeof(int) is 4, then
(p + 3xsizeof(int))
points to the 13th element of the array (first plus 12).
Pointers in C++ are typed. The storage location that is pointed to
when adding a pointer and an integral value depends on the pointer
type.
> This pointer is used as a pointer to the array, not to only just one
> element. And it can be used as a pointer to the array because it points to
> an array.
In the example, the pointer is not used as a pointer to an array of
int. p is a pointer to int. It may point to an element in an array
of int. A pointer to an element in an array of int is not same as a
pointer to the array. The former is of type int*; the latter is of
type like int(*)[64]. If p could be used as a pointer to an array (of
64 int), the following would be allowed, but it isn't.
int (*parr)[64] = p;
> Yes its TYPE is int*, but this does not mean it can only point to one single
> integer. Its type does not define what it points to.
The type of a pointer defines what may be validly pointed to. An int*
may validly point to one single integer.
>>> Now consider the following code:
>>> int *p;
>>> What does this point to? Uninitialised memory that could contain
>>> anything.
>>> The pointer type only tells us that the declared pointer object is
>>> capable
>>> of pointing to an integer, it does not define what is pointed to, as you
>>> have tried to imply.
>>
>> It is undefined what p points to. I have used shorter phrases, such
>> as "is a T", rather than a longer ones, such as "is of type T". You
>> are misreading "is a T" as "is an object of type T that exists when
>> the program runs".
>
> Well you have said that, becuase it is of type int*, it can only point to an
> int.
> Now you are saying it is undefined what it points to.
> I repeat..the pointer type does not define what is pointed to.
I can repeat, too. As I wrote above, where cp is of type char*
The value cp may validly be the address of a char object, the address
of a char object +1, or NULL. Dereferencing cp when its value is not
the address of a char object is undefined behavior. These posts are
long enough without have to mention undefined behavior when a value
is not valid.
> You are shortening the term a "pointer type ptr-to-T" to mean the same as a
> "pointer to T". But the two terms do not mean the same thing.
> One term is specifically describing the pointer type. The other is referring
> to whatever is at the location pointed to.
I have not used the term "ptr-to-T". Where is it in the C++ standard?
The value of a pointer to T, where T is a non-polymorphic type, may
validly be the address of an object of type T, the address of an object
of type T +1, or NULL. Dereferencing a pointer to T when its value
is not the address of an object of type T is undefined behavior. These
posts are long enough without having to mention undefined behavior when
a value is not valid.
>>>> The result of using a stack frame pointer as an address operand
>>>> depends on what the operator does. Different operators move 1, 2, 4,
>>>> 8, or some other number of bytes to or from storage starting at the
>>>> address given by the address operand.
>>>
>>> What you seem to be talking about here is what I know as the PTR keyword
>>> in
>>> assembly, it may change in different assemblers.
>>> I don't really see what this has to do with the fundamental concept that
>>> a
>>> SFP "points to" a stack frame.
>>
>> In that case, you don't really see the difference between a value
>> with the correct number of bits to be used as an address in assembler
>> and a C++ pointer. C++ pointers are typed.
>
> The term "pointer" is not redefined because C++ pointers are typed.
>
> A pointer is defined in the C standard and C++ inherits this defintion. A
> pointer of type char* can point to a single char, and array of chars or
> nothing at all. This is the view of the C standard and also Bjarne
> Stroustrup in one of his C++ books.
When I run a C compiler on the statement that tries to set a char*
to point to an array of char, that is, set the value of a pointer
to char to the address of an array of char, as in
char arr[4], *pc = &arr;
I get a diagnostic message. Setting a char* to point to an element
in an array of char, that is, set the value of a pointer to char to
the address of an element of an array of char, as in
char arr[4], *pc = &arr[0];
is allowed.
In a previous post you partially quoted a glossary entry for char*
by Bjarne Stroustrup. What you quoted omitted: "Typically assumed
to point to a C-style string. Prefer a standard library string over
a C-style string when you can. TC++PL 2.3.3, 13.5.2."
The context of the glossary entry is C-style strings. The glossary
did not contain similar entries for other specific types, such as
int*, or an entry for T* that states a T* is a pointer to a T or to
an array of T.
Allowing
char v[] = "Annemarie";
is a special case for arrays of char and C-style strings.
When writing at a detailed level, Bjarne Stroustrup is careful
about the details, as in the following from an example on page
91 of the Special Edition of "The C++ Programming Language".
int v[] = { 1, 2, 3, 4 };
int* p1 = v; // pointer to initial element (implicit conversion)
Note that p1 is a pointer to the initial element, not a pointer to
the array.
In an eariler edition of the same book he wrote (page 53 of the
second edition):
Pointers to arrays and pointers to functions unfortunately need a
more complicated notation.
int* pi;
char** cpp; // pointer to pointer to char
int (*vp)[10]; // pointer to array of 10 ints
int (*fp)(char, char*); // pointer to function
// taking (char, char*) arguments
// and returning int
An int(*)[] points to an array of int; a int* does not, but it may
point to an element in an array of int.
> With an array like so:
> [int][int][int][int][int][int][int][int]
> If a pointer 'p' points to the beinning of this array then the expression:
> p+1;
> points to the second element.
> p+2;
> points to the third element, and so on.
>
> The pointer 'p' points to an array of integers, not only one single integer.
> The TYPE of 'p' can only be int*, because if it were of type int (*)[8] then
> p+2 would point away past the array.
The pointer p points to an int. It is the semantics of the binary +
operator that p+i points to the i-th element of an array when p
points to the first element of the array. Those semantics also treat
an int(*)[8] as pointing to an element in an int[][8] array when an
integral value is added to an int(*)[8].
> The pointer 'p' is used as a pointer to an array of integers, it could not
> be used as a pointer to an array if it only pointed to one single object.
> It is a different concept from pointing to one single array type object.
The pointer p cannot be used as a pointer to an array of integers. If
it could, the last initialization in the following declaration would be
allowed, but it isn't.
int arr[4], (*parr)[4] = &arr, *p = parr;
The pointer p points to a single int type object. It may point to an
element in an array of int. In which case, it is pointing to a single
int in that array.
When p is pointing to a single int in an array, it due to the
semantics of adding a pointer and an integral value that (p+1) points
to the next element in the array. Pointing to an element in an array
is a different concept than pointing to an array.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-06-08 23:51 +0100 |
| Message-ID | <i2THp.9391$w86.4662@newsfe22.ams2> |
| In reply to | #6448 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
news:slrniuvscs.2fsr.aggedor@earl-grey.cloud9.net...
> On 2011-06-07, Paul <pchristor@yahoo.co.uk> wrote:
>>
>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>> news:slrniuqah1.16ra.aggedor@earl-grey.cloud9.net...
>>> On 2011-06-04, Paul <pchristor@yahoo.co.uk> wrote:
>>>>
>>>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>>>> news:slrniukoa8.1fj5.aggedor@earl-grey.cloud9.net...
>>>>> On 2011-06-03, Paul <pchristor@yahoo.co.uk> wrote:
>>>
>>> [snip]
>>>
>>>>> The C++ sees it as: "An object of array type contains a
>>>>> contiguously allocated nonempty set of N sub-objects of type T."
>>>>> Pointing to an array is pointing to an object of array type.
>>>>> Pointing to a sub-object in an array is pointing to something other
>>>>> than an object of the array type of the array that the sub-object is
>>>>> in.
>>>>>
>>>> You have quoted some text from that seems to describe an object of
>>>> array
>>>> type.
>>>> As I said , and you have proved me correct, you can only see an array
>>>> as
>>>> "a
>>>> single array type object". You cannot see it at as array of integer
>>>> objects( or whatever type it is).
>>>
>>> I have quoted the C++ standard. Seeing it as the C++ standard does
>>> is the proper way to see it when discussing C++, such as in the
>>> comp.lang.c++ newsgroup. Seeing it another way is seeing it in a
>>> way different from the C++ standard.
>>
>> This is not a definition of the term "array", this piece of text you have
>> quoted is not the C++ std's way of saying an array is definitely not an
>> sequence of objects, this is saying and array TYPE object is ....and it
>> doesn't mean this is the only possible way to consider an array.
>
> Because an array is an object of array type, and not of any other
> type, what the C++ standard states about an object of array type is
> about an array.
>
> What I quoted says that an array is a sequence of objects. The
> phrase used in the standard is "a contiguously allocated set of
> sub-objects". Here is part of a standard definition of the word
> contiguous (the word from which the adverb contituously is derived):
> "next or together in sequence" (from
> http://oxforddictionaries.com/definition/contiguous). The
> sub-objects an (object of type) array contains are together in a
> sequence.
>
> The C++ standard considers an array to be a sequence of sub-objects.
> That is what an array should be considered to be when discussing C++.
>
>>>>>> With the following code..
>>>>>> int arr[7];
>>>>>> int* p1 = arr;
>>>>>> int (*p2)[7] = &arr;
>>>>>>
>>>>>> Both the pointers point-to the first element in the array, and both
>>>>>> pointers
>>>>>> also point-to the array of integer objects. They are just different
>>>>>> types
>>>>>> of
>>>>>> pointers.
>>>>>> They both point to exactly the same location.
>>>>>
>>>>> Both pointers do not point to the first element of the array. p1
>>>>> points to the first element of the array; p2 points to the array.
>>>>> An array is not the same as its first element.
>>>> The address of an array is the same as the address of the first
>>>> element,
>>>> and
>>>> a pointer is this address.
>>>
>>> The first element of an array is at the same memory location as the
>>> array. The value of a C++ pointer is not only a memory location; it
>>> is a typed memory location.
>> Rubbish the value of a pointer object does not contain any typeinfo. Its
>> a
>> simple integer value that represents the address of the pointed to
>> object.
>
> The typeinfo is associated with the type of the pointer. In C++ a
> pointer is not a simple integer value; it a typed value.
>
> [Continuing with what I wrote in a single paragraph that you split.]
>
>>> Ignoring their types, the p1 and p2 have
>>> the same value; however because p1 and p2 have different types, they
>>> do not point to the same entity. p1 points to the first element of
>>> the array, not to the array; p2 points to the array.
>>
>> They point to exactly the same location.
>> The type of a pointer does not define what is pointed to.
>
> In C++ the type of the pointer determines the type of the result of
> dereferencing the pointer. Here, again, is what the C++ standard
> states about the unary * operator: "If the type of the expression is
> pointer to T, the type of the result is T."
>
> If the type of the expression is a pointer is to an array of T, the
> result of dereferencing its is type array of T. An attempt to access
> the result of dereferencing a pointer to array of T when the value of
> the pointer is not the address of an array of T object is undefined
> behavior (see paragraph 15 of 3.10 (Lvalues and rvalues) of the C++
> standard).
>
> These posts are long enough without having to mention undefined
> behavior when a value is not valid.
>
>>>> They both point to exactly the same place and they both point to
>>>> exactly
>>>> the
>>>> same array. Whether you view it as pointing to an array of pointing to
>>>> the
>>>> first element is just a POV.
>>>
>>> They do not both point to exactly the same array. One points to an
>>> array; the other may point to an element of that array. The point of
>>> view of the C++ standard is that a
>>>
>>> int (*)[]
>>>
>>> points to an array of int while a
>>>
>>> int *
>>>
>>> points to an int, the int it points to may be an element in an array
>>> of int.
>>>
>> This is completely made up. Where does the standard define that a pointer
>> type defines what is pointed to?
>> In fact where does the C++ standard define the term "points to"? It
>> doesn't.
>
> One place the C++ standard uses the term "points to" is paragraph 2 of
> 4.10 (Pointer conversions):
>
> An rvalue of type "pointer to cv T," where T is an object type, can
> be converted to an rvalue of type "pointer to cv void." The result
> of converting a "pointer to cv T" to a "pointer to cv void" points
> to the start of the storage location where the object of type T
> resides, as if the object is a most derived object (1.8) of type T
> (that is, not a base class subobject)."
>
> "Points to" the start of a storage location is what a value of a
> pointer type does. A pointer to int points to an int, accessing what
> it points to when its value is not the address of an int is undefined
> behavior (see paragraph 15 of 3.10 (Lvalues and rvalues) of the C++
> standard.)
>
> [snip]
>
>>> The declarations were
>>>
>>> int arr[7];
>>> int* p1 = arr;
>>> int (*p2)[7] = &arr;
>>>
>>> p1 is a pointer to an integer.
>> No its a pointer to 7 integers.
>
> The type of p1 is int*; it is a pointer to int. The values of p1 and
> p2 are the same storage location. Because p1 and p2 havd different
> types, they point to different entties. p1 to and int and p2 to an
> array of 7 int.
>
> Saying that a pointer is to whatever is at the storage starting at
> the value of the pointer ignores the fact that C++ pointer are typed.
> Ignoring the pointer type would mean that for the declaration
>
> int arr[3][5], *p;
>
> setting the value of p to the address of the first integer in the
> 2-dimensional array would mean that p is a pointer to 1, 5, and 15
> integers at the same time. It is a pointer to 15 integers because
> 15 were allocated starting at the storage location that p has as
> its value. It is a pointer to 5 integers because the first of 3
> arrays of 5 integers were allocated starting at the same storage
> location. It is a pointer to 1 integer because the first integer
> in the first of 3 arrays of 5 integers were allocated starting at
> the same storage location.
>
> For the declaration
>
> int arr[3][5][7][9][11], *p;
>
> setting the value of p to the address of the first integer in the
> 5-dimensional array would mean that p is a pointer to 1, 11, 99,
> 693, 3465, and 10395 integers at the same time.
>
> A pointer to a member of a POD (plain old data) struct is a similar
> situation. Ignoring its type, with
>
> struct s_t {
> int a, b, c, d, e;
> } s;
> int* pi = &s.a;
>
> pi points to 5 integers.
>
> With
>
> struct s_t {
> int a, b;
> double c, d
> long e;
> } s;
> int* pi = &s.a;
>
> pi points to 2 integers, 2 doubles, and a long. What versitility
> an int* has in a view that ignores the pointer type!
>
> Because pointers are typed in C++, an int* points to an int. Just
> because a pointer to int is treated as if it is to an element of an
> array of int when an integral value is added to the pointer does not
> mean that it does not point to an int.
>
> This is similar to just because array-to-pointer conversion is
> implicitly done in some contexts that an array is the same as a
> pointer.
>
>>> What C++ has available as a pointer to
>>> multiple integers is a pointer to an array of integers, such as p2.
>>> p1 is a pointer to an integer, accessing what p1 points to access
>>> that integer.
>>
>> Accessing what p2 points to also accesses the same integer.
>> They are just different types of pointer but they both point to exactly
>> the
>> same thing.
>
> p1 and p2 do not point to the same thing. p1 points to an int, p2
> points to an array of int. If p1 an p2 pointed to the same thing,
> it would not be necessary to dereference p2 twice to get the same
> int that is gotten by dereferencing p1 once.
>
> [snip]
>
>>> An element in an array has a different type than the array the
>>> element is in. The type of p1 is int*. When p1 points to an element
>>> of an array of int, it is pointing to an an int, not to an array.
>>> The type of a pointer to an array of int is of the form int(*)[].
>>> The C++ standard is clear about this in the following example from
>>> 8.1 (Types).
>>>
>>> int // int i
>>> int * // int *pi
>>> int *[3] // int *p[3]
>>> int (*)[3] // int (*p3i)[3]
>>> int *() // int *f()
>>> int (*)(double) // int (*pf)(double)
>>>
>>> name respectively the types "int," "pointer to int," "array of 3
>>> pointers to int," "pointer to array of 3 int," "function of (no
>>> parameters) returning pointer to int," and "pointer to a function
>>> of (double) returning int.
>>
>> That is the TYPE of pointer, nobody is disputing the pointer TYPE. But a
>> pointer TYPE does not define what is pointed to by that pointer.
>
> Writing, as you did above that "No its a pointer to 7 integers." as a
> response to "p1 is a pointer to an integer.", where p1 is to type
> int*, is disputing that in C++ the result of dereferencing a pointer to
> T is a T, as opposed to many Ts. A pointer type defines what may be
> validly pointed to. Dereferencing a pointer to T whose value is not
> an address of T is undefined behavior.
>
>> A pointers' type simply tells us that that pointer is capable of
>> addressing
>> objects of the given type.
>> For example:
>> char* cp;
>> This pointer is capable of addressing char objects, it doesn't point to a
>> char object.
>
> The value cp may validly be the address of a char object, the address
> of a char object +1, or NULL. Dereferencing cp when its value is not
> the address of a char object is undefined behavior. These posts are
> long enough without having to mention undefined behavior when a value
> is not valid.
>
>>> The distinction between a pointer to an array and a pointer to an
>>> element of that array is important for multidimensional arrays as
>>> arrays of arrays in C++. The declaration
>>>
>>> int x[3][5];
>>>
>>> declares an array of 3 array of 5 int. The expression x[i][j] is
>>> equivalent to *(*(x+i)+j). When that expression is evaluated
>>
>> This is not what the Std says. The standard says that each subsctipt will
>> be
>> calucalated individually.
>> i has a multiplier of 5xsizeof(int), j has the multiplier of
>> 1xsizeof(int).
>
> Where is what follows are the subscripts not calculated individually?
>
>>>
>>> - x is an array of 3 array of 5 int
>>> - array-to-pointer conversion results in a pointer to the first array
>>> of 5 int in x
>>> - adding i results in a pointer to the i-th array of 5 int in x
>>> - dereferencing that results in the i-th array of 5 int in x
>>> - array-to-pointer conversion results in a pointer to the first int in
>>> the i-th array of 5 int in x
>>> - adding j results in a pointer to the j-th int in the i-th array of
>>> 5 int in x
>>> - dereferencing that result in the j-th int in the i-th array of 5 int
>>> in x
>>>
>>> Multidimensional arrays in C++ depend on the distinction between a
>>> pointer to an array and a pointer to an element of that array. Not
>>> understanding this distinction may lead to confusion.
>>>
>>>>> Unlike p1, p2 is a pointer to an array type object. p2 points to an
>>>>> array. p1 does not point to an array; it points to the first
>>>>> element of the array that p2 points to.
>>>>
>>>> p1 and p2 point to exactly the same place, and the same array.
>>>
>>> p1 and p2 have different types. p1 points to an int, not to an
>>> array. p2 points to an array of 7 int.
>>
>> They have different types, but they both point to the same location.
>
> In C++ pointers are typed; they are not only a storage location value.
> The type of the pointer determines type used when accessing what the
> pointer points to.
>
>>>>>> Consider a stack frame pointer, pointing to the stack. It doesn't
>>>>>> actually
>>>>>> point the whole stack at the same time but nonetheless its still
>>>>>> considered
>>>>>> to be pointing to the stack.
>>>>>
>>>>> There is a significant difference between a stack frame pointer and a
>>>>> C++ pointer: a C++ pointer is typed. In C++, the result of
>>>>> dereferencing a pointer to T, where T is a type, is a T.
>>>>
>>>> No, dereferencing a pointer of type pointer-to-T, will result in a T
>>>> if
>>>> it
>>>> points to a valid T object.
>>>> The pointer type declares a pointer object that can address an object
>>>> of
>>>> the
>>>> decalred type , for example:
>>>> int *p = 0;
>>>> p = &ix; /*assume x is valid int*/
>>>> p = new int[64];
>>>
>>> What I have written is about what a C++ compiler does, along the
>>> lines of what the C++ standard does in the folliwng sentence about
>>> the unary * operator: "If the type of the expression is pointer to T,
>>> the type of the result is T." These post are long enough without
>>> adding possible undefined behaviors when the program runs due to the
>>> value of a pointer to a non-polymorphic type.
>>
>> This is explaining just what I said, if the type of the pointer is T then
>> derefernecing it addresses a T.
>> Assuming it points to a valid T type object.
>> This is not defining what p points to. p points to a location and
>> whatever
>> is stored there is what is pointed to.
>
> Whatever is at the storage location that is the value of a pointer to
> T is treated as being of type T. The type of the pointer defines how
> what is pointed to is treated. If what is at the storage location is
> not an object of the appropriate type, the behavior is undefined.
> These posts are long enough without having to mention undefined
> behavior when a value is not valid.
>
>>>> Here the pointer p is declared to be a pointer of type ptr-to-int, it
>>>> means
>>>> this pointer must be capable of pointing to a valid int object., It has
>>>> nothing to do with what it points to.
>>>> The above the pointer is shown pointing to nothing, an integer and an
>>>> array
>>>> of integers.
>>>
>>> What is shown is p having the null pointer value, pointing to an
>>> integer, and pointing to the first integer in an array of integers
>>> (the result of the expression (new int[64]) is a pointer to int,
>>> not a pointer to array of int).
>>
>> No what is returned from the new expression is a pointer to the first
>> element *of an array* of integers.
>> When the pointer is used as a pointer to the array like so:
>> p[3];
>> The expression is evaluated as:
>> *(p+ 3xsizeof(int))
>> Where p is a pointer to the beginning of the array , and the offset to
>> the
>> individual element is added.
>
> The pointer to the first element of the array is a pointer to int (type
> int*). The expression
>
> (p + 3xsizeof(int))
>
> is a pointer to the 3xsizeof(int) element relative to the array element
> that p is treated as pointing to. If p points to the first element of
> and array and sizeof(int) is 4, then
>
> (p + 3xsizeof(int))
>
> points to the 13th element of the array (first plus 12).
>
> Pointers in C++ are typed. The storage location that is pointed to
> when adding a pointer and an integral value depends on the pointer
> type.
>
>> This pointer is used as a pointer to the array, not to only just one
>> element. And it can be used as a pointer to the array because it points
>> to
>> an array.
>
> In the example, the pointer is not used as a pointer to an array of
> int. p is a pointer to int. It may point to an element in an array
> of int. A pointer to an element in an array of int is not same as a
> pointer to the array. The former is of type int*; the latter is of
> type like int(*)[64]. If p could be used as a pointer to an array (of
> 64 int), the following would be allowed, but it isn't.
>
> int (*parr)[64] = p;
>
>> Yes its TYPE is int*, but this does not mean it can only point to one
>> single
>> integer. Its type does not define what it points to.
>
> The type of a pointer defines what may be validly pointed to. An int*
> may validly point to one single integer.
>
>>>> Now consider the following code:
>>>> int *p;
>>>> What does this point to? Uninitialised memory that could contain
>>>> anything.
>>>> The pointer type only tells us that the declared pointer object is
>>>> capable
>>>> of pointing to an integer, it does not define what is pointed to, as
>>>> you
>>>> have tried to imply.
>>>
>>> It is undefined what p points to. I have used shorter phrases, such
>>> as "is a T", rather than a longer ones, such as "is of type T". You
>>> are misreading "is a T" as "is an object of type T that exists when
>>> the program runs".
>>
>> Well you have said that, becuase it is of type int*, it can only point to
>> an
>> int.
>> Now you are saying it is undefined what it points to.
>> I repeat..the pointer type does not define what is pointed to.
>
> I can repeat, too. As I wrote above, where cp is of type char*
>
> The value cp may validly be the address of a char object, the address
> of a char object +1, or NULL. Dereferencing cp when its value is not
> the address of a char object is undefined behavior. These posts are
> long enough without have to mention undefined behavior when a value
> is not valid.
>
>> You are shortening the term a "pointer type ptr-to-T" to mean the same as
>> a
>> "pointer to T". But the two terms do not mean the same thing.
>> One term is specifically describing the pointer type. The other is
>> referring
>> to whatever is at the location pointed to.
>
> I have not used the term "ptr-to-T". Where is it in the C++ standard?
>
> The value of a pointer to T, where T is a non-polymorphic type, may
> validly be the address of an object of type T, the address of an object
> of type T +1, or NULL. Dereferencing a pointer to T when its value
> is not the address of an object of type T is undefined behavior. These
> posts are long enough without having to mention undefined behavior when
> a value is not valid.
>
>>>>> The result of using a stack frame pointer as an address operand
>>>>> depends on what the operator does. Different operators move 1, 2, 4,
>>>>> 8, or some other number of bytes to or from storage starting at the
>>>>> address given by the address operand.
>>>>
>>>> What you seem to be talking about here is what I know as the PTR
>>>> keyword
>>>> in
>>>> assembly, it may change in different assemblers.
>>>> I don't really see what this has to do with the fundamental concept
>>>> that
>>>> a
>>>> SFP "points to" a stack frame.
>>>
>>> In that case, you don't really see the difference between a value
>>> with the correct number of bits to be used as an address in assembler
>>> and a C++ pointer. C++ pointers are typed.
>>
>> The term "pointer" is not redefined because C++ pointers are typed.
>>
>> A pointer is defined in the C standard and C++ inherits this defintion. A
>> pointer of type char* can point to a single char, and array of chars or
>> nothing at all. This is the view of the C standard and also Bjarne
>> Stroustrup in one of his C++ books.
>
> When I run a C compiler on the statement that tries to set a char*
> to point to an array of char, that is, set the value of a pointer
> to char to the address of an array of char, as in
>
> char arr[4], *pc = &arr;
>
> I get a diagnostic message. Setting a char* to point to an element
> in an array of char, that is, set the value of a pointer to char to
> the address of an element of an array of char, as in
>
> char arr[4], *pc = &arr[0];
>
> is allowed.
>
> In a previous post you partially quoted a glossary entry for char*
> by Bjarne Stroustrup. What you quoted omitted: "Typically assumed
> to point to a C-style string. Prefer a standard library string over
> a C-style string when you can. TC++PL 2.3.3, 13.5.2."
>
> The context of the glossary entry is C-style strings. The glossary
> did not contain similar entries for other specific types, such as
> int*, or an entry for T* that states a T* is a pointer to a T or to
> an array of T.
>
> Allowing
>
> char v[] = "Annemarie";
>
> is a special case for arrays of char and C-style strings.
>
> When writing at a detailed level, Bjarne Stroustrup is careful
> about the details, as in the following from an example on page
> 91 of the Special Edition of "The C++ Programming Language".
>
> int v[] = { 1, 2, 3, 4 };
> int* p1 = v; // pointer to initial element (implicit conversion)
>
> Note that p1 is a pointer to the initial element, not a pointer to
> the array.
>
> In an eariler edition of the same book he wrote (page 53 of the
> second edition):
>
> Pointers to arrays and pointers to functions unfortunately need a
> more complicated notation.
>
> int* pi;
> char** cpp; // pointer to pointer to char
> int (*vp)[10]; // pointer to array of 10 ints
> int (*fp)(char, char*); // pointer to function
> // taking (char, char*) arguments
> // and returning int
>
> An int(*)[] points to an array of int; a int* does not, but it may
> point to an element in an array of int.
>
>> With an array like so:
>> [int][int][int][int][int][int][int][int]
>> If a pointer 'p' points to the beinning of this array then the
>> expression:
>> p+1;
>> points to the second element.
>> p+2;
>> points to the third element, and so on.
>>
>> The pointer 'p' points to an array of integers, not only one single
>> integer.
>> The TYPE of 'p' can only be int*, because if it were of type int (*)[8]
>> then
>> p+2 would point away past the array.
>
> The pointer p points to an int. It is the semantics of the binary +
> operator that p+i points to the i-th element of an array when p
> points to the first element of the array. Those semantics also treat
> an int(*)[8] as pointing to an element in an int[][8] array when an
> integral value is added to an int(*)[8].
>
>> The pointer 'p' is used as a pointer to an array of integers, it could
>> not
>> be used as a pointer to an array if it only pointed to one single object.
>> It is a different concept from pointing to one single array type object.
>
> The pointer p cannot be used as a pointer to an array of integers. If
> it could, the last initialization in the following declaration would be
> allowed, but it isn't.
>
> int arr[4], (*parr)[4] = &arr, *p = parr;
>
> The pointer p points to a single int type object. It may point to an
> element in an array of int. In which case, it is pointing to a single
> int in that array.
>
> When p is pointing to a single int in an array, it due to the
> semantics of adding a pointer and an integral value that (p+1) points
> to the next element in the array. Pointing to an element in an array
> is a different concept than pointing to an array.
The C++ standerd does not disgaree with me but it disagrees with you.
Whether tthe C++ standard is right or wrong, whether you are right or wrong
, IDC but I know that an int* can point to, a single int, an array of
integers, or nothing at all.
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-06-11 11:41 -0500 |
| Message-ID | <slrniv76ku.15j6.aggedor@earl-grey.cloud9.net> |
| In reply to | #6453 |
On 2011-06-08, Paul <pchristor@yahoo.co.uk> wrote: > > "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message > news:slrniuvscs.2fsr.aggedor@earl-grey.cloud9.net... [snip] > The C++ standerd does not disgaree with me but it disagrees with you. > Whether tthe C++ standard is right or wrong, whether you are right or wrong > , IDC but I know that an int* can point to, a single int, an array of > integers, or nothing at all. Exactly where does the C++ standard disagree with me? I have quoted paragraphs from it that support what I have claimed about C++. The C++ standard is right when the subject matter is what is required of implementations of C++. Something neither explictly stated in nor inferred from the C++ standard is not part of C++.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-06-12 00:56 +0100 |
| Message-ID | <rhTIp.9246$J65.7937@newsfe14.ams2> |
| In reply to | #6622 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message news:slrniv76ku.15j6.aggedor@earl-grey.cloud9.net... > On 2011-06-08, Paul <pchristor@yahoo.co.uk> wrote: >> >> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message >> news:slrniuvscs.2fsr.aggedor@earl-grey.cloud9.net... > > [snip] > >> The C++ standerd does not disgaree with me but it disagrees with you. >> Whether tthe C++ standard is right or wrong, whether you are right or >> wrong >> , IDC but I know that an int* can point to, a single int, an array of >> integers, or nothing at all. > > Exactly where does the C++ standard disagree with me? I have quoted > paragraphs from it that support what I have claimed about C++. > > The C++ standard is right when the subject matter is what is required > of implementations of C++. Something neither explictly stated in nor > inferred from the C++ standard is not part of C++. > Well lets start with your definition of a pointer. The C++ standard defines that it's based on the C language. Pointers are not defined in the C++ standard , they are defined in the C standard. You can quote stuff from the C++ standard all day but these quotes mean nothing if they are taken out of context. What is a pointer? According to you a pointer of type X* , points to an X and can point to nothing else. I don't care even if the C++ standard did agree with that, its simply wrong. It can be proved wrong with the simple example of a null pointer: X* p = 0; You argument is based upon a twisted misinterpretation of the C++ standards and it ignores simple facts.
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-06-14 13:44 -0500 |
| Message-ID | <slrnivfavp.13k1.aggedor@earl-grey.cloud9.net> |
| In reply to | #6638 |
On 2011-06-11, Paul <pchristor@yahoo.co.uk> wrote: > > "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message > news:slrniv76ku.15j6.aggedor@earl-grey.cloud9.net... >> On 2011-06-08, Paul <pchristor@yahoo.co.uk> wrote: >>> >>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message >>> news:slrniuvscs.2fsr.aggedor@earl-grey.cloud9.net... >> >> [snip] >> >>> The C++ standerd does not disgaree with me but it disagrees with you. >>> Whether tthe C++ standard is right or wrong, whether you are right or >>> wrong >>> , IDC but I know that an int* can point to, a single int, an array of >>> integers, or nothing at all. >> >> Exactly where does the C++ standard disagree with me? I have quoted >> paragraphs from it that support what I have claimed about C++. >> >> The C++ standard is right when the subject matter is what is required >> of implementations of C++. Something neither explictly stated in nor >> inferred from the C++ standard is not part of C++. >> > Well lets start with your definition of a pointer. > The C++ standard defines that it's based on the C language. Pointers are not > defined in the C++ standard , they are defined in the C standard. Pointers are defined in the C++ standard. See 8.3.1 (Pointers) and the numerous occurrences of "pointer" in the C++ standard. Although C++ is based on C, C++ is not a superset of C. Some valid C programs are not valid C++ programs, even some C programs that do not use an identifier that is a keyword added to C++. > You can quote stuff from the C++ standard all day but these quotes mean > nothing if they are taken out of context. What in the C++ standard have I taken out of context? For the most part I have quoted entire paragraphs from the standard in order to retain the context. > What is a pointer? > According to you a pointer of type X* , points to an X and can point to > nothing else. I don't care even if the C++ standard did agree with that, its > simply wrong. > It can be proved wrong with the simple example of a null pointer: > X* p = 0; > You argument is based upon a twisted misinterpretation of the C++ standards > and it ignores simple facts. Saying that a pointer of type X* points only to an X is a simplification. Two posts ago, I wrote The value of a pointer to T, where T is a non-polymorphic type, may validly be the address of an object of type T, the address of an object of type T +1, or NULL. Dereferencing a pointer to T when its value is not the address of an object of type T is undefined behavior. These posts are long enough without having to mention undefined behavior when a value is not valid. There is no twisted misintpretation here. If there is a conflict between what is in the C++ standard and "simple facts", it is what is in the C++ standard that is correct for the C++ programming language.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-06-14 23:01 +0100 |
| Message-ID | <cTQJp.9702$J65.4622@newsfe14.ams2> |
| In reply to | #6747 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message news:slrnivfavp.13k1.aggedor@earl-grey.cloud9.net... > On 2011-06-11, Paul <pchristor@yahoo.co.uk> wrote: >> >> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message >> news:slrniv76ku.15j6.aggedor@earl-grey.cloud9.net... >>> On 2011-06-08, Paul <pchristor@yahoo.co.uk> wrote: >>>> >>>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message >>>> news:slrniuvscs.2fsr.aggedor@earl-grey.cloud9.net... >>> >>> [snip] >>> >>>> The C++ standerd does not disgaree with me but it disagrees with you. >>>> Whether tthe C++ standard is right or wrong, whether you are right or >>>> wrong >>>> , IDC but I know that an int* can point to, a single int, an array of >>>> integers, or nothing at all. >>> >>> Exactly where does the C++ standard disagree with me? I have quoted >>> paragraphs from it that support what I have claimed about C++. >>> >>> The C++ standard is right when the subject matter is what is required >>> of implementations of C++. Something neither explictly stated in nor >>> inferred from the C++ standard is not part of C++. >>> >> Well lets start with your definition of a pointer. >> The C++ standard defines that it's based on the C language. Pointers are >> not >> defined in the C++ standard , they are defined in the C standard. > > Pointers are defined in the C++ standard. See 8.3.1 (Pointers) and > the numerous occurrences of "pointer" in the C++ standard. Although > C++ is based on C, C++ is not a superset of C. Some valid C programs > are not valid C++ programs, even some C programs that do not use an > identifier that is a keyword added to C++. > In the following section of the C++ : 8.0) Declarators 8.3) Meaning of Declarators 8.3.1) Pointer 8.3.1 is a subsection of 8.3 , which is a subsection of 8.0 The whole purpose of this section of the C++ standard is to define declarators. It does not define a pointer , it defines how to declare a pointer. I think this confirmed when you look at the content in section 8.3.1: "8.3.1 Pointers [dcl.ptr] 1 In a declaration T D where D has the form * attribute-specifieropt cv-qualifier-seqopt D1 and the type of the identifier in the declaration T D1 is "derived-declarator-type-list T," then the type of the identifier of D is "derived-declarator-type-list cv-qualifier-seq pointer to T." The cv-qualifiers apply to the pointer and not to the object pointed to. Similarly, the optional attribute-specifier (7.6.1) appertains to the pointer and not to the object pointed to." >> You can quote stuff from the C++ standard all day but these quotes mean >> nothing if they are taken out of context. > > What in the C++ standard have I taken out of context? For the most > part I have quoted entire paragraphs from the standard in order to > retain the context. > Well for a start you have interpreted 8.3.1 as the definition of a pointer, when it actaully defines a pointer declarator. There is a big difference in defining what a pointer is, and defining how to declare one. So this is out of context as the context of the discussion was the definition of a pointer, which more specifically means the definition of what a pointer is , not how to declare one. >> What is a pointer? >> According to you a pointer of type X* , points to an X and can point to >> nothing else. I don't care even if the C++ standard did agree with that, >> its >> simply wrong. >> It can be proved wrong with the simple example of a null pointer: >> X* p = 0; >> You argument is based upon a twisted misinterpretation of the C++ >> standards >> and it ignores simple facts. > > Saying that a pointer of type X* points only to an X is a > simplification. Two posts ago, I wrote > > The value of a pointer to T, where T is a non-polymorphic type, may > validly be the address of an object of type T, the address of an object > of type T +1, or NULL. Dereferencing a pointer to T when its value > is not the address of an object of type T is undefined behavior. These > posts are long enough without having to mention undefined behavior when > a value is not valid. > > There is no twisted misintpretation here. Yes it is , where does the C++ standard define a pointer as you've defined it above? > > If there is a conflict between what is in the C++ standard and > "simple facts", it is what is in the C++ standard that is correct for > the C++ programming language. There is no conlift in the standards, its the way you interpret the standards. The problem seems to be that you cannot accept the defintion of a pointer ,which is inhereted from the C standard.
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-06-16 13:41 -0500 |
| Message-ID | <slrnivkjjl.vql.aggedor@earl-grey.cloud9.net> |
| In reply to | #6753 |
On 2011-06-14, Paul <pchristor@yahoo.co.uk> wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrnivfavp.13k1.aggedor@earl-grey.cloud9.net...
>> On 2011-06-11, Paul <pchristor@yahoo.co.uk> wrote:
[snip]
>>> Well lets start with your definition of a pointer.
>>> The C++ standard defines that it's based on the C language. Pointers are
>>> not
>>> defined in the C++ standard , they are defined in the C standard.
>>
>> Pointers are defined in the C++ standard. See 8.3.1 (Pointers) and
>> the numerous occurrences of "pointer" in the C++ standard. Although
>> C++ is based on C, C++ is not a superset of C. Some valid C programs
>> are not valid C++ programs, even some C programs that do not use an
>> identifier that is a keyword added to C++.
>>
>
> In the following section of the C++ :
> 8.0) Declarators
> 8.3) Meaning of Declarators
> 8.3.1) Pointer
>
> 8.3.1 is a subsection of 8.3 , which is a subsection of 8.0
>
> The whole purpose of this section of the C++ standard is to define
> declarators. It does not define a pointer , it defines how to declare a
> pointer.
> I think this confirmed when you look at the content in section 8.3.1:
>
> "8.3.1 Pointers [dcl.ptr]
> 1 In a declaration T D where D has the form
> * attribute-specifieropt cv-qualifier-seqopt D1
> and the type of the identifier in the declaration T D1 is
> "derived-declarator-type-list T," then the type of the
> identifier of D is "derived-declarator-type-list cv-qualifier-seq pointer to
> T." The cv-qualifiers apply to the pointer
> and not to the object pointed to. Similarly, the optional
> attribute-specifier (7.6.1) appertains to the pointer
> and not to the object pointed to."
Defining how to declare a pointer in C++ is part of the definition of
what a pointer is in C++. I wrote: 'See 8.3.1 (Pointers) and
the numerous occurrences of "pointer" in the C++ standard.' You are
ignoring the numerous occurrences of "pointer" in the C++ standard.
What a pointer is in C++ is not defined in a single place in the
C++ standard. Just as what an int is in C++ is not defined in a
single place: one place defines how to declare an identifier of type
int and other places define the results of operators on an int.
>>> You can quote stuff from the C++ standard all day but these quotes mean
>>> nothing if they are taken out of context.
>>
>> What in the C++ standard have I taken out of context? For the most
>> part I have quoted entire paragraphs from the standard in order to
>> retain the context.
>>
> Well for a start you have interpreted 8.3.1 as the definition of a pointer,
> when it actaully defines a pointer declarator.
> There is a big difference in defining what a pointer is, and defining how to
> declare one.
What is in 8.3.1 is part of the definition of what a pointer is in C++.
It is the part about how an identifier of type pointer is declared.
Other parts of the C++ standard define the results of operators on a
pointer.
> So this is out of context as the context of the discussion was the
> definition of a pointer, which more specifically means the definition of
> what a pointer is , not how to declare one.
My question was: "What in the C++ standard have I taken out of
context?" The context is the C++ standard, not what you mean by
definition of a pointer.
>>> What is a pointer?
>>> According to you a pointer of type X* , points to an X and can point to
>>> nothing else. I don't care even if the C++ standard did agree with that,
>>> its
>>> simply wrong.
>>> It can be proved wrong with the simple example of a null pointer:
>>> X* p = 0;
>>> You argument is based upon a twisted misinterpretation of the C++
>>> standards
>>> and it ignores simple facts.
>>
>> Saying that a pointer of type X* points only to an X is a
>> simplification. Two posts ago, I wrote
>>
>> The value of a pointer to T, where T is a non-polymorphic type, may
>> validly be the address of an object of type T, the address of an object
>> of type T +1, or NULL. Dereferencing a pointer to T when its value
>> is not the address of an object of type T is undefined behavior. These
>> posts are long enough without having to mention undefined behavior when
>> a value is not valid.
>>
>> There is no twisted misintpretation here.
>
> Yes it is , where does the C++ standard define a pointer as you've defined
> it above?
Most of what I wrote just above is from paragraph 3 of 3.9.2
(Compound types), which includes:
A valid value of an object pointer type represents either the
address of a byte in memory (1.7) or a null pointer (4.10). If an
object of type T is located at an address A, a pointer of type cv
T* whose value is the address A is said to point to that object,
regardless of how the value was obtained. [Note: for instance, the
address one past the end of an array (5.7) would be considered to
point to an unrelated object of the arrays element type that might
be located at that address. ]
The Note cites 5.7 (Additive operators). Paragraph 5 of it ends
with:
Moreover, if the expression P points to the last element of an
array object, the expression (P)+1 points one past the last
element of the array object, and if the expression Q points one
past the last element of an array object, the expression (Q)-1
points to the last element of the array object. If both the
pointer operand and the result point to elements of the same
array object, or one past the last element of the array object,
the evaluation shall not produce an overflow; otherwise, the
behavior is undefined.
Paragraph 4 of the same section is:
For the purposes of these operators, a pointer to a nonarray
object behaves the same as a pointer to the first element of an
array of length one with the type of the object as its element
type.
"Dereferencing a pointer to T when its value is not the address
of an object of type T is undefined behavior" is based on paragraph
15 of 3.10 (Lvalues and rvalues), which starts with
If a program attempts to access the stored value of an object
through an lvalue of other than one of the following types the
behavior is undefined:
- the dynamic type of the object,
- a cv-qualified version of the dynamic type of the object,
>> If there is a conflict between what is in the C++ standard and
>> "simple facts", it is what is in the C++ standard that is correct for
>> the C++ programming language.
> There is no conlift in the standards, its the way you interpret the
> standards.
> The problem seems to be that you cannot accept the defintion of a pointer
> ,which is inhereted from the C standard.
There is no conflict between the C++ standard and what I have written
(see my answer above to your question: "where does the C++ standard
define a pointer as you've defined it above?"). The conflict is
between the C++ standard and what you call "simple facts".
Pointers in C and C++ and not the same. For example, assigning from
a pointer to void to a pointer to int is allowed in C, but it is not
allowed in C++.
The C standard, like the C++ standard, does not define what a pointer
is in a single place. In the C99 standard section 6.7.5.1 (Pointer
declarators) is like section 8.3.1 (Pointers) of the C++ standard.
In the C99 standard section 6.5.6 (Additive operators) is like
section 5.7 (Additive operators) in the C++ standard; they both
define the semantics of adding an integral value to a pointer.
I accept what is actually in the C and C++ standards. I also accept
the differences between those standards. What I do not accept are
"simple facts" and claims about C and C++ that are not supported by
what is actually in the standards.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-06-16 23:01 +0100 |
| Message-ID | <K2vKp.9773$J65.6701@newsfe14.ams2> |
| In reply to | #6817 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message news:slrnivkjjl.vql.aggedor@earl-grey.cloud9.net... > On 2011-06-14, Paul <pchristor@yahoo.co.uk> wrote: >> >> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message >> news:slrnivfavp.13k1.aggedor@earl-grey.cloud9.net... >>> On 2011-06-11, Paul <pchristor@yahoo.co.uk> wrote: > > [snip] > >>>> Well lets start with your definition of a pointer. >>>> The C++ standard defines that it's based on the C language. Pointers >>>> are >>>> not >>>> defined in the C++ standard , they are defined in the C standard. >>> >>> Pointers are defined in the C++ standard. See 8.3.1 (Pointers) and >>> the numerous occurrences of "pointer" in the C++ standard. Although >>> C++ is based on C, C++ is not a superset of C. Some valid C programs >>> are not valid C++ programs, even some C programs that do not use an >>> identifier that is a keyword added to C++. >>> >> >> In the following section of the C++ : >> 8.0) Declarators >> 8.3) Meaning of Declarators >> 8.3.1) Pointer >> >> 8.3.1 is a subsection of 8.3 , which is a subsection of 8.0 >> >> The whole purpose of this section of the C++ standard is to define >> declarators. It does not define a pointer , it defines how to declare a >> pointer. >> I think this confirmed when you look at the content in section 8.3.1: >> >> "8.3.1 Pointers [dcl.ptr] >> 1 In a declaration T D where D has the form >> * attribute-specifieropt cv-qualifier-seqopt D1 >> and the type of the identifier in the declaration T D1 is >> "derived-declarator-type-list T," then the type of the >> identifier of D is "derived-declarator-type-list cv-qualifier-seq pointer >> to >> T." The cv-qualifiers apply to the pointer >> and not to the object pointed to. Similarly, the optional >> attribute-specifier (7.6.1) appertains to the pointer >> and not to the object pointed to." > > Defining how to declare a pointer in C++ is part of the definition of > what a pointer is in C++. I wrote: 'See 8.3.1 (Pointers) and > the numerous occurrences of "pointer" in the C++ standard.' You are > ignoring the numerous occurrences of "pointer" in the C++ standard. Defining rules for driving a car is not the same thing as defining what a car is. What you seem to be suggesting here is that every occurence of the word "pointer" in the C++ standard is actually part of the definition of a pointer. > > What a pointer is in C++ is not defined in a single place in the > C++ standard. Just as what an int is in C++ is not defined in a > single place: one place defines how to declare an identifier of type > int and other places define the results of operators on an int. > What a pointer is, is defined in the C standard. An "int" is a type, it is probably defined in the section "Types". >>>> You can quote stuff from the C++ standard all day but these quotes mean >>>> nothing if they are taken out of context. >>> >>> What in the C++ standard have I taken out of context? For the most >>> part I have quoted entire paragraphs from the standard in order to >>> retain the context. >>> >> Well for a start you have interpreted 8.3.1 as the definition of a >> pointer, >> when it actaully defines a pointer declarator. >> There is a big difference in defining what a pointer is, and defining how >> to >> declare one. > > What is in 8.3.1 is part of the definition of what a pointer is in C++. > It is the part about how an identifier of type pointer is declared. > Other parts of the C++ standard define the results of operators on a > pointer. A pointer is defined as a compound type re 3.9.2: "3.9.2 Compound types [basic.compound] 1 Compound types can be constructed in the following ways: - arrays of objects of a given type, 8.3.4; - functions, which have parameters of given types and return void or references or objects of a given type, 8.3.5; - pointers to void or objects or functions (including static members of classes) of a given type, 8.3.1;" Note that pointer is in italics so it's defined here. 8.3.1 gives further information about the rules for declaring pointers but it doesn't define what a pointer is. The above defines a pointer to be a compund type. In the same section, re paragraph 3, there is further information on the definition of a pointer it begins: "3 A pointer to objects of type T is referred to as a "pointer to T."" So what does this mean.... With the following two arrays(and pointers to them) examples: a) T* pT1 = new T[101]; b) T (*pT2)[101] = (T (*)[101]) new T[101]; Ok so pT1 and pT2 are both pointers to objects of type T but in a different way so lets see how this compares to the definiton in the C++ standard. pT1 is a pointer to objects of type T and is referred to as a pointer to T. pT2 is a pointer to objects of type T(*)[101] and is referred to as a pointer to T(*)[101]. This seems to me to be exactly as I have explained previously, the difference is whether the array is seen as an array of integer objects or a single array-object. Any argument that one is more correct than the other is nothing more than pedantic quibling over terminology, I maintain that the terminology I use is genrally accepted terminology and used all across many programming communities. Many programmers refer to pT1 as a pointer to an array, though it doesn't point to an array-object, it points to an array of T objects, BS included. There is a further problem in your use of terminology and it goes back to the old argument about the terminology in the standards not being the same as the terminology used by every day programmers. If the standards states that X will be referred to as Y. It means that is how it will be used in the context of the standard, it is not stating that this is the terminology every day programmers must use and this is a big problem with many of the flame wars in these forums. An example is the term "object". If I am discussing inheritance or some other aspect of OOP in C++ , and you tell me an int is an object because the standard says so then you are using this out of context. In the context of a discussion about OOP an object is an instance of a class-type , not an int or a char. In general the problem is there are too many wanabees who think they know it all and try to correct people on the most pedantic of terminology "errors" because they have nothing better to do. Unfortunately for many people in this case they can try all they want to say that p(in the following) does not point to an array but they would be wrong becuase it points to an array of integer objects. int* p = new int[101]; To suggest that this pointer does not point to an array because the standard states it will be referred to as "a pointer to integer" is complete nonsense. It points to an array of integer objects, therefore it's a pointer to an array of integer objects.
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-06-18 12:23 -0500 |
| Message-ID | <slrnivpnok.2phk.aggedor@earl-grey.cloud9.net> |
| In reply to | #6826 |
On 2011-06-16, Paul <pchristor@yahoo.co.uk> wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrnivkjjl.vql.aggedor@earl-grey.cloud9.net...
[snip]
>> Defining how to declare a pointer in C++ is part of the definition of
>> what a pointer is in C++. I wrote: 'See 8.3.1 (Pointers) and
>> the numerous occurrences of "pointer" in the C++ standard.' You are
>> ignoring the numerous occurrences of "pointer" in the C++ standard.
>
> Defining rules for driving a car is not the same thing as defining what a
> car is.
> What you seem to be suggesting here is that every occurence of the word
> "pointer" in the C++ standard is actually part of the definition of a
> pointer.
Every occurrence of the word "pointer" in the C++ standard specifies
how an implementation of C++ is to treat a pointer in the context
described by that part of the C++ standard. All those parts of the
C++ standard taken together define what a pointer is in C++.
>> What a pointer is in C++ is not defined in a single place in the
>> C++ standard. Just as what an int is in C++ is not defined in a
>> single place: one place defines how to declare an identifier of type
>> int and other places define the results of operators on an int.
>>
> What a pointer is, is defined in the C standard.
> An "int" is a type, it is probably defined in the section "Types".
What a pointer is in C++ is defined in the C++ standard, not in the
C standard. C++ is based on C; C++ is not a copy of C.
[snip]
>> What is in 8.3.1 is part of the definition of what a pointer is in C++.
>> It is the part about how an identifier of type pointer is declared.
>> Other parts of the C++ standard define the results of operators on a
>> pointer.
>
> A pointer is defined as a compound type re 3.9.2:
>
> "3.9.2 Compound types [basic.compound]
> 1 Compound types can be constructed in the following ways:
> - arrays of objects of a given type, 8.3.4;
> - functions, which have parameters of given types and return void or
> references or objects of a given
> type, 8.3.5;
> - pointers to void or objects or functions (including static members of
> classes) of a given type, 8.3.1;"
>
> Note that pointer is in italics so it's defined here. 8.3.1 gives further
> information about the rules for declaring pointers but it doesn't define
> what a pointer is.
> The above defines a pointer to be a compund type.
>
> In the same section, re paragraph 3, there is further information on the
> definition of a pointer it begins:
> "3 A pointer to objects of type T is referred to as a "pointer to T.""
>
>
> So what does this mean....
> With the following two arrays(and pointers to them) examples:
> a) T* pT1 = new T[101];
> b) T (*pT2)[101] = (T (*)[101]) new T[101];
>
> Ok so pT1 and pT2 are both pointers to objects of type T but in a different
> way so lets see how this compares to the definiton in the C++ standard.
No, pT1 and pT2 are not both pointers to objects of type T. pT1 is
a pointer to an object of type T. pT1 is initialized to the value of
the T* returned by new T[101]. pT2 is a pointer to an array of 101 T.
pT2 is initialized by an explicit type conversion that overrides the
type checking done by C++. A C++ implementation rejects the statement
T (*pT3)[101] = pT1;
because a pointer to T is not a pointer to an array of T.
The explicit type conversion may result in undefined behavoir, as in
dereferencing the pointer declared by the following statement.
T (*pT4)[101] = (T (*)[101]) 37;
> pT1 is a pointer to objects of type T and is referred to as a pointer to T.
> pT2 is a pointer to objects of type T(*)[101] and is referred to as a
> pointer to T(*)[101].
The value of pT1 may validly be the address of a single object of type
T, not multiple objects of type T. The result of dereferencing pT1 is
a single object of type T, not multiple objects of type T. According
to the start of paragraph 1 of 5.3.1 (Unary operators):
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.
Note that the result is "the value" (singular) not "the values"
(plural).
Similarly, the value of pT2 may validly be the address of a single
object of type array of 101 T, not multiple objects of that type.
> This seems to me to be exactly as I have explained previously, the
> difference is whether the array is seen as an array of integer objects or a
> single array-object.
Whether an array or a sub-object in that array is pointed to is
determined by the type of the pointer. For an array of 10 int, a
int(*)[10] may point to the array object while a int* may point to
a sub-object in the array object.
> Any argument that one is more correct than the other is nothing more than
> pedantic quibling over terminology, I maintain that the terminology I use is
> genrally accepted terminology and used all across many programming
> communities. Many programmers refer to pT1 as a pointer to an array, though
> it doesn't point to an array-object, it points to an array of T objects, BS
> included.
The many programmers who refer to pT1 as a pointer to an array are
technically incorrect. Programmers dealing with C++ at the level
of detail of the C++ standard are careful about the details. Those
who understand C++ at the level of detail of the C++ standard are
less likely to be confused about what a pointer to an array is.
Exactly where does BS state than pT1 points to an array of T objects,
as opposed to being able to point to a T object that is an element
in an array of T? Here, again, is what Bjarne Stroustrup wrote in
The C++ Programming Language (page 91 of the Special Edition)
The name of an array can be used as a pointer to its initial
element. For example:
int v[] = { 1, 2, 3, 4 };
int* p1 = v; // pointer to initial element (implicitly converted)
int* p2 = &v[0]; // pointer to initial element
int* p3 = &v[4]; // pointer to one beyond last element
Note that each pointer is to an element in the array or one beyond
the last element, the pointers are not to the array. A pointer to
the array named v in the example would be:
int (*p)[4] = &v;
> There is a further problem in your use of terminology and it goes back to
> the old argument about the terminology in the standards not being the same
> as the terminology used by every day programmers. If the standards states
> that X will be referred to as Y. It means that is how it will be used in
> the context of the standard, it is not stating that this is the terminology
> every day programmers must use and this is a big problem with many of the
> flame wars in these forums.
> An example is the term "object". If I am discussing inheritance or some
> other aspect of OOP in C++ , and you tell me an int is an object because the
> standard says so then you are using this out of context. In the context of a
> discussion about OOP an object is an instance of a class-type , not an int
> or a char.
My first post to this thread was a quote from the C++ standard about
what the expression
new int [4]
returns. See
http://groups.google.com/group/comp.lang.c++/msg/dc6879307c277751?hl=en
Since then I have been responding to followups you have made to my
posts. I have answered questions you have asked me (include "Are you
a complete fucking idiot? !!!"). See
http://groups.google.com/group/comp.lang.c++/msg/bc5aae365871a528?hl=en
I have responded to questionable statements you have made about what I
have written.
Here, I'll respond to a questionable statement you wrote just above:
"If I am discussing inheritance or some other aspect of OOP in C++ ,
and you tell me an int is an object because the standard says so then
you are using this out of context." I have never told you that an
int is object because the standard says so when you were discusssing
inheritance or some other aspect of OOP in C++.
> In general the problem is there are too many wanabees who think they know it
> all and try to correct people on the most pedantic of terminology "errors"
> because they have nothing better to do.
> Unfortunately for many people in this case they can try all they want to say
> that p(in the following) does not point to an array but they would be wrong
> becuase it points to an array of integer objects.
> int* p = new int[101];
I don't know it all. I am willing to share the knowledge of C++ that
I have. When someone asks a question in comp.lang.c++ and none of
the other responses have included some important information, such as
what is in the C++ standard about the issue, I'll post the information
I have.
With
int* p = new int[101];
p points to an int, not to an array of int (the initialization
expression returns a pointer to int). What points to an array
of 101 int is a int(*)[101]. If you think that is nothing more than
pedantic quibling over terminology, say that and be done with it
(rather than flame by calling someone a "complete fucking idiot").
> To suggest that this pointer does not point to an array because the standard
> states it will be referred to as "a pointer to integer" is complete
> nonsense. It points to an array of integer objects, therefore it's a pointer
> to an array of integer objects.
You may consider what is in the C++ standard as complete nonsense. I
accept what is actually in the C++ standard as the definition of C++.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-06-18 19:50 +0100 |
| Message-ID | <Yr6Lp.5182$Ll1.3109@newsfe24.ams2> |
| In reply to | #6886 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
news:slrnivpnok.2phk.aggedor@earl-grey.cloud9.net...
> On 2011-06-16, Paul <pchristor@yahoo.co.uk> wrote:
>>
>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>> news:slrnivkjjl.vql.aggedor@earl-grey.cloud9.net...
>
> [snip]
>
>>> Defining how to declare a pointer in C++ is part of the definition of
>>> what a pointer is in C++. I wrote: 'See 8.3.1 (Pointers) and
>>> the numerous occurrences of "pointer" in the C++ standard.' You are
>>> ignoring the numerous occurrences of "pointer" in the C++ standard.
>>
>> Defining rules for driving a car is not the same thing as defining what a
>> car is.
>> What you seem to be suggesting here is that every occurence of the word
>> "pointer" in the C++ standard is actually part of the definition of a
>> pointer.
>
> Every occurrence of the word "pointer" in the C++ standard specifies
> how an implementation of C++ is to treat a pointer in the context
> described by that part of the C++ standard. All those parts of the
> C++ standard taken together define what a pointer is in C++.
>
No it doesn't I can speak about C++ and use the term "pointer" to mean
Instruction pointer. The standard does not define the english langauge nor
does it define programming terminology.
It defines a pointer ...drumroll.... where it is defined......... in
italics.
>>> What a pointer is in C++ is not defined in a single place in the
>>> C++ standard. Just as what an int is in C++ is not defined in a
>>> single place: one place defines how to declare an identifier of type
>>> int and other places define the results of operators on an int.
>>>
>> What a pointer is, is defined in the C standard.
>> An "int" is a type, it is probably defined in the section "Types".
>
> What a pointer is in C++ is defined in the C++ standard, not in the
> C standard. C++ is based on C; C++ is not a copy of C.
>
> [snip]
>
>>> What is in 8.3.1 is part of the definition of what a pointer is in C++.
>>> It is the part about how an identifier of type pointer is declared.
>>> Other parts of the C++ standard define the results of operators on a
>>> pointer.
>>
>> A pointer is defined as a compound type re 3.9.2:
>>
>> "3.9.2 Compound types [basic.compound]
>> 1 Compound types can be constructed in the following ways:
>> - arrays of objects of a given type, 8.3.4;
>> - functions, which have parameters of given types and return void or
>> references or objects of a given
>> type, 8.3.5;
>> - pointers to void or objects or functions (including static members of
>> classes) of a given type, 8.3.1;"
>>
>> Note that pointer is in italics so it's defined here. 8.3.1 gives further
>> information about the rules for declaring pointers but it doesn't define
>> what a pointer is.
>> The above defines a pointer to be a compund type.
>>
>> In the same section, re paragraph 3, there is further information on the
>> definition of a pointer it begins:
>> "3 A pointer to objects of type T is referred to as a "pointer to T.""
>>
>>
>> So what does this mean....
>> With the following two arrays(and pointers to them) examples:
>> a) T* pT1 = new T[101];
>> b) T (*pT2)[101] = (T (*)[101]) new T[101];
>>
>> Ok so pT1 and pT2 are both pointers to objects of type T but in a
>> different
>> way so lets see how this compares to the definiton in the C++ standard.
>
> No, pT1 and pT2 are not both pointers to objects of type T. pT1 is
> a pointer to an object of type T. pT1 is initialized to the value of
> the T* returned by new T[101]. pT2 is a pointer to an array of 101 T.
> pT2 is initialized by an explicit type conversion that overrides the
> type checking done by C++. A C++ implementation rejects the statement
>
Nonsense pT1 and pT2 both point to 101 int objects, they both point to
exactly the same type of dynamically allocated memory.
> T (*pT3)[101] = pT1;
Only you are daft enough to assume this is possible without a cast.
>
> because a pointer to T is not a pointer to an array of T.
>
> The explicit type conversion may result in undefined behavoir, as in
> dereferencing the pointer declared by the following statement.
>
> T (*pT4)[101] = (T (*)[101]) 37;
>
>> pT1 is a pointer to objects of type T and is referred to as a pointer to
>> T.
>> pT2 is a pointer to objects of type T(*)[101] and is referred to as a
>> pointer to T(*)[101].
>
> The value of pT1 may validly be the address of a single object of type
> T, not multiple objects of type T. The result of dereferencing pT1 is
> a single object of type T, not multiple objects of type T. According
> to the start of paragraph 1 of 5.3.1 (Unary operators):
I just told you what the standard states. I repeat:
pT1 is a pointer to objects of type T and is referred to as a pointer to T.
pT2 is a pointer to objects of type T(*)[101] and is referred to as a
pointer to T(*)[101].
Are you dsisagreeing with this? Or are you trying to go off on a different
direction and avoid the facts by blabbering on about the value of pT1 and
pT2?
Both pointers have the same value , the starting address of the array.
>
> 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.
>
It doesn't matter what the unary operator does. This does not define what a
pointer is.
Again you are taking stuff out of context.
> Note that the result is "the value" (singular) not "the values"
> (plural).
>
> Similarly, the value of pT2 may validly be the address of a single
> object of type array of 101 T, not multiple objects of that type.
>
>> This seems to me to be exactly as I have explained previously, the
>> difference is whether the array is seen as an array of integer objects or
>> a
>> single array-object.
>
> Whether an array or a sub-object in that array is pointed to is
> determined by the type of the pointer. For an array of 10 int, a
> int(*)[10] may point to the array object while a int* may point to
> a sub-object in the array object.
>
>> Any argument that one is more correct than the other is nothing more than
>> pedantic quibling over terminology, I maintain that the terminology I use
>> is
>> genrally accepted terminology and used all across many programming
>> communities. Many programmers refer to pT1 as a pointer to an array,
>> though
>> it doesn't point to an array-object, it points to an array of T objects,
>> BS
>> included.
>
> The many programmers who refer to pT1 as a pointer to an array are
> technically incorrect. Programmers dealing with C++ at the level
> of detail of the C++ standard are careful about the details. Those
> who understand C++ at the level of detail of the C++ standard are
> less likely to be confused about what a pointer to an array is.
Well the C++ standard and Bjarne Stroustrup are both techincally incorrect
in your opinion.
I'm sorry but I cannot accept your nonsense they are not techincally
incorrect it is you who is incorrect because you do not understand the
english language properly.
>
> Exactly where does BS state than pT1 points to an array of T objects,
> as opposed to being able to point to a T object that is an element
> in an array of T? Here, again, is what Bjarne Stroustrup wrote in
> The C++ Programming Language (page 91 of the Special Edition)
>
char* - pointer to a char or an array of char.
http://www2.research.att.com/~bs/glossary.html
> The name of an array can be used as a pointer to its initial
> element. For example:
>
> int v[] = { 1, 2, 3, 4 };
> int* p1 = v; // pointer to initial element (implicitly converted)
> int* p2 = &v[0]; // pointer to initial element
> int* p3 = &v[4]; // pointer to one beyond last element
>
> Note that each pointer is to an element in the array or one beyond
> the last element, the pointers are not to the array. A pointer to
> the array named v in the example would be:
>
> int (*p)[4] = &v;
>
>> There is a further problem in your use of terminology and it goes back to
>> the old argument about the terminology in the standards not being the
>> same
>> as the terminology used by every day programmers. If the standards states
>> that X will be referred to as Y. It means that is how it will be used in
>> the context of the standard, it is not stating that this is the
>> terminology
>> every day programmers must use and this is a big problem with many of the
>> flame wars in these forums.
>> An example is the term "object". If I am discussing inheritance or some
>> other aspect of OOP in C++ , and you tell me an int is an object because
>> the
>> standard says so then you are using this out of context. In the context
>> of a
>> discussion about OOP an object is an instance of a class-type , not an
>> int
>> or a char.
>
> My first post to this thread was a quote from the C++ standard about
> what the expression
>
> new int [4]
>
> returns. See
> http://groups.google.com/group/comp.lang.c++/msg/dc6879307c277751?hl=en
>
> Since then I have been responding to followups you have made to my
> posts. I have answered questions you have asked me (include "Are you
> a complete fucking idiot? !!!"). See
> http://groups.google.com/group/comp.lang.c++/msg/bc5aae365871a528?hl=en
> I have responded to questionable statements you have made about what I
> have written.
>
> Here, I'll respond to a questionable statement you wrote just above:
> "If I am discussing inheritance or some other aspect of OOP in C++ ,
> and you tell me an int is an object because the standard says so then
> you are using this out of context." I have never told you that an
> int is object because the standard says so when you were discusssing
> inheritance or some other aspect of OOP in C++.
>
>> In general the problem is there are too many wanabees who think they know
>> it
>> all and try to correct people on the most pedantic of terminology
>> "errors"
>> because they have nothing better to do.
>> Unfortunately for many people in this case they can try all they want to
>> say
>> that p(in the following) does not point to an array but they would be
>> wrong
>> becuase it points to an array of integer objects.
>> int* p = new int[101];
>
> I don't know it all. I am willing to share the knowledge of C++ that
> I have. When someone asks a question in comp.lang.c++ and none of
> the other responses have included some important information, such as
> what is in the C++ standard about the issue, I'll post the information
> I have.
>
> With
>
> int* p = new int[101];
>
> p points to an int, not to an array of int (the initialization
> expression returns a pointer to int). What points to an array
> of 101 int is a int(*)[101]. If you think that is nothing more than
> pedantic quibling over terminology, say that and be done with it
> (rather than flame by calling someone a "complete fucking idiot").
Well TBH you are a fuckin idiot if you cannot see that 'p' points to more
than one integer object.
>
>> To suggest that this pointer does not point to an array because the
>> standard
>> states it will be referred to as "a pointer to integer" is complete
>> nonsense. It points to an array of integer objects, therefore it's a
>> pointer
>> to an array of integer objects.
>
> You may consider what is in the C++ standard as complete nonsense. I
> accept what is actually in the C++ standard as the definition of C++.
I repeat my quote for you:
"3 A pointer to objects of type T is referred to as a "pointer to T.""
It says OBJECTS not single object. It is you who does not accept what the
standard states. The standards support me not you.
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-06-21 13:38 -0500 |
| Message-ID | <slrnj01pa1.2ia2.aggedor@earl-grey.cloud9.net> |
| In reply to | #6890 |
On 2011-06-18, Paul <pchristor@yahoo.co.uk> wrote:
>
> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
> news:slrnivpnok.2phk.aggedor@earl-grey.cloud9.net...
>> On 2011-06-16, Paul <pchristor@yahoo.co.uk> wrote:
>>>
>>> "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
>>> news:slrnivkjjl.vql.aggedor@earl-grey.cloud9.net...
[snip]
>> Every occurrence of the word "pointer" in the C++ standard specifies
>> how an implementation of C++ is to treat a pointer in the context
>> described by that part of the C++ standard. All those parts of the
>> C++ standard taken together define what a pointer is in C++.
>>
> No it doesn't I can speak about C++ and use the term "pointer" to mean
> Instruction pointer. The standard does not define the english langauge nor
> does it define programming terminology.
> It defines a pointer ...drumroll.... where it is defined......... in
> italics.
If you use the term "instruction pointer", you are using a term that
does not occur in the C++ standard. The C++ standard defines the C++
programming language. Part of that definition is the results of
operators, include operators on pointers.
[snip]
>>>> What is in 8.3.1 is part of the definition of what a pointer is in C++.
>>>> It is the part about how an identifier of type pointer is declared.
>>>> Other parts of the C++ standard define the results of operators on a
>>>> pointer.
>>>
>>> A pointer is defined as a compound type re 3.9.2:
>>>
>>> "3.9.2 Compound types [basic.compound]
>>> 1 Compound types can be constructed in the following ways:
>>> - arrays of objects of a given type, 8.3.4;
>>> - functions, which have parameters of given types and return void or
>>> references or objects of a given
>>> type, 8.3.5;
>>> - pointers to void or objects or functions (including static members of
>>> classes) of a given type, 8.3.1;"
>>>
>>> Note that pointer is in italics so it's defined here. 8.3.1 gives further
>>> information about the rules for declaring pointers but it doesn't define
>>> what a pointer is.
>>> The above defines a pointer to be a compund type.
>>>
>>> In the same section, re paragraph 3, there is further information on the
>>> definition of a pointer it begins:
>>> "3 A pointer to objects of type T is referred to as a "pointer to T.""
>>>
>>>
>>> So what does this mean....
>>> With the following two arrays(and pointers to them) examples:
>>> a) T* pT1 = new T[101];
>>> b) T (*pT2)[101] = (T (*)[101]) new T[101];
>>>
>>> Ok so pT1 and pT2 are both pointers to objects of type T but in a
>>> different
>>> way so lets see how this compares to the definiton in the C++ standard.
>>
>> No, pT1 and pT2 are not both pointers to objects of type T. pT1 is
>> a pointer to an object of type T. pT1 is initialized to the value of
>> the T* returned by new T[101]. pT2 is a pointer to an array of 101 T.
>> pT2 is initialized by an explicit type conversion that overrides the
>> type checking done by C++. A C++ implementation rejects the statement
>>
> Nonsense pT1 and pT2 both point to 101 int objects, they both point to
> exactly the same type of dynamically allocated memory.
pT1 and pT2 don't point to exactly the same type of thing. pT1
points to a T, the first sub-object in the array of 101 T dynamically
allocated by new T[101]. pT2 points to an array of 101 T. A T is
not the same as an array of 101 T.
>> T (*pT3)[101] = pT1;
>
> Only you are daft enough to assume this is possible without a cast.
There nothing daft about understanding that pT1 cannot be assigned
to pT3 because pT1, a pointer to T, is not a pointer to an array of
T, which is what pT3 is.
>> because a pointer to T is not a pointer to an array of T.
>>
>> The explicit type conversion may result in undefined behavoir, as in
>> dereferencing the pointer declared by the following statement.
>>
>> T (*pT4)[101] = (T (*)[101]) 37;
>>
>>> pT1 is a pointer to objects of type T and is referred to as a pointer to
>>> T.
>>> pT2 is a pointer to objects of type T(*)[101] and is referred to as a
>>> pointer to T(*)[101].
>>
>> The value of pT1 may validly be the address of a single object of type
>> T, not multiple objects of type T. The result of dereferencing pT1 is
>> a single object of type T, not multiple objects of type T. According
>> to the start of paragraph 1 of 5.3.1 (Unary operators):
>
> I just told you what the standard states. I repeat:
>
> pT1 is a pointer to objects of type T and is referred to as a pointer to T.
> pT2 is a pointer to objects of type T(*)[101] and is referred to as a
> pointer to T(*)[101].
> Are you dsisagreeing with this? Or are you trying to go off on a different
> direction and avoid the facts by blabbering on about the value of pT1 and
> pT2?
> Both pointers have the same value , the starting address of the array.
I'm not disagreeing with
pT1 is a pointer to objects of type T and is referred to as a
pointer to T. pT2 is a pointer to objects of type T(*)[101] and
is referred to as a pointer to T(*)[101].
Each is a pointers to objects in the sense that at different times
during the execution of a program each may validly point to different
objects of type T and T[101], respectively. At a given time, each
may validly point to a single object of type T and T[101],
respectively. At a given time, each does not point to multiple
objects.
In the example given, pT1 and pT2 do not have the same value; they
are initialized with separate new expressions. It is possible to
have both pT1 and pT2 refer to the same storage location. However,
even then both pointers would not have the same value because C++
pointers are typed and pT1 and pT2 have different types; C++
compilers reject the expression
pT1 == pT2
because pT1 and pT2 have different types.
>> 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.
>>
> It doesn't matter what the unary operator does. This does not define what a
> pointer is.
> Again you are taking stuff out of context.
It defines what the result of dereferencing a pointer is. What
happens when you dereference, or do another operation on, a pointer
is part of what a pointer is in C++.
[snip]
>>> Any argument that one is more correct than the other is nothing more than
>>> pedantic quibling over terminology, I maintain that the terminology I use
>>> is
>>> genrally accepted terminology and used all across many programming
>>> communities. Many programmers refer to pT1 as a pointer to an array,
>>> though
>>> it doesn't point to an array-object, it points to an array of T objects,
>>> BS
>>> included.
>>
>> The many programmers who refer to pT1 as a pointer to an array are
>> technically incorrect. Programmers dealing with C++ at the level
>> of detail of the C++ standard are careful about the details. Those
>> who understand C++ at the level of detail of the C++ standard are
>> less likely to be confused about what a pointer to an array is.
> Well the C++ standard and Bjarne Stroustrup are both techincally incorrect
> in your opinion.
No, that is not my opinion. What I wrote was: "The many programmers
who refer to pT1 as a pointer to an array are technically incorrect."
I did not write that the C++ standard and Bjarne Stroustrup are both
technically incorrect.
Exactly does C++ standard or Bjarne Stroustrup, when he writes
about the details, state that in the statement
T a[3], *p = a;
where T is a type, that p is a pointer to an array, rather than a
pointer to the first element of an array?
Later in this post is a quote from The C++ Programming Language by
Bjarne Stroustrup that I included in a previous post. Here is part
of the quote
The name of an array can be used as a pointer to its initial
element. For example:
int v[] = { 1, 2, 3, 4 };
int* p1 = v; // pointer to initial element (implicitly converted)
Note: the result of the name of an array as an expression is a
pointer to the initial element of the array, not a pointer to the
array.
> I'm sorry but I cannot accept your nonsense they are not techincally
> incorrect it is you who is incorrect because you do not understand the
> english language properly.
I never stated that they are not technically incorrect. What I wrote
was: "The many programmers who refer to pT1 as a pointer to an array
are technically incorrect."
I understand the English language properly enough to understand the
"are not technically incorrect" and "are technically incorrect" have
opposite meanings.
>> Exactly where does BS state than pT1 points to an array of T objects,
>> as opposed to being able to point to a T object that is an element
>> in an array of T? Here, again, is what Bjarne Stroustrup wrote in
>> The C++ Programming Language (page 91 of the Special Edition)
>>
> char* - pointer to a char or an array of char.
> http://www2.research.att.com/~bs/glossary.html
You omitted the rest of that glossary entry, which is: "Typically
assumed to point to a C-style string. Prefer a standard library
string over a C-style string when you can. TC++PL 2.3.3, 13.5.2."
The context of the glossary entry is about a C-style string. With a
C-style string the char* points to the first character of a zero
termainate array of characters. The glossary does not have a similar
entry for any other pointer type or for an array of objects in
general.
Instead of immediately replying with a partial quote of a glossary
entry, you should read the example from The C++ Programming Language
that I gave (it follows).
>> The name of an array can be used as a pointer to its initial
>> element. For example:
>>
>> int v[] = { 1, 2, 3, 4 };
>> int* p1 = v; // pointer to initial element (implicitly converted)
>> int* p2 = &v[0]; // pointer to initial element
>> int* p3 = &v[4]; // pointer to one beyond last element
>>
>> Note that each pointer is to an element in the array or one beyond
>> the last element, the pointers are not to the array. A pointer to
>> the array named v in the example would be:
>>
>> int (*p)[4] = &v;
[snip]
>> With
>>
>> int* p = new int[101];
>>
>> p points to an int, not to an array of int (the initialization
>> expression returns a pointer to int). What points to an array
>> of 101 int is a int(*)[101]. If you think that is nothing more than
>> pedantic quibling over terminology, say that and be done with it
>> (rather than flame by calling someone a "complete fucking idiot").
>
> Well TBH you are a fuckin idiot if you cannot see that 'p' points to more
> than one integer object.
What I am is someone who can discuss C++ without calling someone else
"a fuckin idiot".
At any given time during the execution of a program, p may validly
point to one int object. At different times p may validly point to
different objects.
Taking the use of italics in the C++ standard as indicating the
definition of a term, the term "point to" is defined (is in italics
in the C++ standard) in the following sentence from paragraph 3 of
3.9.2 (Compound types):
If an object of type T is located at an address A, a pointer of
type cv T* whose value is the address A is said to point to that
object, regardless of how the value was obtained.
Note that it "is said to point to that object" (singular).
>>> To suggest that this pointer does not point to an array because the
>>> standard
>>> states it will be referred to as "a pointer to integer" is complete
>>> nonsense. It points to an array of integer objects, therefore it's a
>>> pointer
>>> to an array of integer objects.
>>
>> You may consider what is in the C++ standard as complete nonsense. I
>> accept what is actually in the C++ standard as the definition of C++.
>
> I repeat my quote for you:
>
> "3 A pointer to objects of type T is referred to as a "pointer to T.""
>
> It says OBJECTS not single object. It is you who does not accept what the
> standard states. The standards support me not you.
It says "objects" because during the execution of a program a pointer
may point to different objects. At any one time a pointer may point
to a single object. The following sentence occurs later in the same
paragraph.
If an object of type T is located at an address A, a pointer of
type cv T* whose value is the address A is said to point to that
object, regardless of how the value was obtained.
Note that it "is said to point to that object" (singular). In the
C++ standard the term "point to" in that sentence is in italics,
making the sentence the definition of that term.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-06-22 00:29 +0100 |
| Message-ID | <5Q9Mp.6451$NX1.1550@newsfe18.ams2> |
| In reply to | #7027 |
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
news:slrnj01pa1.2ia2.aggedor@earl-grey.cloud9.net...
> On 2011-06-18, Paul <pchristor@yahoo.co.uk> wrote:
>>
> [snip]
>
>>> Every occurrence of the word "pointer" in the C++ standard specifies
>>> how an implementation of C++ is to treat a pointer in the context
>>> described by that part of the C++ standard. All those parts of the
>>> C++ standard taken together define what a pointer is in C++.
>>>
>> No it doesn't I can speak about C++ and use the term "pointer" to mean
>> Instruction pointer. The standard does not define the english langauge
>> nor
>> does it define programming terminology.
>> It defines a pointer ...drumroll.... where it is defined......... in
>> italics.
>
> If you use the term "instruction pointer", you are using a term that
> does not occur in the C++ standard. The C++ standard defines the C++
> programming language. Part of that definition is the results of
> operators, include operators on pointers.
>
No you don't get it. Anyone can use the term "pointer" in any context.
It does not have to be used in the same context as the C++ standard.
The C++ standard defines the term pointer, in the C++ langauge, where it is
in italics.
If the C++ standard were to use the term instruction pointer where "pointer"
was not in italics it does not mean this is another definition of the term
pointer.
> [snip]
>
>>>>> What is in 8.3.1 is part of the definition of what a pointer is in
>>>>> C++.
>>>>> It is the part about how an identifier of type pointer is declared.
>>>>> Other parts of the C++ standard define the results of operators on a
>>>>> pointer.
>>>>
>>>> A pointer is defined as a compound type re 3.9.2:
>>>>
>>>> "3.9.2 Compound types [basic.compound]
>>>> 1 Compound types can be constructed in the following ways:
>>>> - arrays of objects of a given type, 8.3.4;
>>>> - functions, which have parameters of given types and return void or
>>>> references or objects of a given
>>>> type, 8.3.5;
>>>> - pointers to void or objects or functions (including static members of
>>>> classes) of a given type, 8.3.1;"
>>>>
>>>> Note that pointer is in italics so it's defined here. 8.3.1 gives
>>>> further
>>>> information about the rules for declaring pointers but it doesn't
>>>> define
>>>> what a pointer is.
>>>> The above defines a pointer to be a compund type.
>>>>
>>>> In the same section, re paragraph 3, there is further information on
>>>> the
>>>> definition of a pointer it begins:
>>>> "3 A pointer to objects of type T is referred to as a "pointer to T.""
>>>>
>>>>
>>>> So what does this mean....
>>>> With the following two arrays(and pointers to them) examples:
>>>> a) T* pT1 = new T[101];
>>>> b) T (*pT2)[101] = (T (*)[101]) new T[101];
>>>>
>>>> Ok so pT1 and pT2 are both pointers to objects of type T but in a
>>>> different
>>>> way so lets see how this compares to the definiton in the C++ standard.
>>>
>>> No, pT1 and pT2 are not both pointers to objects of type T. pT1 is
>>> a pointer to an object of type T. pT1 is initialized to the value of
>>> the T* returned by new T[101]. pT2 is a pointer to an array of 101 T.
>>> pT2 is initialized by an explicit type conversion that overrides the
>>> type checking done by C++. A C++ implementation rejects the statement
>>>
>> Nonsense pT1 and pT2 both point to 101 int objects, they both point to
>> exactly the same type of dynamically allocated memory.
>
> pT1 and pT2 don't point to exactly the same type of thing. pT1
> points to a T, the first sub-object in the array of 101 T dynamically
> allocated by new T[101]. pT2 points to an array of 101 T. A T is
> not the same as an array of 101 T.
Nonsense pT1 points to an array of 101 ints , not just one single int.
And the following code proves this:
int offset = 77;
int x = *(pT1 + offset);
If pT1 pointed to only one single object this would cause a memory accesss
error but it doesn't because pT1 does point to 101 int objects.
Additionally if pT1 didn't point to the, lets say surplus, 100 in objects
then these are not aliased therefore why can't we refer to them with an
unrelated pointer without breaking strict aliasing rules?
>>> T (*pT3)[101] = pT1;
>>
>> Only you are daft enough to assume this is possible without a cast.
>
> There nothing daft about understanding that pT1 cannot be assigned
> to pT3 because pT1, a pointer to T, is not a pointer to an array of
> T, which is what pT3 is.
pT1 cannot be assigned to pT3 even if they were both null.
Its because they are different pointer types, not because of what they point
to.
>
>>> because a pointer to T is not a pointer to an array of T.
>>>
>>> The explicit type conversion may result in undefined behavoir, as in
>>> dereferencing the pointer declared by the following statement.
>>>
>>> T (*pT4)[101] = (T (*)[101]) 37;
>>>
>>>> pT1 is a pointer to objects of type T and is referred to as a pointer
>>>> to
>>>> T.
>>>> pT2 is a pointer to objects of type T(*)[101] and is referred to as a
>>>> pointer to T(*)[101].
>>>
>>> The value of pT1 may validly be the address of a single object of type
>>> T, not multiple objects of type T. The result of dereferencing pT1 is
>>> a single object of type T, not multiple objects of type T. According
>>> to the start of paragraph 1 of 5.3.1 (Unary operators):
>>
>> I just told you what the standard states. I repeat:
>>
>> pT1 is a pointer to objects of type T and is referred to as a pointer to
>> T.
>> pT2 is a pointer to objects of type T(*)[101] and is referred to as a
>> pointer to T(*)[101].
>> Are you dsisagreeing with this? Or are you trying to go off on a
>> different
>> direction and avoid the facts by blabbering on about the value of pT1 and
>> pT2?
>> Both pointers have the same value , the starting address of the array.
>
> I'm not disagreeing with
>
> pT1 is a pointer to objects of type T and is referred to as a
> pointer to T. pT2 is a pointer to objects of type T(*)[101] and
> is referred to as a pointer to T(*)[101].
You are disagreeing with this, you keep repeating that pT1 points to only
one single int , which is obvioulsy in direct disagreement with the C++
standard which clearly implies that pT1 can point to objects(plural).
.
>
> Each is a pointers to objects in the sense that at different times
> during the execution of a program each may validly point to different
> objects of type T and T[101], respectively. At a given time, each
> may validly point to a single object of type T and T[101],
> respectively. At a given time, each does not point to multiple
> objects.
With the expression:
*(pT1 + offset);
pT1 is a pointer to the beginning of the array, not just one element. The
offset is the pointer to each single element.
pT1 points to integer objects, not just one single integer object, whether
it's simultaneously or not.
>
> In the example given, pT1 and pT2 do not have the same value; they
> are initialized with separate new expressions. It is possible to
> have both pT1 and pT2 refer to the same storage location. However,
> even then both pointers would not have the same value because C++
> pointers are typed and pT1 and pT2 have different types; C++
> compilers reject the expression
>
> pT1 == pT2
>
> because pT1 and pT2 have different types.
As I said before only you are daft enough to not realise that the pointers
have a different type. The fact that you cannot assign one to the other,
without a cast, does not prove what they do or do not point to.
>
>>> 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.
>>>
>> It doesn't matter what the unary operator does. This does not define what
>> a
>> pointer is.
>> Again you are taking stuff out of context.
>
> It defines what the result of dereferencing a pointer is. What
> happens when you dereference, or do another operation on, a pointer
> is part of what a pointer is in C++.
And what is the result of the following derefernece?
*(p + offset);
Dereference a pointer expression and you access the array of integer
objects, because the pointer points to an array of int objects.
>
> [snip]
>
>>>> Any argument that one is more correct than the other is nothing more
>>>> than
>>>> pedantic quibling over terminology, I maintain that the terminology I
>>>> use
>>>> is
>>>> genrally accepted terminology and used all across many programming
>>>> communities. Many programmers refer to pT1 as a pointer to an array,
>>>> though
>>>> it doesn't point to an array-object, it points to an array of T
>>>> objects,
>>>> BS
>>>> included.
>>>
>>> The many programmers who refer to pT1 as a pointer to an array are
>>> technically incorrect. Programmers dealing with C++ at the level
>>> of detail of the C++ standard are careful about the details. Those
>>> who understand C++ at the level of detail of the C++ standard are
>>> less likely to be confused about what a pointer to an array is.
>> Well the C++ standard and Bjarne Stroustrup are both techincally
>> incorrect
>> in your opinion.
>
> No, that is not my opinion. What I wrote was: "The many programmers
> who refer to pT1 as a pointer to an array are technically incorrect."
> I did not write that the C++ standard and Bjarne Stroustrup are both
> technically incorrect.
Well clearly the C++ standard states that pointer of type T can point to T
objects(plural).
And clearly BS thinks that a char* can point to an array of chars.
Your argument is in direct opposition to these opinions..
>
> Exactly does C++ standard or Bjarne Stroustrup, when he writes
> about the details, state that in the statement
>
> T a[3], *p = a;
>
> where T is a type, that p is a pointer to an array, rather than a
> pointer to the first element of an array?
>
> Later in this post is a quote from The C++ Programming Language by
> Bjarne Stroustrup that I included in a previous post. Here is part
> of the quote
>
> The name of an array can be used as a pointer to its initial
> element. For example:
>
> int v[] = { 1, 2, 3, 4 };
> int* p1 = v; // pointer to initial element (implicitly converted)
>
> Note: the result of the name of an array as an expression is a
> pointer to the initial element of the array, not a pointer to the
> array.
Where does your quote start and end?
Is the above Note added by you or is that part of the quote from BS?
>
>> I'm sorry but I cannot accept your nonsense they are not techincally
>> incorrect it is you who is incorrect because you do not understand the
>> english language properly.
>
> I never stated that they are not technically incorrect. What I wrote
> was: "The many programmers who refer to pT1 as a pointer to an array
> are technically incorrect."
>
> I understand the English language properly enough to understand the
> "are not technically incorrect" and "are technically incorrect" have
> opposite meanings.
But you don't understand that objects(plural) means more than one object,
which is not the same as one single object.
>
>>> Exactly where does BS state than pT1 points to an array of T objects,
>>> as opposed to being able to point to a T object that is an element
>>> in an array of T? Here, again, is what Bjarne Stroustrup wrote in
>>> The C++ Programming Language (page 91 of the Special Edition)
>>>
>> char* - pointer to a char or an array of char.
>> http://www2.research.att.com/~bs/glossary.html
>
> You omitted the rest of that glossary entry, which is: "Typically
> assumed to point to a C-style string. Prefer a standard library
> string over a C-style string when you can. TC++PL 2.3.3, 13.5.2."
But that makes no difference to what he has stated. The important part which
I have quoted is terminated with a full stop and it is a complete statement
in itself.
You disagree with this statement and you disagree with Bjarne.
>
> The context of the glossary entry is about a C-style string. With a
> C-style string the char* points to the first character of a zero
> termainate array of characters. The glossary does not have a similar
> entry for any other pointer type or for an array of objects in
> general.
Are you saying that a char* can or cannot point to an array of char objects?
Now you seem to be of the opinion that its ok for char* to point to an array
of chars but no other types is that it?
You don't seem to know what you are talking about now and have no clarity in
your words.
Are you now trying to twist and manipulate context and meaning of words to
wangle out of what seems to be you in direct disagreement with BS?
>
> Instead of immediately replying with a partial quote of a glossary
> entry, you should read the example from The C++ Programming Language
> that I gave (it follows).
The quote from the glossary is in complete agreement with the C++ standards
definition , and it is in complete agree with me.
It is in complete disagreement with you. Can you explain why you refuse to
accept the facts presented?
>
>>> The name of an array can be used as a pointer to its initial
>>> element. For example:
>>>
>>> int v[] = { 1, 2, 3, 4 };
>>> int* p1 = v; // pointer to initial element (implicitly converted)
>>> int* p2 = &v[0]; // pointer to initial element
>>> int* p3 = &v[4]; // pointer to one beyond last element
>>>
>>> Note that each pointer is to an element in the array or one beyond
>>> the last element, the pointers are not to the array. A pointer to
>>> the array named v in the example would be:
>>>
>>> int (*p)[4] = &v;
>
> [snip]
>
>>> With
>>>
>>> int* p = new int[101];
>>>
>>> p points to an int, not to an array of int (the initialization
>>> expression returns a pointer to int). What points to an array
>>> of 101 int is a int(*)[101]. If you think that is nothing more than
>>> pedantic quibling over terminology, say that and be done with it
>>> (rather than flame by calling someone a "complete fucking idiot").
>>
>> Well TBH you are a fuckin idiot if you cannot see that 'p' points to more
>> than one integer object.
>
> What I am is someone who can discuss C++ without calling someone else
> "a fuckin idiot".
And you have a problem with the term "fucking idiot"?
>
> At any given time during the execution of a program, p may validly
> point to one int object. At different times p may validly point to
> different objects.
Sorry the standard disagrees, the standard states that a pointer can point
to objects(plural).
And Bjarne Stroustrup disagrees too.
>
> Taking the use of italics in the C++ standard as indicating the
> definition of a term, the term "point to" is defined (is in italics
> in the C++ standard) in the following sentence from paragraph 3 of
> 3.9.2 (Compound types):
>
> If an object of type T is located at an address A, a pointer of
> type cv T* whose value is the address A is said to point to that
> object, regardless of how the value was obtained.
>
> Note that it "is said to point to that object" (singular).
>
>>>> To suggest that this pointer does not point to an array because the
>>>> standard
>>>> states it will be referred to as "a pointer to integer" is complete
>>>> nonsense. It points to an array of integer objects, therefore it's a
>>>> pointer
>>>> to an array of integer objects.
>>>
>>> You may consider what is in the C++ standard as complete nonsense. I
>>> accept what is actually in the C++ standard as the definition of C++.
>>
>> I repeat my quote for you:
>>
>> "3 A pointer to objects of type T is referred to as a "pointer to T.""
>>
>> It says OBJECTS not single object. It is you who does not accept what the
>> standard states. The standards support me not you.
>
> It says "objects" because during the execution of a program a pointer
> may point to different objects. At any one time a pointer may point
> to a single object. The following sentence occurs later in the same
> paragraph.
No the pointer can point to objects(plural). It doesn't matter about fucking
time the standard does not mention time.
You say "at any one time a pointer may point to a single object" but you are
speaking nonsense.
>
> If an object of type T is located at an address A, a pointer of
> type cv T* whose value is the address A is said to point to that
> object, regardless of how the value was obtained.
>
> Note that it "is said to point to that object" (singular). In the
> C++ standard the term "point to" in that sentence is in italics,
> making the sentence the definition of that term.
This obviously assumes that the people who are reading it are intelligent
enough to understand this in conjunction with the intitial sentence:
"3 A pointer to objects of type T is referred to as a "pointer to T.""
Are you suggesting that this somehow implies that the above quote is
incorrect?
Don't be so stupid use some common sense and understand the context.
.
[toc] | [prev] | [next] | [standalone]
| From | Keith H Duggar <duggar@alum.mit.edu> |
|---|---|
| Date | 2011-06-18 12:58 -0700 |
| Message-ID | <4ae9348d-66bb-4b70-9934-6c4ed7101147@t7g2000vbv.googlegroups.com> |
| In reply to | #6886 |
On Jun 18, 1:23 pm, "A. Bolmarcich" <agge...@earl-grey.cloud9.net> wrote: > You may consider what is in the C++ standard as complete nonsense.  I > accept what is actually in the C++ standard as the definition of C++. Oh really? Then it's case closed; you are wrong: 24.2.1 5 Just as a regular /pointer to an array/ guarantees that there is a pointer value pointing past the last element of the array, so for any iterator type there is an iterator value that points past the last element of a corresponding sequence. 27.7.5 ... template <class charT> unspecified get_time(struct tm* tmb, const charT* fmt); 7 Requires: The argument tmb shall be a valid pointer to an object of type struct tm, and the argument fmt shall be a valid /pointer to an array/ of objects of type charT with char_traits<charT>::length(fmt) elements. ... template <class charT> unspecified put_time(const struct tm* tmb, const charT* fmt); 9 Requires: The argument tmb shall be a valid pointer to an object of type struct tm, and the argument fmt shall be a valid /pointer to an array/ of objects of type charT with char_traits<charT>::length(fmt) elements. Note /pointer to an array/ verbatim exactly as Paul uses it. KHD
[toc] | [prev] | [next] | [standalone]
| From | "A. Bolmarcich" <aggedor@earl-grey.cloud9.net> |
|---|---|
| Date | 2011-06-21 13:40 -0500 |
| Message-ID | <slrnj01pcg.2ia2.aggedor@earl-grey.cloud9.net> |
| In reply to | #6895 |
On 2011-06-18, Keith H Duggar <duggar@alum.mit.edu> wrote:
> On Jun 18, 1:23¬?pm, "A. Bolmarcich" <agge...@earl-grey.cloud9.net>
> wrote:
>> You may consider what is in the C++ standard as complete nonsense. ¬?I
>> accept what is actually in the C++ standard as the definition of C++.
>
> Oh really? Then it's case closed; you are wrong:
>
> 24.2.1
> 5 Just as a regular /pointer to an array/ guarantees that there
> is a pointer value pointing past the last element of the array,
> so for any iterator type there is an iterator value that points
> past the last element of a corresponding sequence.
The C++ standard (ISO/IEC 14882:2003(E)) does not have a section
24.2.1. Section 24.2 is Header <iterator> synopsis; it does not
have any subsections.
What is guaranteed is a pointer value pointing past the last element
of the array. Given the declarations
int arr[4], (*parr)[4] = &arr;
parr+1 is a pointer value pointing past the last element of the
array named arr.
> 27.7.5
> ...
> template <class charT> unspecified get_time(struct tm* tmb, const
> charT* fmt);
>
> 7 Requires: The argument tmb shall be a valid pointer to an
> object of type struct tm, and the argument fmt shall be a valid
> /pointer to an array/ of objects of type charT with
> char_traits<charT>::length(fmt) elements.
>
> ...
>
> template <class charT> unspecified put_time(const struct tm* tmb,
> const charT* fmt);
>
> 9 Requires: The argument tmb shall be a valid pointer to an
> object of type struct tm, and the argument fmt shall be a valid
> /pointer to an array/ of objects of type charT with
> char_traits<charT>::length(fmt) elements.
>
> Note /pointer to an array/ verbatim exactly as Paul uses it.
27.7.5 of the C++ standard (ISO/IEC 14882:2003(E)) is
27.7.5 basic_stringstream constructors [lib.stringstream.cons]
explicit basic_stringstream(
ios_base::openmode which = ios_base::out|ios_base::in);
1 Effects: Constructs an object of class basic_stringstream<
charT,traits>, initializing the base class with
basic_iostream(&sb) and initializing sb with
basic_stringbuf<charT,traits,Allocator>(which).
explicit basic_stringstream(
const basic_string<charT,traits,Allocator>& str,
ios_base::openmode which = ios_base::out|ios_base::in);
2 Effects: Constructs an object of class
basic_stringstream<charT,traits>, initializing the base class
with basic_iostream(&sb) and initializing sb with
basic_stringbuf<charT,traits,Allocator>(str,which).
No "/pointer to an array/" here.
The quotes you gave may be from a draft. It would be unfortunate
if an approved standard used terms as similar as
- pointer to array
- pointer to an array
for pointers different enough that they cannot be compared for
equality. A slightly longer and more distinct alternative for
the latter term is: "pointer to an array element".
[toc] | [prev] | [next] | [standalone]
| From | Joshua Maurice <joshuamaurice@gmail.com> |
|---|---|
| Date | 2011-05-10 15:56 -0700 |
| Message-ID | <53bd878f-c18b-476f-ae00-e4fc0a1fa7b1@s41g2000prb.googlegroups.com> |
| In reply to | #4870 |
On May 10, 10:31 am, "A. Bolmarcich" <agge...@earl-grey.cloud9.net> wrote: [snip] This is for your benefit A. Bolmarcich. I don't think you'll get anywhere, but to lessen your pain and suffering, let me take a stab at where Paul is coming from so that you might understand. For nearly all of the programming world, we recognize a few thinks that Paul does not. Note that these are almost purely definitional, which means that you cannot "prove" Paul wrong with evidence or a scientific argument. Instead, Paul is wrong by definition. Arguments over definition tend to devolve down into usually not interesting or convincing arguments IMHO. Either it's clear cut enough that the correct answer is obvious, such as in this case, or it's ambiguous enough that you're better off just getting a temporary consensus on usable terms for the duration of the conversation. Lots of the recent inane arguments have been because you both have been arguing with your own particular definitions of the words which are not shared by your opponent. Thus, the conversation is as if one is yelling in French and the other in traditional Chinese. It won't get very far unless and until you agree upon some definitions for the terms involved, and any future discussion should be framed in that regard. 1- An array is an object. The elements of an array are sub-objects of the array. "new int[2]" creates 1 array object, which has 2 sub- objects of type int. Thus 3 objects in total. Paul will dispute this. GL there. If I were to try arguing with him, I would start here. 2- A. Bolmarcich wants to narrowly define "accessing the array" as an expression of array type which refers to the array, or some such. Paul wants to narrowly define "accessing the array" as an expression of the element type of the array which refers to an element of the array, or some such. IMHO, I think both are accepted usage of language, that is I don't think there's such a clear cut definition of "access" in usage, so GL to both of you. 3- Paul is making some sort of distinction between "an array object" and "an array-type object". At least, I think he is, or something. It's really quite hard to follow because he has never defined those terms, and because he's wrong insofaras that's how /anyone/ else uses those words. I've been trying to figure out exactly what he means, but it's difficult to pierce his terminology.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-05-11 12:25 +1200 |
| Message-ID | <92u3biF51qU4@mid.individual.net> |
| In reply to | #4877 |
On 05/11/11 10:56 AM, Joshua Maurice wrote:
> On May 10, 10:31 am, "A. Bolmarcich"<agge...@earl-grey.cloud9.net>
> wrote:
> [snip]
>
> This is for your benefit A. Bolmarcich. I don't think you'll get
> anywhere, but to lessen your pain and suffering, let me take a stab at
> where Paul is coming from so that you might understand.
>
> For nearly all of the programming world, we recognize a few thinks
> that Paul does not. Note that these are almost purely definitional,
> which means that you cannot "prove" Paul wrong with evidence or a
> scientific argument. Instead, Paul is wrong by definition. Arguments
> over definition tend to devolve down into usually not interesting or
> convincing arguments IMHO. Either it's clear cut enough that the
> correct answer is obvious, such as in this case, or it's ambiguous
> enough that you're better off just getting a temporary consensus on
> usable terms for the duration of the conversation.
The part of his argument that baffles me is he accepts that given
int arr[40] = {0};
int (*pparr)[40] = &arr;
typeid(arr) == typeid(*pparr)
but refuses to accept they access the array in the same way.
Well odd.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
Page 20 of 21 — ← Prev page 1 … 18 19 [20] 21 Next page →
Back to top | Article view | comp.lang.c++
csiph-web