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 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-03-31 07:21 -0700 |
| Message-ID | <591c26b7-8951-42db-b5ea-292e9142b26e@r3g2000yqh.googlegroups.com> |
| In reply to | #2910 |
On Mar 31, 3:14 pm, "Paul" <pchris...@yahoo.co.uk> wrote: > "Goran" <goran.pu...@gmail.com> wrote in message > > news:b5b52d80-6f54-440d-acc5-397f3a1ff0d2@s18g2000prg.googlegroups.com... > On Mar 31, 11:52 am, "Paul" <pchris...@yahoo.co.uk> wrote: > > > The definition in the C++ standard says it points to the first element OF > > AN > > ARRAY. > > therefore by definition it points to an array you idiot. > > First part, I agree. Second part (the "therefore" one), is false (and > is not in the standard, either). > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > It IS the defintioon in the standard, the standard states it points to the > first element OF AN ARRAY, therefore it cannot NOT point to an array. > > The standard certainly doesn't state, that it doesn't point to an array, as > you are saying. > You do not accept the opinion of experts who say that a T* can point to a T, > or an array of T's. OK, so, let's say that what you say is true... (proof by contradiction follows...) In my previous example... What does "a" in "const A* a = b" points to then? Clearly, b is an array. So what does a points to? To an array of A, an array of B, or what? Clearly, b is an array, code is legal, no casting, no funny business... Further, if a points to an array of A, why incrementing it gives strange results? If it's an array of B, how can that even compile? (B __is__ A, but A __is not__ B). I know that you have no relevant answer to any of these questions, so I'll give it to you: "a" points to __the first element of "b"__. It points to no array, ever. Goran.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-03-31 13:04 +0100 |
| Message-ID | <24-dnUMwk6tF8AnQnZ2dnUVZ8k6dnZ2d@giganews.com> |
| In reply to | #2891 |
On 31/03/2011 02:22, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:6ZqdnRJoifyzXw7QnZ2dnUVZ8qidnZ2d@giganews.com... >> On 31/03/2011 00:42, Paul wrote: >> [...] >>>>>> Anyway it doesn't matter how it *seems* to you; what is important is >>>>>> to be technically accurate and to use correct terminology: casting >>>>>> from derived to base is called "upcasting"; casting from base to >>>>>> derived is called "downcasting". >>>>>> >>>>> Yes says the proven idiot who thinks p doesn't point to an array with: >>>>> int* p = new int[5] >>>> >>>> p is not a pointer to an array; p is a pointer to an int. >>> No p points to the initial element *of an array*, by definiton it points >>> to an array. >> >> Whilst p does point to the initial element of an array that does not >> mean that p is a pointer to an array; p is a pointer to an int. >> > If p points to the intial element *OF AN ARRAY*, then by defintion it > points to an array. By whose definition? Yours? Your own personal definitions of things carry no weight here. The fact that p points to the initial element of an array does not mean that p is a pointer to an array; p is a pointer to an int. > Were you born stupid or did you grow into it? Occam's Razor my dear chap: which is more likely: everybody except Paul is stupid or just Paul is stupid? /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-31 14:16 +0100 |
| Message-ID | <G8%kp.1233$Vm5.614@newsfe30.ams2> |
| In reply to | #2906 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:24-dnUMwk6tF8AnQnZ2dnUVZ8k6dnZ2d@giganews.com... > On 31/03/2011 02:22, Paul wrote: >> >> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >> news:6ZqdnRJoifyzXw7QnZ2dnUVZ8qidnZ2d@giganews.com... >>> On 31/03/2011 00:42, Paul wrote: >>> [...] >>>>>>> Anyway it doesn't matter how it *seems* to you; what is important is >>>>>>> to be technically accurate and to use correct terminology: casting >>>>>>> from derived to base is called "upcasting"; casting from base to >>>>>>> derived is called "downcasting". >>>>>>> >>>>>> Yes says the proven idiot who thinks p doesn't point to an array >>>>>> with: >>>>>> int* p = new int[5] >>>>> >>>>> p is not a pointer to an array; p is a pointer to an int. >>>> No p points to the initial element *of an array*, by definiton it >>>> points >>>> to an array. >>> >>> Whilst p does point to the initial element of an array that does not >>> mean that p is a pointer to an array; p is a pointer to an int. >>> >> If p points to the intial element *OF AN ARRAY*, then by defintion it >> points to an array. > > By whose definition? Yours? By the defintion of the C++ standards, that state the pointer points to the first element OF AN ARRAY. It can't not point to an array if it points to the first element OF AN ARRAY, you idiot.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-03-31 14:26 +0100 |
| Message-ID | <ecidnQ_9haKbHAnQnZ2dnUVZ8hudnZ2d@giganews.com> |
| In reply to | #2911 |
On 31/03/2011 14:16, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:24-dnUMwk6tF8AnQnZ2dnUVZ8k6dnZ2d@giganews.com... >> On 31/03/2011 02:22, Paul wrote: >>> >>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>> news:6ZqdnRJoifyzXw7QnZ2dnUVZ8qidnZ2d@giganews.com... >>>> On 31/03/2011 00:42, Paul wrote: >>>> [...] >>>>>>>> Anyway it doesn't matter how it *seems* to you; what is >>>>>>>> important is >>>>>>>> to be technically accurate and to use correct terminology: casting >>>>>>>> from derived to base is called "upcasting"; casting from base to >>>>>>>> derived is called "downcasting". >>>>>>>> >>>>>>> Yes says the proven idiot who thinks p doesn't point to an array >>>>>>> with: >>>>>>> int* p = new int[5] >>>>>> >>>>>> p is not a pointer to an array; p is a pointer to an int. >>>>> No p points to the initial element *of an array*, by definiton it >>>>> points >>>>> to an array. >>>> >>>> Whilst p does point to the initial element of an array that does not >>>> mean that p is a pointer to an array; p is a pointer to an int. >>>> >>> If p points to the intial element *OF AN ARRAY*, then by defintion it >>> points to an array. >> >> By whose definition? Yours? > By the defintion of the C++ standards, that state the pointer points to > the first element OF AN ARRAY. > It can't not point to an array if it points to the first element OF AN > ARRAY, you idiot. You are just going round in circles. Again: there is a difference between the not so technical term "points to" and the technical term "a pointer to". A *pointer to an int* is *a pointer to an int* not *a pointer to an array*; pretty simple IMO so I wonder why you don't "get" it. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-31 14:37 +0100 |
| Message-ID | <fs%kp.2172$2o1.1579@newsfe18.ams2> |
| In reply to | #2912 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:ecidnQ_9haKbHAnQnZ2dnUVZ8hudnZ2d@giganews.com... > On 31/03/2011 14:16, Paul wrote: >> >> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >> news:24-dnUMwk6tF8AnQnZ2dnUVZ8k6dnZ2d@giganews.com... >>> On 31/03/2011 02:22, Paul wrote: >>>> >>>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>>> news:6ZqdnRJoifyzXw7QnZ2dnUVZ8qidnZ2d@giganews.com... >>>>> On 31/03/2011 00:42, Paul wrote: >>>>> [...] >>>>>>>>> Anyway it doesn't matter how it *seems* to you; what is >>>>>>>>> important is >>>>>>>>> to be technically accurate and to use correct terminology: casting >>>>>>>>> from derived to base is called "upcasting"; casting from base to >>>>>>>>> derived is called "downcasting". >>>>>>>>> >>>>>>>> Yes says the proven idiot who thinks p doesn't point to an array >>>>>>>> with: >>>>>>>> int* p = new int[5] >>>>>>> >>>>>>> p is not a pointer to an array; p is a pointer to an int. >>>>>> No p points to the initial element *of an array*, by definiton it >>>>>> points >>>>>> to an array. >>>>> >>>>> Whilst p does point to the initial element of an array that does not >>>>> mean that p is a pointer to an array; p is a pointer to an int. >>>>> >>>> If p points to the intial element *OF AN ARRAY*, then by defintion it >>>> points to an array. >>> >>> By whose definition? Yours? >> By the defintion of the C++ standards, that state the pointer points to >> the first element OF AN ARRAY. >> It can't not point to an array if it points to the first element OF AN >> ARRAY, you idiot. > > You are just going round in circles. Again: there is a difference between > the not so technical term "points to" and the technical term "a pointer > to". > > A *pointer to an int* is *a pointer to an int* not *a pointer to an > array*; pretty simple IMO so I wonder why you don't "get" it. > And a pointer to an array of int is a pointer to an array. This is a pointer to an array , not a pointer to a single int, pretty simple: int* p = new int[6]; You obviously have an overwhelming desire to get your own back after the many times i have proved you wrong. I have won this argument arleady and I see no need to reply to your idiotic nonsense anymore.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-03-31 14:44 +0100 |
| Message-ID | <ZYidnTEny-DJGAnQnZ2dnUVZ8vydnZ2d@giganews.com> |
| In reply to | #2914 |
On 31/03/2011 14:37, Paul wrote: > > "Leigh Johnston" <leigh@i42.co.uk> wrote in message > news:ecidnQ_9haKbHAnQnZ2dnUVZ8hudnZ2d@giganews.com... >> On 31/03/2011 14:16, Paul wrote: >>> >>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>> news:24-dnUMwk6tF8AnQnZ2dnUVZ8k6dnZ2d@giganews.com... >>>> On 31/03/2011 02:22, Paul wrote: >>>>> >>>>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>>>> news:6ZqdnRJoifyzXw7QnZ2dnUVZ8qidnZ2d@giganews.com... >>>>>> On 31/03/2011 00:42, Paul wrote: >>>>>> [...] >>>>>>>>>> Anyway it doesn't matter how it *seems* to you; what is >>>>>>>>>> important is >>>>>>>>>> to be technically accurate and to use correct terminology: >>>>>>>>>> casting >>>>>>>>>> from derived to base is called "upcasting"; casting from base to >>>>>>>>>> derived is called "downcasting". >>>>>>>>>> >>>>>>>>> Yes says the proven idiot who thinks p doesn't point to an array >>>>>>>>> with: >>>>>>>>> int* p = new int[5] >>>>>>>> >>>>>>>> p is not a pointer to an array; p is a pointer to an int. >>>>>>> No p points to the initial element *of an array*, by definiton it >>>>>>> points >>>>>>> to an array. >>>>>> >>>>>> Whilst p does point to the initial element of an array that does not >>>>>> mean that p is a pointer to an array; p is a pointer to an int. >>>>>> >>>>> If p points to the intial element *OF AN ARRAY*, then by defintion it >>>>> points to an array. >>>> >>>> By whose definition? Yours? >>> By the defintion of the C++ standards, that state the pointer points to >>> the first element OF AN ARRAY. >>> It can't not point to an array if it points to the first element OF AN >>> ARRAY, you idiot. >> >> You are just going round in circles. Again: there is a difference >> between the not so technical term "points to" and the technical term >> "a pointer to". >> >> A *pointer to an int* is *a pointer to an int* not *a pointer to an >> array*; pretty simple IMO so I wonder why you don't "get" it. >> > And a pointer to an array of int is a pointer to an array. Indeed; nobody said otherwise. > This is a pointer to an array , not a pointer to a single int, pretty > simple: > int* p = new int[6]; p is a pointer to an int not a pointer to an array; you can bleat that this is incorrect as much as you like but it will not change the fact that it is a correct statement. > > You obviously have an overwhelming desire to get your own back after the > many times i have proved you wrong. I have won this argument arleady and > I see no need to reply to your idiotic nonsense anymore. > Get my own back? Why? You have not proven me or anybody else wrong so far. If you ever do prove me wrong about something I will admit my mistake; I certainly wouldn't want to "get my own back". Also: the ad hominem is a logical fallacy. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2011-03-30 16:04 -0400 |
| Message-ID | <v927p6tpal8s21dfmt7724v9vt96dci5on@4ax.com> |
| In reply to | #2853 |
On Wed, 30 Mar 2011 18:22:51 +0100, "Paul" <pchristor@yahoo.co.uk> wrote: > >"Leigh Johnston" <leigh@i42.co.uk> wrote in message >news:sNOdnZtNWPu3-A7QnZ2dnUVZ8mOdnZ2d@giganews.com... >> On 30/03/2011 18:06, Paul wrote: >>> >>> "Leigh Johnston" <leigh@i42.co.uk> wrote in message >>> news:dqydndSmfoUl1Q7QnZ2dnUVZ8qqdnZ2d@giganews.com... >>>> On 30/03/2011 15:38, Paul wrote: >>>>> As far as I was aware is perfectly ok to downcast to a Base class. As >>>>> long as the Base class has a virtual destructor the object destruction >>>>> will destruct the whole Dervied object. >>>> >>>> Casting from derived to base is called "upcasting" not "downcasting". >>>> >>> Thats a rather back to front way of looking at it. Casting to a >>> subobject is casting up? >> >> Think about how you draw a family tree: ancestors toward the top; >> descendants toward the bottom (the tree is upside down). > >A family tree is exact opposite of a class inheritance, a parent object is >the most derived object. >In a family tree the children are most derived. I am starting to think you are making shit up as you go along here. And when you are called on your wrongness, you become pridefully defensive and argue the most inane points instead of just acknowledging those who have helped you to be correct. TCPPPL 15.4 Class Hierarchies: "Casting from base class to a derived class is often called a downcast because of the convention of drawing inheritance trees growing from the root down. Similarly, a cast from the derived class to the base is called an upcast." Of course, you're entitled to your own language with its own vocabulary and its own set of terms, but keep in mind that when you come to these forums, you are going to be severely limited in such a way that you feel that everybody here is trying to prove everything that you say is wrong. > >> >> Anyway it doesn't matter how it *seems* to you; what is important is to be >> technically accurate and to use correct terminology: casting from derived >> to base is called "upcasting"; casting from base to derived is called >> "downcasting". >> >Yes says the proven idiot who thinks p doesn't point to an array with: >int* p = new int[5] Ahh, I see, you're still confused. Well I am all too happy to help. That's what we are here for :) p is a pointer to the single int that was returned by new. p is pointer of "int type", not "array of int type" p only points to a single int Anything else that you think p points to is meaningful only in your mind. Consult ISO/IEC 14882 for further information and clarification if you are still confused. By the way, I proudly stand among those that you call idiots since this distringuished group of idiots are all of those that have successfully used simple logic and proper citation of The Standard to prove you wrong.
[toc] | [prev] | [next] | [standalone]
| From | Joshua Maurice <joshuamaurice@gmail.com> |
|---|---|
| Date | 2011-03-30 14:04 -0700 |
| Message-ID | <b4e012b3-9844-41ce-bcbf-0bc9b9f12580@s18g2000prg.googlegroups.com> |
| In reply to | #2869 |
On Mar 30, 1:04 pm, cg_chas <cg_c...@hotmail.com> wrote: > On Wed, 30 Mar 2011 18:22:51 +0100, "Paul" <pchris...@yahoo.co.uk> wrote: >> [...] > I am starting to think you are making shit up as you go along here. Welcome to the club. The rest of us realized this a month or two ago. Just ignore the troll.
[toc] | [prev] | [next] | [standalone]
| From | Kai-Uwe Bux <jkherciueh@gmx.net> |
|---|---|
| Date | 2011-03-30 20:02 +0200 |
| Message-ID | <imvr8j$8n6$1@hoshi.visyn.net> |
| In reply to | #2842 |
Paul wrote:
>
> "Kai-Uwe Bux" <jkherciueh@gmx.net> wrote in message
> news:imupsn$tos$1@hoshi.visyn.net...
>> Here is a data point:
>>
>> #include <iostream>
>>
>> class BaseA{
>> public:
>> int k;
>> BaseA() {std::cout<<"Constructing base a\n";}
>> virtual ~BaseA(){std::cout<<"Destructing base a\n";}
>> };
>>
>> class BaseB {
>> public:
>> int i;
>> BaseB() {std::cout<<"Constructing base b\n";}
>> virtual ~BaseB(){std::cout<<"Destructing base b\n";}
>> };
>>
>> class Derived: public BaseA, BaseB {
>> public:
>> int j;
>> Derived() {std::cout<<"Constructing derived\n";}
>> ~Derived(){std::cout<<"Destructing derived\n";}
>> };
>>
>> int main() {
>> Derived (*p1) [3] = new Derived [2][3];
>> BaseB (*p2)[3] = (BaseB (*)[3])p1;
>> delete [] p2;
>> }
>>
>> This program segfaults on my machine.
>>
>> I think, it is allowed to do so.
>>
>>
> Ok I had a quick look at this.
> This works perfectly ok on my machine. So are you are saying is that its
> UB to cast a pointer to Derived into a pointer to BaseB?
I don't say that.
> Or are you saying that its only UB to cast a pointer of Derived (*)[size]
> to BaseB (*)[size], but its ok to cast a Derived* to a baseB*?
I don't even say that. What I say is that casting the pointer p1 (of type
Derived(*)[3]) to the type (BaseB(*)[3]) results in an unspecified value of
p2. What is UB is calling delete[] on the unspecified value p2.
> As far as I was aware is perfectly ok to downcast to a Base class. As long
> as the Base class has a virtual destructor the object destruction will
> destruct the whole Dervied object.
True. If we had
Derived* p1 = new Derived;
BaseB* p2 = (BaseB*)p1;
delete p2;
everything would be perfectly fine. Note, however, that the case is
_entirely_ different, starting with the C-style cast (BaseB*)p1 being a
static_cast<> as opposed to the reinterpret_cast<> from the previous
snippet. Now, the (redundant) cast is governed by [5.2.9/2]. The delete
expression is governed by [5.3.5/3].
Note, however, that this snippet has UB:
Derived* p1 = new Derived [3];
BaseB* p2 = (BaseB*)p1; // fine so far, but p2[1] would be UB
delete [] p2; // UB as per [5.3.5/3]
This involves the distinction of dynamic and static types: p2 has dynamic
type Derived* and static type BaseB*.
Best,
Kai-Uwe Bux
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-30 20:21 +0100 |
| Message-ID | <HrLkp.2230$9z4.430@newsfe14.ams2> |
| In reply to | #2860 |
"Kai-Uwe Bux" <jkherciueh@gmx.net> wrote in message
news:imvr8j$8n6$1@hoshi.visyn.net...
> Paul wrote:
>
>>
>> "Kai-Uwe Bux" <jkherciueh@gmx.net> wrote in message
>> news:imupsn$tos$1@hoshi.visyn.net...
>>> Here is a data point:
>>>
>>> #include <iostream>
>>>
>>> class BaseA{
>>> public:
>>> int k;
>>> BaseA() {std::cout<<"Constructing base a\n";}
>>> virtual ~BaseA(){std::cout<<"Destructing base a\n";}
>>> };
>>>
>>> class BaseB {
>>> public:
>>> int i;
>>> BaseB() {std::cout<<"Constructing base b\n";}
>>> virtual ~BaseB(){std::cout<<"Destructing base b\n";}
>>> };
>>>
>>> class Derived: public BaseA, BaseB {
>>> public:
>>> int j;
>>> Derived() {std::cout<<"Constructing derived\n";}
>>> ~Derived(){std::cout<<"Destructing derived\n";}
>>> };
>>>
>>> int main() {
>>> Derived (*p1) [3] = new Derived [2][3];
>>> BaseB (*p2)[3] = (BaseB (*)[3])p1;
>>> delete [] p2;
>>> }
>>>
>>> This program segfaults on my machine.
>>>
>>> I think, it is allowed to do so.
>>>
>>>
>> Ok I had a quick look at this.
>> This works perfectly ok on my machine. So are you are saying is that its
>> UB to cast a pointer to Derived into a pointer to BaseB?
>
> I don't say that.
>
>> Or are you saying that its only UB to cast a pointer of Derived (*)[size]
>> to BaseB (*)[size], but its ok to cast a Derived* to a baseB*?
>
> I don't even say that. What I say is that casting the pointer p1 (of type
> Derived(*)[3]) to the type (BaseB(*)[3]) results in an unspecified value
> of
> p2. What is UB is calling delete[] on the unspecified value p2.
>
I thought you might actually have a valid point, but now its quite clear
your just another idiot who has no other objective than to prove anything I
say is wrong.
I don't really care what people like you think tbh 99% of the time you don't
have a clue what you're talking about.
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2011-03-30 15:47 -0400 |
| Message-ID | <fv17p693kilvlo5iapfn4r5e2qg9cpvc1i@4ax.com> |
| In reply to | #2864 |
On Wed, 30 Mar 2011 20:21:55 +0100, "Paul" <pchristor@yahoo.co.uk> wrote:
>
>"Kai-Uwe Bux" <jkherciueh@gmx.net> wrote in message
>news:imvr8j$8n6$1@hoshi.visyn.net...
>> Paul wrote:
>>
>>>
>>> "Kai-Uwe Bux" <jkherciueh@gmx.net> wrote in message
>>> news:imupsn$tos$1@hoshi.visyn.net...
>>>> Here is a data point:
>>>>
>>>> #include <iostream>
>>>>
>>>> class BaseA{
>>>> public:
>>>> int k;
>>>> BaseA() {std::cout<<"Constructing base a\n";}
>>>> virtual ~BaseA(){std::cout<<"Destructing base a\n";}
>>>> };
>>>>
>>>> class BaseB {
>>>> public:
>>>> int i;
>>>> BaseB() {std::cout<<"Constructing base b\n";}
>>>> virtual ~BaseB(){std::cout<<"Destructing base b\n";}
>>>> };
>>>>
>>>> class Derived: public BaseA, BaseB {
>>>> public:
>>>> int j;
>>>> Derived() {std::cout<<"Constructing derived\n";}
>>>> ~Derived(){std::cout<<"Destructing derived\n";}
>>>> };
>>>>
>>>> int main() {
>>>> Derived (*p1) [3] = new Derived [2][3];
>>>> BaseB (*p2)[3] = (BaseB (*)[3])p1;
>>>> delete [] p2;
>>>> }
>>>>
>>>> This program segfaults on my machine.
>>>>
>>>> I think, it is allowed to do so.
>>>>
>>>>
>>> Ok I had a quick look at this.
>>> This works perfectly ok on my machine.
UB doesn't mean that something will or will not work.
It means that the Standard simply does not guarantee the behaviour.
>>>So are you are saying is that its
>>> UB to cast a pointer to Derived into a pointer to BaseB?
>>
>> I don't say that.
>>
>>> Or are you saying that its only UB to cast a pointer of Derived (*)[size]
>>> to BaseB (*)[size], but its ok to cast a Derived* to a baseB*?
>>
>> I don't even say that. What I say is that casting the pointer p1 (of type
>> Derived(*)[3]) to the type (BaseB(*)[3]) results in an unspecified value
>> of
>> p2. What is UB is calling delete[] on the unspecified value p2.
>>
>I thought you might actually have a valid point, but now its quite clear
>your just another idiot who has no other objective than to prove anything I
>say is wrong.
Everybody that disagrees with Paul is an idiot, espectially when they use logic
or proper citation of the Standard to prove him wrong.
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-03-30 00:12 -0700 |
| Message-ID | <270b8feb-2801-4a15-a7a9-05f4f5ab87f5@p13g2000yqh.googlegroups.com> |
| In reply to | #2807 |
On Mar 30, 12:32 am, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Goran" <goran.pu...@gmail.com> wrote in message
>
> news:bed4b5d7-1577-4a11-8267-6e041352635b@k9g2000yqi.googlegroups.com...
>
> >On Mar 29, 1:07 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> >> int (*p1)[5] = (int (*)[5])new int*[5]; /*2d array*/
> >> int (*p2)[5] = (int (*)[5])new int[5]; /*1d array*/
> >> int (*p3)[5] = new int[5][5]; /*2d array*/
> >> delete[] p1;
> >> delete[] p2;
> >> delete[] p3;
>
> >> What is the difference with the above deletes?
>
> >As far as I am concerned, difference is: first two are UB (platform-
> >specific at best), because of wrong casts in corresponding "new",
> >whereas the third one is correct.
>
> Why are they UB? After having a read through the rellevant pages of the
> standard I don't think that it is UB. The standard specifically states that
> the pointer returned from new must be castable.
Return type of "new int(*)[5]" is int**. You cast that into int(*)[5],
using C cast. That, as far as I can see, ends up in same effect as
reinterpret_cast, and reinterpret_cast is UB (or platform specific at
best).
> Consider this more complex example:
> class Base{
> public:
> Base() {std::cout<<"Constructing base\n";}
> virtual ~Base(){std::cout<<"Destructing base\n";}
>
> };
>
> class Derived: public Base{
> public:
> Derived() {std::cout<<"Constructing derived\n";}
> ~Derived(){std::cout<<"Destructing derived\n";}
>
> };
>
> int main() {
> Base (*p2)[3] = (Base (*)[3])new Derived[2][3];
> delete[] p2;
>
> }
>
> The cast is required , otherwise you'd need to loop through the array
> columns for allocation and deallocation..
First, the cast is not required, because
Derived (*p2)[3] = new Derived[2][3];
delete [] p2;
works just as well.
Second, the problem with your exact example is that in practice just
does not work. And I mean, at all!
Try this:
class Base{
public:
Base() : i(0) {}
int i;
};
class Derived: public Base{
public:
Derived() : j(1) {}
int j;
};
Base (*p2)[3] = (Base (*)[3])new Derived[2][3];
const Base& b = p2[0][1];
assert(0 == b.i); // Fires on common implementations
assert(1 == b.i); // Does not fire on common implementations. Eh!?
Of course, problem is that pointer returned by "new Derived[2][3]" and
"Base (*)[3]" have unrelated types, and my code snippet shows why that
is required.
Goran.
> >FAQ uses term "decay". I meant same thing (that was the term used to
> >explain the thing to me).
>
> Ok I see you are talking about implicit pointer conversion.
Nice try ;-);
Goran.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-30 11:36 +0100 |
| Message-ID | <PIDkp.15392$rF.3835@newsfe12.ams2> |
| In reply to | #2821 |
>"Goran" <goran.pusic@gmail.com> wrote in message >news:270b8feb-2801-4a15-a7a9->05f4f5ab87f5@p13g2000yqh.googlegroups.com... >On Mar 30, 12:32 am, "Paul" <pchris...@yahoo.co.uk> wrote: >> "Goran" <goran.pu...@gmail.com> wrote in message >> >> news:bed4b5d7-1577-4a11-8267-6e041352635b@k9g2000yqi.googlegroups.com... >> >> >On Mar 29, 1:07 pm, "Paul" <pchris...@yahoo.co.uk> wrote: >> >> int (*p1)[5] = (int (*)[5])new int*[5]; /*2d array*/ >> >> int (*p2)[5] = (int (*)[5])new int[5]; /*1d array*/ >> >> int (*p3)[5] = new int[5][5]; /*2d array*/ >> >> delete[] p1; >> >> delete[] p2; >> >> delete[] p3; >> >> >> What is the difference with the above deletes? >> >> >specific at best), because of wrong casts in corresponding "new", >> >whereas the third one is correct. >> >> Why are they UB? After having a read through the rellevant pages of the >> standard I don't think that it is UB. The standard specifically states >> that >> the pointer returned from new must be castable. > >Return type of "new int(*)[5]" is int**. You cast that into int(*)[5], >using C cast. That, as far as I can see, ends up in same effect as >reinterpret_cast, and reinterpret_cast is UB (or platform specific at >best). So, as far as you can see, any use of a c-style cast will immediately cause UB? <snip> >Of course, problem is that pointer returned by "new Derived[2][3]" and >"Base (*)[3]" have unrelated types, and my code snippet shows why that >is required. Your code shows me nothing except that you are a noob who uses assert, If you want to expalin something to me in code please don't use noob statements like assert. > >FAQ uses term "decay". I meant same thing (that was the term used to > >explain the thing to me). > > Ok I see you are talking about implicit pointer conversion. Nice try ;-); What does this mean? What am I trying to do in your mind? Sorry for snipping etc but dont have time to manually indent all that crap.
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-03-30 05:26 -0700 |
| Message-ID | <94faa1e8-754e-4144-aae9-29d2d0ce3b7a@a26g2000vbo.googlegroups.com> |
| In reply to | #2833 |
On Mar 30, 12:36 pm, "Paul" <pchris...@yahoo.co.uk> wrote: > >"Goran" <goran.pu...@gmail.com> wrote in message > >news:270b8feb-2801-4a15-a7a9->05f4f5ab8__BEGIN_MASK_n#9g02mG7!__...__END_MASK_i?a63jfAD$z__@p13g2000yqh.googlegroups.com... > >On Mar 30, 12:32 am, "Paul" <pchris...@yahoo.co.uk> wrote: > >> "Goran" <goran.pu...@gmail.com> wrote in message > > >>news:bed4b5d7-1577-4a11-8267-6e041352635b@k9g2000yqi.googlegroups.com... > > >> >On Mar 29, 1:07 pm, "Paul" <pchris...@yahoo.co.uk> wrote: > >> >> int (*p1)[5] = (int (*)[5])new int*[5]; /*2d array*/ > >> >> int (*p2)[5] = (int (*)[5])new int[5]; /*1d array*/ > >> >> int (*p3)[5] = new int[5][5]; /*2d array*/ > >> >> delete[] p1; > >> >> delete[] p2; > >> >> delete[] p3; > > >> >> What is the difference with the above deletes? > > >> >specific at best), because of wrong casts in corresponding "new", > >> >whereas the third one is correct. > > >> Why are they UB? After having a read through the rellevant pages of the > >> standard I don't think that it is UB. The standard specifically states > >> that > >> the pointer returned from new must be castable. > > >Return type of "new int(*)[5]" is int**. You cast that into int(*)[5], > >using C cast. That, as far as I can see, ends up in same effect as > >reinterpret_cast, and reinterpret_cast is UB (or platform specific at > >best). > > So, as far as you can see, any use of a c-style cast will immediately cause > UB? Not will. Could. Your cast up there __will__, however (and a very simple example has shown that). > >Of course, problem is that pointer returned by "new Derived[2][3]" and > >"Base (*)[3]" have unrelated types, and my code snippet shows why that > >is required. > > Your code shows me nothing except that you are a noob who uses assert, If > you want to expalin something to me in code please don't use noob statements > like assert. First, assert is not a statement, it's a function. Second, it's use is incidental to the problem. Noob or not, assert shows that your cast does not work. In slightly more detail: in common implementations, object's memory layout is such that your cast, on your example, fails horribly. Line const Base& b = p2[0][1]; does not produce a reference to b (and it should). It does not do it, because the cast on the line where new is called is __wrong__. In even more detail: what new allocated (on common implementations) is 6 consecutive instances of Derived. So let's presume a 32-bit platform and a common implementation. New gives (memory layout): 32 bits: Base.i 32 bits: Derived.j 32 bits: Base.i 32 bits: Derived.j ... 6 of those in total You tried to cast that to (memory layout on common implementations): 32 bits: Base.i 32 bits: Base.i ... 6 of those in total Your cast causes "b" to "reference" Derived.j, which makes no sense whatsoever. "assert" was only there to show you this. I hoped not so many words were needed, but alas... Goran.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-30 13:41 +0100 |
| Message-ID | <MxFkp.1181$tp6.399@newsfe25.ams2> |
| In reply to | #2836 |
"Goran" <goran.pusic@gmail.com> wrote in message news:94faa1e8-754e-4144-aae9-29d2d0ce3b7a@a26g2000vbo.googlegroups.com... On Mar 30, 12:36 pm, "Paul" <pchris...@yahoo.co.uk> wrote: > >"Goran" <goran.pu...@gmail.com> wrote in message > >news:270b8feb-2801-4a15-a7a9->05f4f5ab8__BEGIN_MASK_n#9g02mG7!__...__END_MASK_i?a63jfAD$z__@p13g2000yqh.googlegroups.com... > >On Mar 30, 12:32 am, "Paul" <pchris...@yahoo.co.uk> wrote: > >> "Goran" <goran.pu...@gmail.com> wrote in message > > >>news:bed4b5d7-1577-4a11-8267-6e041352635b@k9g2000yqi.googlegroups.com... > > >> >On Mar 29, 1:07 pm, "Paul" <pchris...@yahoo.co.uk> wrote: > >> >> int (*p1)[5] = (int (*)[5])new int*[5]; /*2d array*/ > >> >> int (*p2)[5] = (int (*)[5])new int[5]; /*1d array*/ > >> >> int (*p3)[5] = new int[5][5]; /*2d array*/ > >> >> delete[] p1; > >> >> delete[] p2; > >> >> delete[] p3; > > >> >> What is the difference with the above deletes? > > >> >specific at best), because of wrong casts in corresponding "new", > >> >whereas the third one is correct. > > >> Why are they UB? After having a read through the rellevant pages of the > >> standard I don't think that it is UB. The standard specifically states > >> that > >> the pointer returned from new must be castable. > > >Return type of "new int(*)[5]" is int**. You cast that into int(*)[5], > >using C cast. That, as far as I can see, ends up in same effect as > >reinterpret_cast, and reinterpret_cast is UB (or platform specific at > >best). > > So, as far as you can see, any use of a c-style cast will immediately > cause > UB? Not will. Could. Your cast up there __will__, however (and a very simple example has shown that). ------------------------------------------ Who the hell do you think you are ? You cant even communicate properly I cant be arsed with arseholes who cant communicate properly. Im not gonna bother indenting and making an effort for someone who obviously thinks he is abov eme. I told you your example showed me nothing except that you are some noob who uses *STATEMENTS* like assert
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-03-30 06:28 -0700 |
| Message-ID | <536c0fc1-460b-4804-9f81-639be28cd9c8@k30g2000yqb.googlegroups.com> |
| In reply to | #2838 |
On Mar 30, 2:41 pm, "Paul" <pchris...@yahoo.co.uk> wrote: > I told you your example showed me nothing except that you are some noob who > uses *STATEMENTS* like assert I was mistaken, I apologize. assert is not a function, it's rather a macro. It's not a statement though. Please refer to section 6 of the current language standard for more detail on what a statement is. Goran.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-30 15:00 +0100 |
| Message-ID | <8IGkp.827$bI3.274@newsfe15.ams2> |
| In reply to | #2839 |
"Goran" <goran.pusic@gmail.com> wrote in message news:536c0fc1-460b-4804-9f81-639be28cd9c8@k30g2000yqb.googlegroups.com... On Mar 30, 2:41 pm, "Paul" <pchris...@yahoo.co.uk> wrote: > I told you your example showed me nothing except that you are some noob > who > uses *STATEMENTS* like assert I was mistaken, I apologize. assert is not a function, it's rather a macro. It's not a statement though. Please refer to section 6 of the current language standard for more detail on what a statement is. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx I dont care what its called in the standards I called it a statement and you knew what i meant. What I dont understand is what exactly your argument is, you fail to communicate properly. You said something was UB but no expalanation, just because it appeared to be UB to you. Now you are blabbing on about some assert thing. WHat exactly has all this got to do with delete[] ?
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-03-30 07:47 -0700 |
| Message-ID | <1d20e918-d384-43db-8404-28c394ab523e@v8g2000yqb.googlegroups.com> |
| In reply to | #2840 |
On Mar 30, 4:00 pm, "Paul" <pchris...@yahoo.co.uk> wrote: > What I dont understand is what exactly your argument is, you fail to > communicate properly. > You said something was UB but no expalanation, just because it appeared to > be UB to you. > Now you are blabbing on about some assert thing. WHat exactly has all this > got to do with delete[] ? Your cast is on the new side invokes UB. By consequence, your examples are buggy, and so is your call to operator[]. You do not seem to accept that cast invokes UB, so I made you a piece of code that shows why your cast is, and should be, UB. For that piece of code, I used assert to ascertain what should be true (that "0" equals "b.i"). If you compile this snippet without NDEBUG, "assert(0 == b.i)" should not fire, because, clearly, Base() sets i to 0. And yet, this assert does fire (on common implementations). Why? Because your cast invoked UB. Consequently, everything else is wrong, including delete[] you're trying to pull off. Goran.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-30 18:14 +0100 |
| Message-ID | <IxJkp.124$_c3.24@newsfe26.ams2> |
| In reply to | #2844 |
"Goran" <goran.pusic@gmail.com> wrote in message news:1d20e918-d384-43db-8404-28c394ab523e@v8g2000yqb.googlegroups.com... On Mar 30, 4:00 pm, "Paul" <pchris...@yahoo.co.uk> wrote: > What I dont understand is what exactly your argument is, you fail to > communicate properly. > You said something was UB but no expalanation, just because it appeared to > be UB to you. > Now you are blabbing on about some assert thing. WHat exactly has all this > got to do with delete[] ? Your cast is on the new side invokes UB. By consequence, your examples are buggy, and so is your call to operator[]. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Why? Please explain why it is UB? Any time we cast in C++ we produce UB? xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx You do not seem to accept that cast invokes UB, so I made you a piece of code that shows why your cast is, and should be, UB. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Your code doesn't prove the cast is UB. I would accept it if it is UB but as far as I can see all the standard says is that new must return a castable pointer, this implies that its allowed to be casted. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx For that piece of code, I used assert to ascertain what should be true (that "0" equals "b.i"). If you compile this snippet without NDEBUG, "assert(0 == b.i)" should not fire, because, clearly, Base() sets i to 0. And yet, this assert does fire (on common implementations). Why? Because your cast invoked UB. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Eh? Because you code asserts something to be not equal you assert this to mean the cast produces UB? How do you come to that conclusion? xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-03-30 10:33 -0700 |
| Message-ID | <c7844c1b-31da-46c7-b114-0d7be3ea7975@27g2000yqv.googlegroups.com> |
| In reply to | #2851 |
On Mar 30, 7:14 pm, "Paul" <pchris...@yahoo.co.uk> wrote: > "Goran" <goran.pu...@gmail.com> wrote in message > > news:1d20e918-d384-43db-8404-28c394ab523e@v8g2000yqb.googlegroups.com... > On Mar 30, 4:00 pm, "Paul" <pchris...@yahoo.co.uk> wrote: > > > What I dont understand is what exactly your argument is, you fail to > > communicate properly. > > You said something was UB but no expalanation, just because it appeared to > > be UB to you. > > Now you are blabbing on about some assert thing. WHat exactly has all this > > got to do with delete[] ? > > Your cast is on the new side invokes UB. By consequence, your examples > are buggy, and so is your call to operator[]. > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > Why? > Please explain why it is UB? Because you are casting from a pointer of one type to a pointer of an unrelated type (and that's what the compiler told you, too, when you tried without a cast, now did it?) > You do not seem to accept that cast invokes UB, so I made you a piece > of code that shows why your cast is, and should be, UB. > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > Your code doesn't prove the cast is UB. It does. See below. > For that piece of code, I used assert to ascertain what should be true > (that "0" equals "b.i"). If you compile this snippet without NDEBUG, > "assert(0 == b.i)" should not fire, because, clearly, Base() sets i to > 0. And yet, this assert does fire (on common implementations). Why? > Because your cast invoked UB. > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > Eh? Because you code asserts something to be not equal you assert this to > mean the cast produces UB? How do you come to that conclusion? > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx That something is b.i, which is initialized to 0 and never changed. Yet, assert does fire. My claim is that it fires because cast was UB, and, on common implementations, result is that code sees that b.i equals one, not zero. My claim is that implementation is correct in everything it has done, that code is correct in every detail, except for the UB cast. If cast wasn't UB, assert(0 == b.i) would not fire. Since it does, it's because cast is UB. Goran.
[toc] | [prev] | [next] | [standalone]
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
Back to top | Article view | comp.lang.c++
csiph-web