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 1 of 10 [1] 2 3 … 10 Next page →
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-03-29 10:27 -0700 |
| Subject | Re: delete[] p or delete[] *p |
| Message-ID | <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. > I don't know this term "array type erasure". What do you mean by that? FAQ uses term "decay". I meant same thing (that was the term used to explain the thing to me). Goran.
[toc] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-29 23:32 +0100 |
| Message-ID | <bztkp.83$_c3.81@newsfe26.ams2> |
| In reply to | #2801 |
"Goran" <goran.pusic@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.
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..
I could cast it back prior to deletion with:
delete[] (Derived (*)[3])p2;
But this is unneccessary because Base type is an acceptable pointer type.
The type is only neccessay for the correct destruction of objects. For
example:
Base *p2 = new Derived[3];
delete[] p2;
is identical to
Base (*p2)[3] = (Base (*)[3])new Derived[3];
deletep[] p2;
The type that is relevant here is that it is Base or Derived, the number of
elements destructed is decided by the C runtime. As long as the dereferenced
pointer passed to delete has the same value as the pointer returned by new
all is ok, because it is converted to void* anyway. The C runtime decides
whether it deletes 3 objects or 1 , not the type system.
If int[3] and int* both point to the same address, then converted to void*
they are identical.
The C++ type system is only interested in if its an array of int-typ,
Derived-type , or Base-type, It not up to the type system to deicde how many
destructors to call.
It would be UB if you converted the pointer to a different type altogether
for example:
double* p = (double*)new int[6];
delete[] p;
This would be UB , because you are converting to a new type of array..
>
>> I don't know this term "array type erasure". What do you mean by that?
>
>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.
HTH
Paul.
[toc] | [prev] | [next] | [standalone]
| From | Kai-Uwe Bux <jkherciueh@gmx.net> |
|---|---|
| Date | 2011-03-30 01:53 +0200 |
| Message-ID | <imtrd3$kq9$1@hoshi.visyn.net> |
| In reply to | #2807 |
Paul wrote:
>
> "Goran" <goran.pusic@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.
We shall see.
> The standard specifically states that the pointer returned from new must
> be castable.
Correct: [5.2.10/7] states:
A pointer to an object can be explicitly converted to a pointer to an
object of different type.65) Except that converting an rvalue of type
"pointer to T1" to the type "pointer to T2" (where T1 and T2 are object
types and where the alignment requirements of T2 are no stricter than
those of T1) and back to its original type yields the original pointer
value, the result of such a pointer conversion is unspecified.
That implies that after casting, you have an unspecified result. The only
thing you can do with it, is casting back, and even that presupposes
compatible alignment requirement.
In particular, passing the unspecified value obtained by casting to delete
or delete [] is undefined behavior.
> 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..
> I could cast it back prior to deletion with:
> delete[] (Derived (*)[3])p2;
>
> But this is unneccessary because Base type is an acceptable pointer type.
What do you mean by "acceptable"?
Also, the value of the variable p2 is _unspecified_ as it is obtained
through casting.
> The type is only neccessay for the correct destruction of objects. For
> example:
> Base *p2 = new Derived[3];
> delete[] p2;
>
> is identical to
> Base (*p2)[3] = (Base (*)[3])new Derived[3];
> deletep[] p2;
>
> The type that is relevant here is that it is Base or Derived, the number
> of elements destructed is decided by the C runtime. As long as the
> dereferenced pointer passed to delete has the same value as the pointer
> returned by new all is ok, because it is converted to void* anyway. The C
> runtime decides whether it deletes 3 objects or 1 , not the type system.
Sameness of value is not guaranteed by the standard (pretending we know what
it means). Consider:
int main () {
Derived (*p1) [3] = new Derived [2][3];
Base (*p2) [3] = (Base (*)[3]) p1;
assert( p1 == p2 );
}
This does not even compile as p1 and p2 are of different type.
> If int[3] and int* both point to the same address, then converted to void*
> they are identical.
So this is what we mean by "sameness of values". Ok, let's consider
int main () {
Derived (*p1) [3] = new Derived [2][3];
Base (*p2) [3] = (Base (*)[3]) p1;
assert( (void*)p1 == (void*)p2 );
}
Now, the code compiles. However, contrary to expectations, the assert is
allowed to _fail_ because the value of p2 is unspecified. In fact, using the
unspecified value as an argument for a cast is UB. So, we could do:
int main () {
Derived (*p1) [3] = new Derived [2][3];
Base (*p2) [3] = (Base (*)[3]) p1;
assert( p2 == (Base (*) [3]) p1 );
}
This looks as though it could not fail. However, the two sides of the == are
both unspecified values. It is neither clear that they are equal nor that
comparing them does not result in a core dump.
If you see more guarantees in the standard that would render any of the
above defined behavior, please cite them.
[...]
Best,
Kai-Uwe Bux
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-30 03:55 +0100 |
| Message-ID | <4Zwkp.3320$Hl6.1475@newsfe23.ams2> |
| In reply to | #2809 |
"Kai-Uwe Bux" <jkherciueh@gmx.net> wrote in message
news:imtrd3$kq9$1@hoshi.visyn.net...
> Paul wrote:
>
>>
>> "Goran" <goran.pusic@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.
>
> We shall see.
>
>> The standard specifically states that the pointer returned from new must
>> be castable.
>
> Correct: [5.2.10/7] states:
>
> A pointer to an object can be explicitly converted to a pointer to an
> object of different type.65) Except that converting an rvalue of type
> "pointer to T1" to the type "pointer to T2" (where T1 and T2 are object
> types and where the alignment requirements of T2 are no stricter than
> those of T1) and back to its original type yields the original pointer
> value, the result of such a pointer conversion is unspecified.
>
> That implies that after casting, you have an unspecified result. The only
> thing you can do with it, is casting back, and even that presupposes
> compatible alignment requirement.
>
But I didn't cast to a different object type, I casted to an array of
objects of the same type.
That quote is talking about converting between objects of a different types.
> In particular, passing the unspecified value obtained by casting to delete
> or delete [] is undefined behavior.
What is unspecified , the cast does not make the pointer *unspecified*
>
>
>> 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..
>> I could cast it back prior to deletion with:
>> delete[] (Derived (*)[3])p2;
>>
>> But this is unneccessary because Base type is an acceptable pointer type.
>
> What do you mean by "acceptable"?
Acceptable pointer type, that is a base(with virtual destructor) or derived
class. There are probably many other acceptable pointer conversions which
are Implementation specific e.g: short to int where they are both the same
size.
>
> Also, the value of the variable p2 is _unspecified_ as it is obtained
> through casting.
Casting doesn't make it *unspecified*.
>
>> The type is only neccessay for the correct destruction of objects. For
>> example:
>> Base *p2 = new Derived[3];
>> delete[] p2;
>>
>> is identical to
>> Base (*p2)[3] = (Base (*)[3])new Derived[3];
>> deletep[] p2;
>>
>> The type that is relevant here is that it is Base or Derived, the number
>> of elements destructed is decided by the C runtime. As long as the
>> dereferenced pointer passed to delete has the same value as the pointer
>> returned by new all is ok, because it is converted to void* anyway. The C
>> runtime decides whether it deletes 3 objects or 1 , not the type system.
>
> Sameness of value is not guaranteed by the standard (pretending we know
> what
> it means). Consider:
>
> int main () {
> Derived (*p1) [3] = new Derived [2][3];
> Base (*p2) [3] = (Base (*)[3]) p1;
> assert( p1 == p2 );
> }
>
> This does not even compile as p1 and p2 are of different type.
That doesn't mean the values are not the same though does it.
>
>> If int[3] and int* both point to the same address, then converted to
>> void*
>> they are identical.
>
> So this is what we mean by "sameness of values". Ok, let's consider
>
> int main () {
> Derived (*p1) [3] = new Derived [2][3];
> Base (*p2) [3] = (Base (*)[3]) p1;
> assert( (void*)p1 == (void*)p2 );
> }
>
> Now, the code compiles. However, contrary to expectations, the assert is
> allowed to _fail_ because the value of p2 is unspecified. In fact, using
> the
> unspecified value as an argument for a cast is UB. So, we could do:
I don't know what your problem is with understand the meaning of two of the
same values.
its simple:
float f = 65;
int x = 65;
long l = 65;
same values.
>
> int main () {
> Derived (*p1) [3] = new Derived [2][3];
> Base (*p2) [3] = (Base (*)[3]) p1;
> assert( p2 == (Base (*) [3]) p1 );
> }
>
> This looks as though it could not fail. However, the two sides of the ==
> are
> both unspecified values. It is neither clear that they are equal nor that
> comparing them does not result in a core dump.
I don't have a clue what you are talking about, what is an unspecified
value? What fails?
A pointers' value is the address it points to , if two pointers point to the
same address they have they same value, simple as that.
>
> If you see more guarantees in the standard that would render any of the
> above defined behavior, please cite them.
>
What guarantees you talknig about here?
[toc] | [prev] | [next] | [standalone]
| From | Kai-Uwe Bux <jkherciueh@gmx.net> |
|---|---|
| Date | 2011-03-30 09:52 +0200 |
| Message-ID | <imung5$t2f$1@hoshi.visyn.net> |
| In reply to | #2814 |
Paul wrote: > > "Kai-Uwe Bux" <jkherciueh@gmx.net> wrote in message > news:imtrd3$kq9$1@hoshi.visyn.net... >> Paul wrote: >> >>> >>> "Goran" <goran.pusic@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. >> >> We shall see. >> >>> The standard specifically states that the pointer returned from new must >>> be castable. >> >> Correct: [5.2.10/7] states: >> >> A pointer to an object can be explicitly converted to a pointer to an >> object of different type.65) Except that converting an rvalue of type >> "pointer to T1" to the type "pointer to T2" (where T1 and T2 are object >> types and where the alignment requirements of T2 are no stricter than >> those of T1) and back to its original type yields the original pointer >> value, the result of such a pointer conversion is unspecified. >> >> That implies that after casting, you have an unspecified result. The only >> thing you can do with it, is casting back, and even that presupposes >> compatible alignment requirement. >> > But I didn't cast to a different object type, I casted to an array of > objects of the same type. > That quote is talking about converting between objects of a different > types. [...] Ok, so you are saying that the C-style cast you are using is _not_ governed by clause [5.2.10/7]. Please specify which clause of the standard you are relying on in determining the behavior of the cast expression. Best, Kai-Uwe Bux
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-30 11:44 +0100 |
| Message-ID | <DQDkp.3001$o81.1136@newsfe28.ams2> |
| In reply to | #2823 |
"Kai-Uwe Bux" <jkherciueh@gmx.net> wrote in message news:imung5$t2f$1@hoshi.visyn.net... > Paul wrote: > >> >> "Kai-Uwe Bux" <jkherciueh@gmx.net> wrote in message >> news:imtrd3$kq9$1@hoshi.visyn.net... >>> Paul wrote: >>> >>>> >>>> "Goran" <goran.pusic@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. >>> >>> We shall see. >>> >>>> The standard specifically states that the pointer returned from new >>>> must >>>> be castable. >>> >>> Correct: [5.2.10/7] states: >>> >>> A pointer to an object can be explicitly converted to a pointer to an >>> object of different type.65) Except that converting an rvalue of type >>> "pointer to T1" to the type "pointer to T2" (where T1 and T2 are object >>> types and where the alignment requirements of T2 are no stricter than >>> those of T1) and back to its original type yields the original pointer >>> value, the result of such a pointer conversion is unspecified. >>> >>> That implies that after casting, you have an unspecified result. The >>> only >>> thing you can do with it, is casting back, and even that presupposes >>> compatible alignment requirement. >>> >> But I didn't cast to a different object type, I casted to an array of >> objects of the same type. >> That quote is talking about converting between objects of a different >> types. > [...] > > Ok, so you are saying that the C-style cast you are using is _not_ > governed > by clause [5.2.10/7]. Please specify which clause of the standard you are > relying on in determining the behavior of the cast expression. > > I was saying the cast wasn't an issue with me, I don't see things in such a way that every cast produces UB. A cast from int* to int*[] doesn't seem like a major conversion of any major concern to me.
[toc] | [prev] | [next] | [standalone]
| From | Kai-Uwe Bux <jkherciueh@gmx.net> |
|---|---|
| Date | 2011-03-30 19:44 +0200 |
| Message-ID | <imvq59$89a$1@hoshi.visyn.net> |
| In reply to | #2835 |
Paul wrote: > > "Kai-Uwe Bux" <jkherciueh@gmx.net> wrote in message > news:imung5$t2f$1@hoshi.visyn.net... >> Paul wrote: >> >>> >>> "Kai-Uwe Bux" <jkherciueh@gmx.net> wrote in message >>> news:imtrd3$kq9$1@hoshi.visyn.net... >>>> Paul wrote: >>>> >>>>> >>>>> "Goran" <goran.pusic@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. >>>> >>>> We shall see. >>>> >>>>> The standard specifically states that the pointer returned from new >>>>> must >>>>> be castable. >>>> >>>> Correct: [5.2.10/7] states: >>>> >>>> A pointer to an object can be explicitly converted to a pointer to an >>>> object of different type.65) Except that converting an rvalue of type >>>> "pointer to T1" to the type "pointer to T2" (where T1 and T2 are >>>> object types and where the alignment requirements of T2 are no >>>> stricter than those of T1) and back to its original type yields the >>>> original pointer value, the result of such a pointer conversion is >>>> unspecified. >>>> >>>> That implies that after casting, you have an unspecified result. The >>>> only >>>> thing you can do with it, is casting back, and even that presupposes >>>> compatible alignment requirement. >>>> >>> But I didn't cast to a different object type, I casted to an array of >>> objects of the same type. >>> That quote is talking about converting between objects of a different >>> types. >> [...] >> >> Ok, so you are saying that the C-style cast you are using is _not_ >> governed >> by clause [5.2.10/7]. Please specify which clause of the standard you are >> relying on in determining the behavior of the cast expression. >> >> > I was saying the cast wasn't an issue with me, I don't see things in such > a way that every cast produces UB. Not _every_ cast. Just the one in your code :-) > A cast from int* to int*[] doesn't seem like a major conversion of any > major concern to me. It is a conversion not governed by anything else than [5.2.10/7]. And the governing clause [5.2.10/7] specifies that the result of the cast is unspecified. Using those unspecified values farther down the road in any way not listed in [5.2.10/7] is undefined behavior as per: 1.3.12 undefined behavior behavior, such as might arise upon use of an erroneous program construct or erroneous data, for which this International Standard imposes no requirements. Undefined behavior may also be expected when this International Standard omits the description of any explicit definition of behavior. Best, Kai-Uwe Bux
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-30 20:18 +0100 |
| Message-ID | <7mLkp.1475$cx.1094@newsfe24.ams2> |
| In reply to | #2859 |
"Kai-Uwe Bux" <jkherciueh@gmx.net> wrote in message news:imvq59$89a$1@hoshi.visyn.net... > 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. >>>>> >>>>> We shall see. >>>>> >>>>>> The standard specifically states that the pointer returned from new >>>>>> must >>>>>> be castable. >>>>> >>>>> Correct: [5.2.10/7] states: >>>>> >>>>> A pointer to an object can be explicitly converted to a pointer to an >>>>> object of different type.65) Except that converting an rvalue of type >>>>> "pointer to T1" to the type "pointer to T2" (where T1 and T2 are >>>>> object types and where the alignment requirements of T2 are no >>>>> stricter than those of T1) and back to its original type yields the >>>>> original pointer value, the result of such a pointer conversion is >>>>> unspecified. >>>>> >>>>> That implies that after casting, you have an unspecified result. The >>>>> only >>>>> thing you can do with it, is casting back, and even that presupposes >>>>> compatible alignment requirement. >>>>> >>>> But I didn't cast to a different object type, I casted to an array of >>>> objects of the same type. >>>> That quote is talking about converting between objects of a different >>>> types. >>> [...] >>> >>> Ok, so you are saying that the C-style cast you are using is _not_ >>> governed >>> by clause [5.2.10/7]. Please specify which clause of the standard you >>> are >>> relying on in determining the behavior of the cast expression. >>> >>> >> I was saying the cast wasn't an issue with me, I don't see things in such >> a way that every cast produces UB. > > Not _every_ cast. Just the one in your code :-) > Oh right so its a case of any time I do a cast its UB because you say so. Like I bother what people like you think if thats the case.
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2011-03-30 04:30 -0400 |
| Message-ID | <dbp5p6tflosp0htdtjm6o0e3v02iln3bnm@4ax.com> |
| In reply to | #2814 |
On Wed, 30 Mar 2011 03:55:53 +0100, "Paul" <pchristor@yahoo.co.uk> wrote: > >"Kai-Uwe Bux" <jkherciueh@gmx.net> wrote in message >news:imtrd3$kq9$1@hoshi.visyn.net... >> Paul wrote: >> >>> >>> "Goran" <goran.pusic@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. >> >> We shall see. >> >>> The standard specifically states that the pointer returned from new must >>> be castable. >> >> Correct: [5.2.10/7] states: >> >> A pointer to an object can be explicitly converted to a pointer to an >> object of different type.65) Except that converting an rvalue of type >> "pointer to T1" to the type "pointer to T2" (where T1 and T2 are object >> types and where the alignment requirements of T2 are no stricter than >> those of T1) and back to its original type yields the original pointer >> value, the result of such a pointer conversion is unspecified. >> >> That implies that after casting, you have an unspecified result. The only >> thing you can do with it, is casting back, and even that presupposes >> compatible alignment requirement. >> >But I didn't cast to a different object type, I casted to an array of >objects of the same type. >That quote is talking about converting between objects of a different types. But you did cast to a different type in both of the above cases that you casted: 1) from int** to int(*)[5] 2) from int* to int(*)[5] or in language that even you should understand since it appears that you are confused by the Standard's use of what pointer to and object of different type means: 1) from "pointer to int pointer" to "pointer to array of int" 2) from "pointer to int" to "pointer to array of int" Once again, this takes us back to all of the previous message threads that you have started which demonstrate some form of your confusion with the fact that a pointer to int and pointer to array of int are not the same thing. Now whether or not there are stricter alignment requirements for T2 than T1 is another story. I do not think there is under Windows for the above types, but the idea is that UB is potentially there where C++ is concerned. Something that could easily be remedied by not casting the return in the first place.
[toc] | [prev] | [next] | [standalone]
| From | Kai-Uwe Bux <jkherciueh@gmx.net> |
|---|---|
| Date | 2011-03-30 10:33 +0200 |
| Message-ID | <imupsn$tos$1@hoshi.visyn.net> |
| In reply to | #2814 |
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.
Best,
Kai-Uwe Bux
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-30 11:39 +0100 |
| Message-ID | <GLDkp.1897$2o1.1406@newsfe18.ams2> |
| In reply to | #2828 |
"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.
>
>
> Best,
>
I will need to look at this later when I have more time. As this is a
different inheritance pattern maybe there are some isssues
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-30 15:38 +0100 |
| Message-ID | <aiHkp.2176$9z4.1703@newsfe14.ams2> |
| In reply to | #2828 |
"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?
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*?
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.
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-03-30 16:14 +0100 |
| Message-ID | <dqydndSmfoUl1Q7QnZ2dnUVZ8qqdnZ2d@giganews.com> |
| In reply to | #2842 |
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". /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-30 18:06 +0100 |
| Message-ID | <vqJkp.2050$Pi.553@newsfe22.ams2> |
| In reply to | #2846 |
"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?
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-03-30 18:15 +0100 |
| Message-ID | <sNOdnZtNWPu3-A7QnZ2dnUVZ8mOdnZ2d@giganews.com> |
| In reply to | #2850 |
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). 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". /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-30 18:22 +0100 |
| Message-ID | <UFJkp.1231$5t2.786@newsfe06.ams2> |
| In reply to | #2852 |
"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. > > 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]
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-03-30 18:38 +0100 |
| Message-ID | <JY-dnaCxyM0y9w7QnZ2dnUVZ8sGdnZ2d@giganews.com> |
| In reply to | #2853 |
On 30/03/2011 18:22, Paul 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. A family tree was an example of a tree which you typically draw upside down (the root is at the top); an inheritance hierarchy is typically viewed as a tree where the base classes are at the root of the tree and similar to a family tree the root is at the top hence the term "upcast". > >> >> 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. You are the one who continually provides evidence to everyone reading your posts as to who the idiot actually is; you certainly have yet to provide any evidence or proof that those who continually correct you are idiots although giving a troll such as yourself any time probably *is* idiotic. If you are not a troll and you actually believe the bullshit you post then your cause is a hopeless one. /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-31 00:42 +0100 |
| Message-ID | <tdPkp.1699$2W5.1206@newsfe16.ams2> |
| In reply to | #2857 |
"Leigh Johnston" <leigh@i42.co.uk> wrote in message news:JY-dnaCxyM0y9w7QnZ2dnUVZ8sGdnZ2d@giganews.com... > On 30/03/2011 18:22, Paul 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. > > A family tree was an example of a tree which you typically draw upside > down (the root is at the top); an inheritance hierarchy is typically > viewed as a tree where the base classes are at the root of the tree and > similar to a family tree the root is at the top hence the term "upcast". > >> >>> >>> 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. > > You are the one who continually provides evidence to everyone reading your > posts as to who the idiot actually is; you certainly have yet to provide > any evidence or proof that those who continually correct you are idiots > although giving a troll such as yourself any time probably *is* idiotic. > > If you are not a troll and you actually believe the bullshit you post then > your cause is a hopeless one. > Very good but it's obvious to anyone, with isn't an idiot, that you are an idiot. As for the idiots who agree with you, I don't really care what they think . :-)
[toc] | [prev] | [next] | [standalone]
| From | Leigh Johnston <leigh@i42.co.uk> |
|---|---|
| Date | 2011-03-31 00:52 +0100 |
| Message-ID | <6ZqdnRJoifyzXw7QnZ2dnUVZ8qidnZ2d@giganews.com> |
| In reply to | #2885 |
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. [...] /Leigh
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-31 02:22 +0100 |
| Message-ID | <tHQkp.946$Y71.675@newsfe17.ams2> |
| In reply to | #2886 |
"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. Were you born stupid or did you grow into it?
[toc] | [prev] | [next] | [standalone]
Page 1 of 10 [1] 2 3 … 10 Next page →
Back to top | Article view | comp.lang.c++
csiph-web