Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #2801 > unrolled thread
| Started by | Goran <goran.pusic@gmail.com> |
|---|---|
| First post | 2011-03-29 10:27 -0700 |
| Last post | 2011-03-31 23:08 +0000 |
| Articles | 20 on this page of 196 — 15 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: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-03-29 10:27 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-29 23:32 +0100
Re: delete[] p or delete[] *p Kai-Uwe Bux <jkherciueh@gmx.net> - 2011-03-30 01:53 +0200
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-30 03:55 +0100
Re: delete[] p or delete[] *p Kai-Uwe Bux <jkherciueh@gmx.net> - 2011-03-30 09:52 +0200
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-30 11:44 +0100
Re: delete[] p or delete[] *p Kai-Uwe Bux <jkherciueh@gmx.net> - 2011-03-30 19:44 +0200
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-30 20:18 +0100
Re: delete[] p or delete[] *p cg_chas <cg_chas@hotmail.com> - 2011-03-30 04:30 -0400
Re: delete[] p or delete[] *p Kai-Uwe Bux <jkherciueh@gmx.net> - 2011-03-30 10:33 +0200
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-30 11:39 +0100
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-30 15:38 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-03-30 16:14 +0100
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-30 18:06 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-03-30 18:15 +0100
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-30 18:22 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-03-30 18:38 +0100
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-31 00:42 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-03-31 00:52 +0100
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-31 02:22 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-03-30 23:44 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-31 10:52 +0100
Re: delete[] p or delete[] *p cg_chas <cg_chas@hotmail.com> - 2011-03-31 06:13 -0400
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-03-31 04:00 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-31 14:14 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-03-31 07:01 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-31 15:55 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-03-31 08:10 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-31 18:20 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-01 01:14 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-01 11:53 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-01 05:11 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-01 15:32 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-01 11:24 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-02 01:55 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-02 23:32 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-03 13:21 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-04 02:47 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-04 13:33 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-04 11:06 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-04 20:17 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-05 05:00 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-05 15:59 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-06 03:08 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-06 16:24 +0100
Re: delete[] p or delete[] *p boltar2003@boltar.world - 2011-04-06 15:36 +0000
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-06 10:23 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-06 18:53 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-04-06 19:01 +0100
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-06 19:24 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-04-06 19:30 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-06 11:53 -0700
Re: delete[] p or delete[] *p cg_chas <cg_chas@hotmail.com> - 2011-04-06 17:31 -0400
Re: delete[] p or delete[] *p Ian Collins <ian-news@hotmail.com> - 2011-04-07 09:47 +1200
Re: delete[] p or delete[] *p Joshua Maurice <joshuamaurice@gmail.com> - 2011-04-06 15:14 -0700
Re: delete[] p or delete[] *p Joshua Maurice <joshuamaurice@gmail.com> - 2011-04-06 15:15 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-06 23:13 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-06 23:35 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-07 14:20 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-07 12:56 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-07 21:47 +0100
Re: delete[] p or delete[] *p Lasse Reichstein Nielsen <lrn.unread@gmail.com> - 2011-04-08 06:54 +0200
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-08 08:45 +0100
Re: delete[] p or delete[] *p Lasse Reichstein Nielsen <lrn.unread@gmail.com> - 2011-04-08 18:01 +0200
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-08 18:09 +0100
Re: delete[] p or delete[] *p Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-08 20:25 +0200
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-08 19:45 +0100
Re: delete[] p or delete[] *p Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-08 21:14 +0200
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-08 21:08 +0100
Re: delete[] p or delete[] *p Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-04-08 22:52 +0200
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-08 00:52 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-08 09:06 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-08 07:53 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-08 18:12 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-04-08 18:22 +0100
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-08 19:51 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-04-08 19:54 +0100
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-08 21:10 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-10 23:44 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-11 12:40 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-11 04:53 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-11 14:05 +0100
Re: delete[] p or delete[] *p gwowen <gwowen@gmail.com> - 2011-04-11 06:20 -0700
Re: delete[] p or delete[] *p Goran Pusic <goranp@cse-semaphore.com> - 2011-04-11 07:33 -0700
Re: delete[] p or delete[] *p cg_chas <cg_chas@hotmail.com> - 2011-04-11 11:42 -0400
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-11 17:56 +0100
Re: delete[] p or delete[] *p cg_chas <cg_chas@hotmail.com> - 2011-04-11 13:16 -0400
Re: delete[] p or delete[] *p Ian Collins <ian-news@hotmail.com> - 2011-04-12 08:09 +1200
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-12 00:19 -0700
Re: delete[] p or delete[] *p SG <s.gesemann@gmail.com> - 2011-04-12 04:04 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 13:49 +0100
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 13:41 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-12 06:48 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-12 17:20 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-12 23:43 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-13 11:24 +0100
Re: delete[] p or delete[] *p cg_chas <cg_chas@hotmail.com> - 2011-04-13 07:13 -0400
Re: delete[] p or delete[] *p cg_chas <cg_chas@hotmail.com> - 2011-04-13 07:19 -0400
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-13 08:31 -0700
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-13 23:30 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-14 13:50 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-14 07:28 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-14 16:26 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-04-14 18:02 +0100
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-14 19:08 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-04-14 19:45 +0100
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-14 20:55 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-04-14 21:10 +0100
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-14 23:04 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-04-14 23:24 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-04-14 23:31 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-04-14 23:33 +0100
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 01:28 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-04-15 13:31 +0100
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 14:24 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-04-15 14:34 +0100
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 14:49 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-04-15 14:58 +0100
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 16:43 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-04-15 17:52 +0100
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 18:55 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-04-15 19:28 +0100
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 19:43 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-04-15 19:55 +0100
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 22:19 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-04-15 22:27 +0100
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 22:53 +0100
Re: delete[] p or delete[] *p crisgoogle <crisd@telus.net> - 2011-04-14 15:28 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 01:11 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-15 01:35 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 12:24 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-15 05:06 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 13:19 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-15 06:37 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 14:52 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-15 06:54 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 16:45 +0100
Re: delete[] p or delete[] *p gwowen <gwowen@gmail.com> - 2011-04-15 05:56 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 14:30 +0100
Re: delete[] p or delete[] *p Ian Collins <ian-news@hotmail.com> - 2011-04-15 10:44 +1200
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 00:14 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-15 01:22 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 12:35 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-15 05:05 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 13:26 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-15 06:35 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-15 16:48 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-17 08:50 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-17 18:28 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-19 01:16 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-19 11:42 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-19 05:02 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-20 16:29 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-21 05:09 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-21 18:24 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-21 23:23 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-22 09:34 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-01 05:36 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-04-01 12:52 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-04-01 05:46 -0700
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-03-31 07:21 -0700
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-03-31 13:04 +0100
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-31 14:16 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-03-31 14:26 +0100
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-31 14:37 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-03-31 14:44 +0100
Re: delete[] p or delete[] *p cg_chas <cg_chas@hotmail.com> - 2011-03-30 16:04 -0400
Re: delete[] p or delete[] *p Joshua Maurice <joshuamaurice@gmail.com> - 2011-03-30 14:04 -0700
Re: delete[] p or delete[] *p Kai-Uwe Bux <jkherciueh@gmx.net> - 2011-03-30 20:02 +0200
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-30 20:21 +0100
Re: delete[] p or delete[] *p cg_chas <cg_chas@hotmail.com> - 2011-03-30 15:47 -0400
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-03-30 00:12 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-30 11:36 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-03-30 05:26 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-30 13:41 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-03-30 06:28 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-30 15:00 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-03-30 07:47 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-30 18:14 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-03-30 10:33 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-30 20:24 +0100
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-03-30 23:31 -0700
Re: delete[] p or delete[] *p SG <s.gesemann@gmail.com> - 2011-03-31 04:46 -0700
Re: delete[] p or delete[] *p Goran <goran.pusic@gmail.com> - 2011-03-31 05:16 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-31 14:28 +0100
Re: delete[] p or delete[] *p SG <s.gesemann@gmail.com> - 2011-03-31 09:01 -0700
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-31 18:23 +0100
Re: delete[] p or delete[] *p Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-03-31 21:32 +0200
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-03-31 20:37 +0100
Re: delete[] p or delete[] *p cg_chas <cg_chas@hotmail.com> - 2011-03-31 16:13 -0400
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-31 21:28 +0100
Re: delete[] p or delete[] *p Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2011-03-31 22:55 +0200
Re: delete[] p or delete[] *p "Paul" <pchristor@yahoo.co.uk> - 2011-03-31 23:06 +0100
Re: delete[] p or delete[] *p Leigh Johnston <leigh@i42.co.uk> - 2011-03-31 23:43 +0100
Re: delete[] p or delete[] *p Ian Collins <ian-news@hotmail.com> - 2011-04-01 12:12 +1300
Re: delete[] p or delete[] *p drew@furrfu.invalid (Drew Lawson) - 2011-03-31 23:08 +0000
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-04-11 04:53 -0700 |
| Message-ID | <04718043-b351-42da-9deb-5aa1c652bcec@hd10g2000vbb.googlegroups.com> |
| In reply to | #3400 |
On Apr 11, 1:40 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> No, it's clear enough, and you are lying when saying it's not. If you
> say that pointer of type "T*" (somehow, sometime, whatever) points to
> an __array__ of T, then simplest of pointer operations (indexing,
> incrementing) are broken.
>
> Since pointer operations clearly aren't broken, your claim is false.
>
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> What is broken about indexing and incrementing?
int a[2][2]={1,2,3,4};
int* p1 = a[0]; // p1 points to an array (your claim).
p1++;
if (*p1 != a[1])
std::cout << "incrementing is broken.";
int* p2 = a[0]; // p2 points to an array (your claim).
if (*p2[1] != a[1])
std::cout << "indexing is broken.";
Goran.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-11 14:05 +0100 |
| Message-ID | <P0Dop.3813$Pi.1062@newsfe22.ams2> |
| In reply to | #3401 |
"Goran" <goran.pusic@gmail.com> wrote in message
news:04718043-b351-42da-9deb-5aa1c652bcec@hd10g2000vbb.googlegroups.com...
On Apr 11, 1:40 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> No, it's clear enough, and you are lying when saying it's not. If you
> say that pointer of type "T*" (somehow, sometime, whatever) points to
> an __array__ of T, then simplest of pointer operations (indexing,
> incrementing) are broken.
>
> Since pointer operations clearly aren't broken, your claim is false.
>
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> What is broken about indexing and incrementing?
int a[2][2]={1,2,3,4};
int* p1 = a[0]; // p1 points to an array (your claim).
p1++;
if (*p1 != a[1])
std::cout << "incrementing is broken.";
int* p2 = a[0]; // p2 points to an array (your claim).
if (*p2[1] != a[1])
std::cout << "indexing is broken.";
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
You create a 2d array, then you create a pointer to a 1d-subarray of this 2d
array.
Then after that I don't know what you are trying to do. You say its broken
but you don't say what you expect it to do.
It looks like you increment the pointer to the 1d-subarray and expect it to
increment the 2d array , or something stupid like that. But surely you can't
be that stupid?
What exactly is your code trying to do?
[toc] | [prev] | [next] | [standalone]
| From | gwowen <gwowen@gmail.com> |
|---|---|
| Date | 2011-04-11 06:20 -0700 |
| Message-ID | <d0d82597-66aa-476a-8bd7-c84b9a4e871c@e8g2000vbz.googlegroups.com> |
| In reply to | #3402 |
On Apr 11, 2:05 pm, "Paul" <pchris...@yahoo.co.uk> wrote: > You create a 2d array, then you create a pointer to a 1d-subarray of this 2d > array. (Specifically, the first 1d-subarray.) > Then after that I don't know what you are trying to do. He's trying to increment the pointer to the FIRST 1d-subarray, in the expectation that doing so will cause it to point to the SECOND 1d- subarray. Do *you* think this should work?
[toc] | [prev] | [next] | [standalone]
| From | Goran Pusic <goranp@cse-semaphore.com> |
|---|---|
| Date | 2011-04-11 07:33 -0700 |
| Message-ID | <a89688fc-d716-47a5-98e1-feae2fde3ea2@l30g2000vbn.googlegroups.com> |
| In reply to | #3402 |
On Apr 11, 3:05 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Goran" <goran.pu...@gmail.com> wrote in message
>
> news:04718043-b351-42da-9deb-5aa1c652bcec@hd10g2000vbb.googlegroups.com...
> On Apr 11, 1:40 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
> > No, it's clear enough, and you are lying when saying it's not. If you
> > say that pointer of type "T*" (somehow, sometime, whatever) points to
> > an __array__ of T, then simplest of pointer operations (indexing,
> > incrementing) are broken.
>
> > Since pointer operations clearly aren't broken, your claim is false.
>
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > What is broken about indexing and incrementing?
>
> int a[2][2]={1,2,3,4};
> int* p1 = a[0]; // p1 points to an array (your claim).
> p1++;
> if (*p1 != a[1])
> std::cout << "incrementing is broken.";
> int* p2 = a[0]; // p2 points to an array (your claim).
> if (*p2[1] != a[1])
> std::cout << "indexing is broken.";
>
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> You create a 2d array, then you create a pointer to a 1d-subarray of this 2d
> array.
> Then after that I don't know what you are trying to do. You say its broken
> but you don't say what you expect it to do.
I expect both pointers to point to a[1]. This is because you say that
they point to one array (a[0]), and I know that incrementing, or
indexing pointers with 1, must make them point to next element. Thats
a[1]. This is how pointers work. Explain why this doesn't happen.
Goran.
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2011-04-11 11:42 -0400 |
| Message-ID | <8576q653nkuj7fl3pl5qt68bk4at7ecr1v@4ax.com> |
| In reply to | #3404 |
On Mon, 11 Apr 2011 07:33:11 -0700 (PDT), Goran Pusic <goranp@cse-semaphore.com>
wrote:
>On Apr 11, 3:05 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>> "Goran" <goran.pu...@gmail.com> wrote in message
>>
>> news:04718043-b351-42da-9deb-5aa1c652bcec@hd10g2000vbb.googlegroups.com...
>> On Apr 11, 1:40 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>>
>> > No, it's clear enough, and you are lying when saying it's not. If you
>> > say that pointer of type "T*" (somehow, sometime, whatever) points to
>> > an __array__ of T, then simplest of pointer operations (indexing,
>> > incrementing) are broken.
>>
>> > Since pointer operations clearly aren't broken, your claim is false.
>>
>> > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> > What is broken about indexing and incrementing?
>>
>> int a[2][2]={1,2,3,4};
>> int* p1 = a[0]; // p1 points to an array (your claim).
>> p1++;
>> if (*p1 != a[1])
>> std::cout << "incrementing is broken.";
>> int* p2 = a[0]; // p2 points to an array (your claim).
>> if (*p2[1] != a[1])
>> std::cout << "indexing is broken.";
>>
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>
>> You create a 2d array, then you create a pointer to a 1d-subarray of this 2d
>> array.
>> Then after that I don't know what you are trying to do. You say its broken
>> but you don't say what you expect it to do.
>
>I expect both pointers to point to a[1]. This is because you say that
>they point to one array (a[0]), and I know that incrementing, or
>indexing pointers with 1, must make them point to next element. Thats
>a[1]. This is how pointers work. Explain why this doesn't happen.
>
>Goran.
Goran,
I am seeing some oddities with your example. I agree with what I believe your
point is, but I think the "if" expressions may perhaps not be what you're trying
to express.
consider:
if (*p1 != a[1])
You are attempting to compare a dereferenced pointer (an int value) with an
array type. This should not even compile imo.
Now if you meant to say:
if (*p1 != a[0][1])
similarly:
if (p1 != &(a[0][1]))
then i think the test is valid.
As a side note:
The 2-dimensional array example isn't even necessary.
A 1-dimensional array is more than sufficient to make the case for how many
bytes are incremented by incrementing the pointer.
int a[4] = {1,2,3,4}; // a is an array
int* p1 = a; // a is still an array and Paul thinks p1 points to an array
int* p2 = p1; // p1's value is stored in p2
++p1; // p1 is incremented
std::cout << sizeof(int[4]) << std::endl; // size of our array in bytes
std::cout << sizeof(p1-p2) << std::endl; // bytes between p1 and p2
output:
16
4
on my machine, a is a 16-byte array
we store the address of p1 in p2
we then increment p1 by 1
the bytes jumped on my machine is 4
the sizeof(int) on my machine is 4
if p1 pointed to an array instead of an int, then the difference between p1 and
p2 would be 16, not 4.
p1 irrefutably points to an int element, not the array.
(this is the part where Paul is backed into a wall logicall and starts calling
everybody an idiot)
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-11 17:56 +0100 |
| Message-ID | <9pGop.51037$7u3.18362@newsfe04.ams2> |
| In reply to | #3404 |
"Goran Pusic" <goranp@cse-semaphore.com> wrote in message
news:a89688fc-d716-47a5-98e1-feae2fde3ea2@l30g2000vbn.googlegroups.com...
On Apr 11, 3:05 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Goran" <goran.pu...@gmail.com> wrote in message
>
> news:04718043-b351-42da-9deb-5aa1c652bcec@hd10g2000vbb.googlegroups.com...
> On Apr 11, 1:40 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
> > No, it's clear enough, and you are lying when saying it's not. If you
> > say that pointer of type "T*" (somehow, sometime, whatever) points to
> > an __array__ of T, then simplest of pointer operations (indexing,
> > incrementing) are broken.
>
> > Since pointer operations clearly aren't broken, your claim is false.
>
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > What is broken about indexing and incrementing?
>
> int a[2][2]={1,2,3,4};
> int* p1 = a[0]; // p1 points to an array (your claim).
> p1++;
> if (*p1 != a[1])
> std::cout << "incrementing is broken.";
> int* p2 = a[0]; // p2 points to an array (your claim).
> if (*p2[1] != a[1])
> std::cout << "indexing is broken.";
>
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> You create a 2d array, then you create a pointer to a 1d-subarray of this
> 2d
> array.
> Then after that I don't know what you are trying to do. You say its broken
> but you don't say what you expect it to do.
I expect both pointers to point to a[1]. This is because you say that
they point to one array (a[0]), and I know that incrementing, or
indexing pointers with 1, must make them point to next element. Thats
a[1]. This is how pointers work. Explain why this doesn't happen.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Incrementing it will make it point to a[0][1] becuase you increment a
pointer to a 1d array. If you want to make it point to a[1][0] then you must
use a pointer to a 2d array like so:
int (*p)[2] = a;
p++;
/*now p points to a[1][0]*/
I don't see what you find so difficult about this.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2011-04-11 13:16 -0400 |
| Message-ID | <27d6q65n762j1836u7k1fuv56m8um6mh78@4ax.com> |
| In reply to | #3409 |
On Mon, 11 Apr 2011 17:56:26 +0100, "Paul" <pchristor@yahoo.co.uk> wrote:
>
>"Goran Pusic" <goranp@cse-semaphore.com> wrote in message
>news:a89688fc-d716-47a5-98e1-feae2fde3ea2@l30g2000vbn.googlegroups.com...
>On Apr 11, 3:05 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>> "Goran" <goran.pu...@gmail.com> wrote in message
>>
>> news:04718043-b351-42da-9deb-5aa1c652bcec@hd10g2000vbb.googlegroups.com...
>> On Apr 11, 1:40 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>>
>> > No, it's clear enough, and you are lying when saying it's not. If you
>> > say that pointer of type "T*" (somehow, sometime, whatever) points to
>> > an __array__ of T, then simplest of pointer operations (indexing,
>> > incrementing) are broken.
>>
>> > Since pointer operations clearly aren't broken, your claim is false.
>>
>> > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>> > What is broken about indexing and incrementing?
>>
>> int a[2][2]={1,2,3,4};
>> int* p1 = a[0]; // p1 points to an array (your claim).
>> p1++;
>> if (*p1 != a[1])
>> std::cout << "incrementing is broken.";
>> int* p2 = a[0]; // p2 points to an array (your claim).
>> if (*p2[1] != a[1])
>> std::cout << "indexing is broken.";
>>
>> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>
>> You create a 2d array, then you create a pointer to a 1d-subarray of this
>> 2d
>> array.
>> Then after that I don't know what you are trying to do. You say its broken
>> but you don't say what you expect it to do.
>
>I expect both pointers to point to a[1]. This is because you say that
>they point to one array (a[0]), and I know that incrementing, or
>indexing pointers with 1, must make them point to next element. Thats
>a[1]. This is how pointers work. Explain why this doesn't happen.
>
>xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>Incrementing it will make it point to a[0][1] becuase you increment a
>pointer to a 1d array.
wrong, the pointer is a pointer to int, not 1d array.
incrementing an int pointer makes it point to a[0][1]
> If you want to make it point to a[1][0] then you must
>use a pointer to a 2d array like so:
>int (*p)[2] = a;
wrong again, p is now a pointer to an array of int object with 2 elements.
this pointer type is a 1-dimensional array type, not 2.
incrementing the 1d array pointer makes it point to a[1][0]
std::cout << "p type is : " << typeid(p).name() << std::endl;
output: p type is : int (*)[2]
you're so confused it is comical.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-04-12 08:09 +1200 |
| Message-ID | <90h5feFhg6U8@mid.individual.net> |
| In reply to | #3412 |
On 04/12/11 05:16 AM, cg_chas wrote: > > you're so confused it is comical. Not only that, the fool still hasn't worked out how to configure his news client! -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-04-12 00:19 -0700 |
| Message-ID | <f2d09f21-3b92-42ec-8377-028e6138f4fb@f30g2000yqa.googlegroups.com> |
| In reply to | #3409 |
On Apr 11, 6:56 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Goran Pusic" <gor...@cse-semaphore.com> wrote in message
>
> news:a89688fc-d716-47a5-98e1-feae2fde3ea2@l30g2000vbn.googlegroups.com...
> On Apr 11, 3:05 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
>
>
> > "Goran" <goran.pu...@gmail.com> wrote in message
>
> >news:04718043-b351-42da-9deb-5aa1c652bcec@hd10g2000vbb.googlegroups.com...
> > On Apr 11, 1:40 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
> > > No, it's clear enough, and you are lying when saying it's not. If you
> > > say that pointer of type "T*" (somehow, sometime, whatever) points to
> > > an __array__ of T, then simplest of pointer operations (indexing,
> > > incrementing) are broken.
>
> > > Since pointer operations clearly aren't broken, your claim is false.
>
> > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > > What is broken about indexing and incrementing?
>
> > int a[2][2]={1,2,3,4};
> > int* p1 = a[0]; // p1 points to an array (your claim).
> > p1++;
> > if (*p1 != a[1])
> > std::cout << "incrementing is broken.";
> > int* p2 = a[0]; // p2 points to an array (your claim).
> > if (*p2[1] != a[1])
> > std::cout << "indexing is broken.";
>
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > You create a 2d array, then you create a pointer to a 1d-subarray of this
> > 2d
> > array.
> > Then after that I don't know what you are trying to do. You say its broken
> > but you don't say what you expect it to do.
>
> I expect both pointers to point to a[1]. This is because you say that
> they point to one array (a[0]), and I know that incrementing, or
> indexing pointers with 1, must make them point to next element. Thats
> a[1]. This is how pointers work. Explain why this doesn't happen.
>
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Incrementing it will make it point to a[0][1] becuase you increment a
> pointer to a 1d array.
OK. So, I'll presume then this claim is true, that int* is a pointer
to 1d array. If so (continuing from previous example)...
p1 = &a[0][1]; // 1
int i;
p1 = &i; // 2
If p is a pointer to a 1d array, how come I can assign address of a
single int to it? a[0][1] and i are clearly not arrays.
Also, if your claim is true, then in:
int aa[2];
int(*pa)[2] = &aa; // 3
pa is a pointer to a 2d array. But aa is clearly __not__ a 2d array.
Since all of 1, 2, 3 is both correct and legal code, your claim, that
T* is a pointer to 1d array of T, is false.
Goran.
[toc] | [prev] | [next] | [standalone]
| From | SG <s.gesemann@gmail.com> |
|---|---|
| Date | 2011-04-12 04:04 -0700 |
| Message-ID | <5b11071b-f99e-400f-bba8-40822fe92f0f@m7g2000vbq.googlegroups.com> |
| In reply to | #3453 |
On 12 Apr., 09:19, Goran wrote: > [...] > If p is a pointer to a 1d array, how come I can assign address > of a single int to it? a[0][1] and i are clearly not arrays. When he says "p is a pointer to a 1d array" he means "p currently stores an address of an array or the address of something that is part of that array". So, when he says "p is ..." he's mainly considering runtime properties and the raw type-agnostic address some object pointer stores. Unlike others, he ignores the type of a pointer variable when it comes to describing what a certain pointer "is". That's why he brought up the broken finger/bunch/banana analogy. Guys, don't you realize that this is going around in circles? Don't you have anything better to do? SG
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-12 13:49 +0100 |
| Message-ID | <X6Yop.29870$0j7.11036@newsfe20.ams2> |
| In reply to | #3459 |
"SG" <s.gesemann@gmail.com> wrote in message news:5b11071b-f99e-400f-bba8-40822fe92f0f@m7g2000vbq.googlegroups.com... > On 12 Apr., 09:19, Goran wrote: >> [...] >> If p is a pointer to a 1d array, how come I can assign address >> of a single int to it? a[0][1] and i are clearly not arrays. > > When he says "p is a pointer to a 1d array" he means "p currently > stores an address of an array or the address of something that is part > of that array". No I mean p points, primarily to an array. >So, when he says "p is ..." he's mainly considering > runtime properties and the raw type-agnostic address some object > pointer stores. A pointer stores an address of an entity. A pointer needs to be treated as if it points-to the entity which it was created and initialised to point to. > Unlike others, he ignores the type of a pointer > variable when it comes to describing what a certain pointer "is". > That's why he brought up the broken finger/bunch/banana analogy. No I acknowledge what type of pointers I use. > > Guys, don't you realize that this is going around in circles? Don't > you have anything better to do? > Like you obviously do?
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-12 13:41 +0100 |
| Message-ID | <uMXop.3809$Y71.3009@newsfe17.ams2> |
| In reply to | #3453 |
"Goran" <goran.pusic@gmail.com> wrote in message
news:f2d09f21-3b92-42ec-8377-028e6138f4fb@f30g2000yqa.googlegroups.com...
On Apr 11, 6:56 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> > > No, it's clear enough, and you are lying when saying it's not. If you
> > > say that pointer of type "T*" (somehow, sometime, whatever) points to
> > > an __array__ of T, then simplest of pointer operations (indexing,
> > > incrementing) are broken.
>
> > > Since pointer operations clearly aren't broken, your claim is false.
>
> > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > > What is broken about indexing and incrementing?
>
> > int a[2][2]={1,2,3,4};
> > int* p1 = a[0]; // p1 points to an array (your claim).
> > p1++;
> > if (*p1 != a[1])
> > std::cout << "incrementing is broken.";
> > int* p2 = a[0]; // p2 points to an array (your claim).
> > if (*p2[1] != a[1])
> > std::cout << "indexing is broken.";
>
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > You create a 2d array, then you create a pointer to a 1d-subarray of
> > this
> > 2d
> > array.
> > Then after that I don't know what you are trying to do. You say its
> > broken
> > but you don't say what you expect it to do.
>
> I expect both pointers to point to a[1]. This is because you say that
> they point to one array (a[0]), and I know that incrementing, or
> indexing pointers with 1, must make them point to next element. Thats
> a[1]. This is how pointers work. Explain why this doesn't happen.
>
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Incrementing it will make it point to a[0][1] becuase you increment a
> pointer to a 1d array.
OK. So, I'll presume then this claim is true, that int* is a pointer
to 1d array. If so (continuing from previous example)...
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Its not a claim its a fact.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
p1 = &a[0][1]; // 1
int i;
p1 = &i; // 2
If p is a pointer to a 1d array, how come I can assign address of a
single int to it? a[0][1] and i are clearly not arrays.
Also, if your claim is true, then in:
int aa[2];
int(*pa)[2] = &aa; // 3
pa is a pointer to a 2d array. But aa is clearly __not__ a 2d array.
Since all of 1, 2, 3 is both correct and legal code, your claim, that
T* is a pointer to 1d array of T, is false.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Whether your code is legal or valid , I don't care but it certainly doesn't
look right to me.
Believe what you want on this subject I have explained enough and if you
still do not understand then IDC.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-04-12 06:48 -0700 |
| Message-ID | <69e5ab7b-822c-4223-b905-74253d16e925@j17g2000vbr.googlegroups.com> |
| In reply to | #3465 |
On Apr 12, 2:41 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Goran" <goran.pu...@gmail.com> wrote in message
>
> news:f2d09f21-3b92-42ec-8377-028e6138f4fb@f30g2000yqa.googlegroups.com...
> On Apr 11, 6:56 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
>
>
> > > > No, it's clear enough, and you are lying when saying it's not. If you
> > > > say that pointer of type "T*" (somehow, sometime, whatever) points to
> > > > an __array__ of T, then simplest of pointer operations (indexing,
> > > > incrementing) are broken.
>
> > > > Since pointer operations clearly aren't broken, your claim is false.
>
> > > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > > > What is broken about indexing and incrementing?
>
> > > int a[2][2]={1,2,3,4};
> > > int* p1 = a[0]; // p1 points to an array (your claim).
> > > p1++;
> > > if (*p1 != a[1])
> > > std::cout << "incrementing is broken.";
> > > int* p2 = a[0]; // p2 points to an array (your claim).
> > > if (*p2[1] != a[1])
> > > std::cout << "indexing is broken.";
>
> > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > > You create a 2d array, then you create a pointer to a 1d-subarray of
> > > this
> > > 2d
> > > array.
> > > Then after that I don't know what you are trying to do. You say its
> > > broken
> > > but you don't say what you expect it to do.
>
> > I expect both pointers to point to a[1]. This is because you say that
> > they point to one array (a[0]), and I know that incrementing, or
> > indexing pointers with 1, must make them point to next element. Thats
> > a[1]. This is how pointers work. Explain why this doesn't happen.
>
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > Incrementing it will make it point to a[0][1] becuase you increment a
> > pointer to a 1d array.
>
> OK. So, I'll presume then this claim is true, that int* is a pointer
> to 1d array. If so (continuing from previous example)...
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Its not a claim its a fact.
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Ok, so it's a fact that it's a pointer to an array. And one can assign
address of a single int to it, too (that's a fact, too). So pointer is
now not a pointer to an array. Therefore, your fact is in conflict
with itself. Therefore, your fact is nonsense.
Goran.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-12 17:20 +0100 |
| Message-ID | <NZ_op.3817$Y71.2211@newsfe17.ams2> |
| In reply to | #3476 |
"Goran" <goran.pusic@gmail.com> wrote in message
news:69e5ab7b-822c-4223-b905-74253d16e925@j17g2000vbr.googlegroups.com...
On Apr 12, 2:41 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
> > > > No, it's clear enough, and you are lying when saying it's not. If
> > > > you
> > > > say that pointer of type "T*" (somehow, sometime, whatever) points
> > > > to
> > > > an __array__ of T, then simplest of pointer operations (indexing,
> > > > incrementing) are broken.
>
> > > > Since pointer operations clearly aren't broken, your claim is false.
>
> > > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > > > What is broken about indexing and incrementing?
>
> > > int a[2][2]={1,2,3,4};
> > > int* p1 = a[0]; // p1 points to an array (your claim).
> > > p1++;
> > > if (*p1 != a[1])
> > > std::cout << "incrementing is broken.";
> > > int* p2 = a[0]; // p2 points to an array (your claim).
> > > if (*p2[1] != a[1])
> > > std::cout << "indexing is broken.";
>
> > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > > You create a 2d array, then you create a pointer to a 1d-subarray of
> > > this
> > > 2d
> > > array.
> > > Then after that I don't know what you are trying to do. You say its
> > > broken
> > > but you don't say what you expect it to do.
>
> > I expect both pointers to point to a[1]. This is because you say that
> > they point to one array (a[0]), and I know that incrementing, or
> > indexing pointers with 1, must make them point to next element. Thats
> > a[1]. This is how pointers work. Explain why this doesn't happen.
>
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > Incrementing it will make it point to a[0][1] becuase you increment a
> > pointer to a 1d array.
>
> OK. So, I'll presume then this claim is true, that int* is a pointer
> to 1d array. If so (continuing from previous example)...
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Its not a claim its a fact.
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Ok, so it's a fact that it's a pointer to an array. And one can assign
address of a single int to it, too (that's a fact, too). So pointer is
now not a pointer to an array.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
This would be correct.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Therefore, your fact is in conflict
with itself. Therefore, your fact is nonsense.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
No your conclusion is nonsense, the same pointer can point to a single int
or and array of int. If you assign to it the address of an array, then it
points to an array. If you assign to it the address of a single int, then it
points to a single int.
A pointer can point to almost anything, it is the programmers job to know,
understand or test for what it points to. In many cases you cannot assume a
pointer is not null, so you must test for this. If a pointer is expected to
point to a single int you cannot treat it as if it points to an array. If a
pointer is supposed to point to an array of int then it should be treated as
a pointer to array, not pointer to single int.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-04-12 23:43 -0700 |
| Message-ID | <31dbe830-82f6-4d8d-8a05-1a24bf24f6d3@z37g2000vbl.googlegroups.com> |
| In reply to | #3489 |
On Apr 12, 6:20 pm, "Paul" <pchris...@yahoo.co.uk> wrote: > No your conclusion is nonsense, the same pointer can point to a single int > or and array of int. If you assign to it the address of an array, then it > points to an array. If you assign to it the address of a single int, then it > points to a single int. If you assign to it the address of an array, then we __commonly say__ that it points to an array. If you assign to it the address of a single int, then it points to a single int. FTFY. You want to conflate "points to" and "is". We commonly do that out of expedience, but giving any more meaning to that leads to bugs, horrible and/or easily misunderstood code, which is what you yourself have done on several occasions in the beginning of this thread. Therefore such conflating is unwarranted. Goran.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-13 11:24 +0100 |
| Message-ID | <0%epp.51335$7u3.5158@newsfe04.ams2> |
| In reply to | #3536 |
"Goran" <goran.pusic@gmail.com> wrote in message news:31dbe830-82f6-4d8d-8a05-1a24bf24f6d3@z37g2000vbl.googlegroups.com... >On Apr 12, 6:20 pm, "Paul" <pchris...@yahoo.co.uk> wrote: >> No your conclusion is nonsense, the same pointer can point to a single >> int >> or and array of int. If you assign to it the address of an array, then it >> points to an array. If you assign to it the address of a single int, then >> it >> points to a single int. >If you assign to it the address of an array, then we __commonly say__ >that it points to an array. If you assign to it the address of a >single int, then it points to a single int. No we don't normally take the address of an array , using the address&of operator. Doing this creates an extra level of indirection show by comparison to pointer to int: int x; int arr[4]; /*create pointers*/ int* p_x = &x; /*pointer to integer*/ int* p_arr = arr; /*pointer to array*/ /*create another level of indirection*/ int** pp_x = &p_x; int (*pp_arr)[5] = &arr; int** pp_p_arr = &p_arr; The above two array pointers are at the same level of indirection. The difference is what happens when you.. a) dereference them b) increment them They both point to exactly the same memory loaction(where the array has been allocated). The pointer-type allows the compiler to know how many bytes of memory will be addressed when the pointer is derefernced >FTFY. >You want to conflate "points to" and "is". We commonly do that out of >expedience, but giving any more meaning to that leads to bugs, >horrible and/or easily misunderstood code, which is what you yourself >have done on several occasions in the beginning of this thread. >Therefore such conflating is unwarranted. I don't know what you are trying to say here. What "points to" generally means is what has been allocated at the pointed to memory.
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2011-04-13 07:13 -0400 |
| Message-ID | <201bq65i7rugtap7j5au02rabd6vippl10@4ax.com> |
| In reply to | #3556 |
On Wed, 13 Apr 2011 11:24:57 +0100, "Paul" <pchristor@yahoo.co.uk> wrote: > >"Goran" <goran.pusic@gmail.com> wrote in message >news:31dbe830-82f6-4d8d-8a05-1a24bf24f6d3@z37g2000vbl.googlegroups.com... >>On Apr 12, 6:20 pm, "Paul" <pchris...@yahoo.co.uk> wrote: >>> No your conclusion is nonsense, the same pointer can point to a single >>> int >>> or and array of int. If you assign to it the address of an array, then it >>> points to an array. If you assign to it the address of a single int, then >>> it >>> points to a single int. > >>If you assign to it the address of an array, then we __commonly say__ >>that it points to an array. If you assign to it the address of a >>single int, then it points to a single int. > >No we don't normally take the address of an array , using the address&of >operator. Doing this creates an extra level of indirection show by >comparison to pointer to int: > >int x; >int arr[4]; > >/*create pointers*/ >int* p_x = &x; /*pointer to integer*/ >int* p_arr = arr; /*pointer to array*/ > >/*create another level of indirection*/ >int** pp_x = &p_x; >int (*pp_arr)[5] = &arr; >int** pp_p_arr = &p_arr; > >The above two array pointers are at the same level of indirection. The >difference is what happens when you.. >a) dereference them >b) increment them > >They both point to exactly the same memory loaction(where the array has been >allocated). The pointer-type allows the compiler to know how many bytes of >memory will be addressed when the pointer is derefernced > > > > >>FTFY. > >>You want to conflate "points to" and "is". We commonly do that out of >>expedience, but giving any more meaning to that leads to bugs, >>horrible and/or easily misunderstood code, which is what you yourself >>have done on several occasions in the beginning of this thread. >>Therefore such conflating is unwarranted. > >I don't know what you are trying to say here. What "points to" generally >means is what has been allocated at the pointed to memory. actually what "points to" means is: For a type T, T* is the type "pointer to T." That is, a variable of type T* can hold the address of an object of type T. The allocation is not relevant, but do not take my word for it, the Standard is very well-defined for this case. ISO/IEC 14882:2003(E) 5.3.4 New, paragraph 5 "When the allocated object is an array (that is, the direct-new-declarator syntax is used or the new-type-id or type-id denotes an array type), the new-expression yields a pointer to the initial element (if any) of the array. [Note: both new int and new int[10] have type int* and the type of new int[i][10] is int (*)[10]. ] type allocated: int[10] type pointed to: int* Best Regards & hth., Charles
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2011-04-13 07:19 -0400 |
| Message-ID | <pj1bq6dekc10emn2tdtt6rrtkkptoqd383@4ax.com> |
| In reply to | #3559 |
On Wed, 13 Apr 2011 07:13:11 -0400, cg_chas <cg_chas@hotmail.com> wrote:
>On Wed, 13 Apr 2011 11:24:57 +0100, "Paul" <pchristor@yahoo.co.uk> wrote:
>
>>
>>"Goran" <goran.pusic@gmail.com> wrote in message
>>news:31dbe830-82f6-4d8d-8a05-1a24bf24f6d3@z37g2000vbl.googlegroups.com...
>>>On Apr 12, 6:20 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>>>> No your conclusion is nonsense, the same pointer can point to a single
>>>> int
>>>> or and array of int. If you assign to it the address of an array, then it
>>>> points to an array. If you assign to it the address of a single int, then
>>>> it
>>>> points to a single int.
>>
>>>If you assign to it the address of an array, then we __commonly say__
>>>that it points to an array. If you assign to it the address of a
>>>single int, then it points to a single int.
>>
>>No we don't normally take the address of an array , using the address&of
>>operator. Doing this creates an extra level of indirection show by
>>comparison to pointer to int:
>>
>>int x;
>>int arr[4];
>>
>>/*create pointers*/
>>int* p_x = &x; /*pointer to integer*/
>>int* p_arr = arr; /*pointer to array*/
>>
>>/*create another level of indirection*/
>>int** pp_x = &p_x;
>>int (*pp_arr)[5] = &arr;
>>int** pp_p_arr = &p_arr;
>>
>>The above two array pointers are at the same level of indirection. The
>>difference is what happens when you..
>>a) dereference them
>>b) increment them
>>
>>They both point to exactly the same memory loaction(where the array has been
>>allocated). The pointer-type allows the compiler to know how many bytes of
>>memory will be addressed when the pointer is derefernced
>>
>>
>>
>>
>>>FTFY.
>>
>>>You want to conflate "points to" and "is". We commonly do that out of
>>>expedience, but giving any more meaning to that leads to bugs,
>>>horrible and/or easily misunderstood code, which is what you yourself
>>>have done on several occasions in the beginning of this thread.
>>>Therefore such conflating is unwarranted.
>>
>>I don't know what you are trying to say here. What "points to" generally
>>means is what has been allocated at the pointed to memory.
>actually what "points to" means is:
>
>For a type T, T* is the type "pointer to T." That is, a variable of type T* can
>hold the address of an object of type T.
>
>The allocation is not relevant, but do not take my word for it, the Standard is
>very well-defined for this case.
>
>ISO/IEC 14882:2003(E) 5.3.4 New, paragraph 5
>
>"When the allocated object is an array (that is, the direct-new-declarator
>syntax is used or the new-type-id or type-id denotes an array type), the
>new-expression yields a pointer to the initial element (if any) of the array.
>[Note: both new int and new int[10] have type int* and the type of new
>int[i][10] is int (*)[10]. ]
>
>type allocated: int[10]
>type pointed to: int*
typo: this should read: type of object: int*
>
>Best Regards & hth.,
>
>Charles
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-04-13 08:31 -0700 |
| Message-ID | <6b0ac9ab-f79f-4694-a9ba-c95a1ef4b441@2g2000vbl.googlegroups.com> |
| In reply to | #3489 |
On Apr 12, 6:20 pm, "Paul" <pchris...@yahoo.co.uk> wrote: > Ok, so it's a fact that it's a pointer to an array. And one can assign > address of a single int to it, too (that's a fact, too). So pointer is > now not a pointer to an array. > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > This would be correct. > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx This implies that what pointer is, i.e. it's type, changes. Given that C and C++ are statically typed languages, that can't be correct. Consequently, claim that pointer changes it's type is incorrect. What is correct, though, is that, out of expedience, we __commonly say__ that pointer __is__ a point to an array. Goran.
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-04-13 23:30 -0700 |
| Message-ID | <5c2c27e8-e02d-4818-9be0-7afb3a1796a9@hd10g2000vbb.googlegroups.com> |
| In reply to | #3489 |
On Apr 12, 6:20 pm, "Paul" <pchris...@yahoo.co.uk> wrote: > Ok, so it's a fact that it's a pointer to an array. And one can assign > address of a single int to it, too (that's a fact, too). So pointer is > now not a pointer to an array. > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > This would be correct. > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > Therefore, your fact is in conflict > with itself. Therefore, your fact is nonsense. > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > No your conclusion is nonsense, the same pointer can point to a single int > or and array of int. No, conclusion is fine. Nonsense are your attempts to equal "is" and "points to". And, they lead to poor coding and errors (see your own attempts earlier in this thread to explain your stance). Goran.
[toc] | [prev] | [next] | [standalone]
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | comp.lang.c++
csiph-web