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 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-03-30 23:44 -0700 |
| Message-ID | <362fae78-1af4-4f00-994c-88b508110631@k22g2000yqh.googlegroups.com> |
| In reply to | #2891 |
On Mar 31, 3:22 am, "Paul" <pchris...@yahoo.co.uk> wrote: > >>>> 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. I don't know what definition you are talking about, but either the definition, or your interpretation thereof, is wrong. Return type of expression "new TYPE[5]" is "TYPE*", not e.g. TYPE[5], or, I dunno, TYPE(*)[5]. Array (as in TYPE[size]) is in no way involved there. Arrays and pointers mix in some other contexts^^^. It looks like the syntax (new TYPE[5]), that resembles an array declaration, confuses you. You might want to think of it this way: int* p = new int(1); // p is a pointer to int. p = new int[2]; // p is __still__ a pointer to int int i; p = &i; // p is __still__ a pointer to int int a[3]; p = a; // ^^^ implicit array-to-pointer conversion // p is __still__ a pointer to int You seem to believe that there is something as pointer-to-array conversion (or pointer-to-pointertoarray conversion). That belief is wrong. Goran.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-31 10:52 +0100 |
| Message-ID | <T9Ykp.1640$cx.1043@newsfe24.ams2> |
| In reply to | #2895 |
"Goran" <goran.pusic@gmail.com> wrote in message news:362fae78-1af4-4f00-994c-88b508110631@k22g2000yqh.googlegroups.com... On Mar 31, 3:22 am, "Paul" <pchris...@yahoo.co.uk> wrote: > >>>> 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. I don't know what definition you are talking about, but either the definition, or your interpretation thereof, is wrong. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 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. <snip >
[toc] | [prev] | [next] | [standalone]
| From | cg_chas <cg_chas@hotmail.com> |
|---|---|
| Date | 2011-03-31 06:13 -0400 |
| Message-ID | <r7k8p6tug8p7fu1i60na83uqg6em9b0nmf@4ax.com> |
| In reply to | #2900 |
On Thu, 31 Mar 2011 10:52:48 +0100, "Paul" <pchristor@yahoo.co.uk> wrote: > >"Goran" <goran.pusic@gmail.com> wrote in message >news:362fae78-1af4-4f00-994c-88b508110631@k22g2000yqh.googlegroups.com... >On Mar 31, 3:22 am, "Paul" <pchris...@yahoo.co.uk> wrote: >> >>>> 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. > >I don't know what definition you are talking about, but either the >definition, or your interpretation thereof, is wrong. > >xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > >The definition in the C++ standard says it points to the first element stop right there and you'll seem like less of a degenerate. >OF AN ARRAY. Pointing to the first element is not the same thing as pointing to the array. The array is a different type than is the first element, no matter how many times you beligerantly say otherwise. >therefore by definition it points to an array you idiot. lol, by your definition, which everybody who has responded to you has indicated is meaningless. your points are all meaningless paul. congratulations for all your time well spent :)
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-03-31 04:00 -0700 |
| Message-ID | <b5b52d80-6f54-440d-acc5-397f3a1ff0d2@s18g2000prg.googlegroups.com> |
| In reply to | #2900 |
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).
Here, a practical example why __your__ "therefore" is wrong:
class A
{
public:
A() : i(0) {}
const int i;
};
class B : public A
{
public:
B() : j(1) {}
const int j;
};
int main(int, char*[])
{
const B b[2];
const A* a = b;
if (a->i == 0)
std::cout << "a points to the array b" << std::endl;
a++;
std::cout << "I did a++; now it points to the second element of the
array b;" << std::endl;
std::cout << "That's what pointers do, right?" << std::endl;
if (a->i == 1)
{
std::cout << "Hmmm... no object of type A has i that equals 1." <<
std::endl;
std::cout << "I must have invoked UB somewhere. I wonder where..."
<< std::endl;
std::cout << "Perhaps in the part where I said that a points to
the array b?" << std::endl;
std::cout << "Nooo... Un-possible!";
}
return 0;
}
Goran.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-31 14:14 +0100 |
| Message-ID | <Z6%kp.2589$7u3.830@newsfe04.ams2> |
| In reply to | #2902 |
"Goran" <goran.pusic@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. <snip>
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-03-31 07:01 -0700 |
| Message-ID | <5e510662-7f68-438d-917c-27e4eace1dc8@1g2000yqq.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. First things first. You do understand now that casts you tried to pull off are UB, right? Goran.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-31 15:55 +0100 |
| Message-ID | <KB0lp.15629$rF.6003@newsfe12.ams2> |
| In reply to | #2917 |
"Goran" <goran.pusic@gmail.com> wrote in message news:5e510662-7f68-438d-917c-27e4eace1dc8@1g2000yqq.googlegroups.com... 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. First things first. You do understand now that casts you tried to pull off are UB, right? xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx What exactly is UB? Casting in general produces UB, or only when I cast? Is it a case that you are not interested in discovering the true language technicalities and that your sole intention is to prove that I am wrong about something.
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-03-31 08:10 -0700 |
| Message-ID | <c59c6538-f590-41aa-8336-e44ce7315c8a@1g2000yqq.googlegroups.com> |
| In reply to | #2920 |
On Mar 31, 4:55 pm, "Paul" <pchris...@yahoo.co.uk> wrote: > First things first. You do understand now that casts you tried to pull > off are UB, right? > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > What exactly is UB? Casting in general produces UB, or only when I cast? In your post here: http://groups.google.com/group/comp.lang.c++/msg/1948e01fd0971cac, I claimed that first two casts were UB. You claimed that they were not. I proved you that they were (read back, please). Goran.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-03-31 18:20 +0100 |
| Message-ID | <7K2lp.3975$o81.160@newsfe28.ams2> |
| In reply to | #2921 |
"Goran" <goran.pusic@gmail.com> wrote in message
news:c59c6538-f590-41aa-8336-e44ce7315c8a@1g2000yqq.googlegroups.com...
On Mar 31, 4:55 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> First things first. You do understand now that casts you tried to pull
> off are UB, right?
>
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> What exactly is UB? Casting in general produces UB, or only when I cast?
In your post here:
http://groups.google.com/group/comp.lang.c++/msg/1948e01fd0971cac,
I claimed that first two casts were UB. You claimed that they were
not. I proved you that they were (read back, please).
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
You haven't proved anything is UB, In C++ casting is not UB , its
conversion form one type to another. Initially you said casting the return
from new was UB but since I have stated the standards states the return from
new must be castable you have changed your tune to , "your cast is UB
because I say so". Your code with assets and comparisons does not prove that
a cast is UB it only proves you can write code that has bugs.
Are you saying that casting a pointer to an array is UB? , Who knows because
you are not being specific, you are simply stating my cast is UB because you
say so.
Is this UB in your mind then:
template <typename T, int S>
T* foo(){
return static_cast<T*>(::operator new(S * sizeof(T)));
}
int main() {
int (*p)[6] = foo<int[6], 6>();
}
.
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-04-01 01:14 -0700 |
| Message-ID | <b371e97b-2d73-4cb0-8f96-72f79f8fb61f@r13g2000yqk.googlegroups.com> |
| In reply to | #2929 |
On Mar 31, 7:20 pm, "Paul" <pchris...@yahoo.co.uk> wrote: > "Goran" <goran.pu...@gmail.com> wrote in message > > news:c59c6538-f590-41aa-8336-e44ce7315c8a@1g2000yqq.googlegroups.com... > On Mar 31, 4:55 pm, "Paul" <pchris...@yahoo.co.uk> wrote: > > > First things first. You do understand now that casts you tried to pull > > off are UB, right? > > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > > What exactly is UB? Casting in general produces UB, or only when I cast? > > In your post here:http://groups.google.com/group/comp.lang.c++/msg/1948e01fd0971cac, > I claimed that first two casts were UB. You claimed that they were > not. I proved you that they were (read back, please). > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > You haven't proved anything is UB, Yes I have. Read this again: http://groups.google.com/group/comp.lang.c++/msg/e274c527afabc5f4 Now... (proof by contradiction follows... Do you know what "proof by contradiction" means, BTW? I hope so. If not, I hope you can google it.) So... See the code? See the line: Base (*p2)[3] = (Base (*)[3])new Derived[2][3]; ? You claimed that one should be able to do it, in this post: http://groups.google.com/group/comp.lang.c++/msg/310cebb655d59715 So, presuming that your cast is not UB, I made you a bit of code that uses your cast and doesn't work correctly. I'll repeat offending part, slightly modified, since you seem to have an issue with assert macro (a macro is not a statement, which is something you don't seem to understand well): Base (*p2)[3] = (Base (*)[3])new Derived[2][3]; // Presumption: no UB in cast. const Base& b = p2[0][1]; if (b.i) std::cout << "This is not possible!"; I'll also show you the correct code: Derived(*p2)[3] = new Derived[2][3]; const Base& b = p2[0][1]; if (b.i) std::cout << "This is not possible!"; Contradiction is: the only difference between these two snippets is the the cast^^^. If there's no UB in the cast, why doesn't first snippet work? Answer: cast is UB; by consequence, anything that follows is wrong. ^^^ Bar the use of Base type. But since e.g. "Base (*p2)[3] = new Derived[2][3];" doesn't even compile, that's immaterial. Goran.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-01 11:53 +0100 |
| Message-ID | <C8ilp.2233$Ir.2046@newsfe13.ams2> |
| In reply to | #2963 |
"Goran" <goran.pusic@gmail.com> wrote in message
news:b371e97b-2d73-4cb0-8f96-72f79f8fb61f@r13g2000yqk.googlegroups.com...
On Mar 31, 7:20 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Goran" <goran.pu...@gmail.com> wrote in message
>
> news:c59c6538-f590-41aa-8336-e44ce7315c8a@1g2000yqq.googlegroups.com...
> On Mar 31, 4:55 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
> > First things first. You do understand now that casts you tried to pull
> > off are UB, right?
>
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > What exactly is UB? Casting in general produces UB, or only when I cast?
>
> In your post
> here:http://groups.google.com/group/comp.lang.c++/msg/1948e01fd0971cac,
> I claimed that first two casts were UB. You claimed that they were
> not. I proved you that they were (read back, please).
>
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> You haven't proved anything is UB,
Yes I have. Read this again:
http://groups.google.com/group/comp.lang.c++/msg/e274c527afabc5f4
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
This is your code that is wrong not the cast. You cannot even explain what
is wrong with the cast in your opinion , its just wrong?
I provided the following code as an alternative which you snipped and
ignored. And you replaced it with your buggy shit code.
The following is the same C cast but in C++ style, is this also UB in your
mind?
template <typename T, int S>
T* foo(){
return static_cast<T*>(::operator new(S * sizeof(T)));
}
int main() {
int (*p)[6] = foo<int[6], 6>();
}
<Snip>
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-04-01 05:11 -0700 |
| Message-ID | <3bb28f62-1cc0-42a0-9d5a-0c7c9960b817@w36g2000vbi.googlegroups.com> |
| In reply to | #2964 |
On Apr 1, 12:53 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Goran" <goran.pu...@gmail.com> wrote in message
>
> news:b371e97b-2d73-4cb0-8f96-72f79f8fb61f@r13g2000yqk.googlegroups.com...
> On Mar 31, 7:20 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
>
>
> > "Goran" <goran.pu...@gmail.com> wrote in message
>
> >news:c59c6538-f590-41aa-8336-e44ce7315c8a@1g2000yqq.googlegroups.com...
> > On Mar 31, 4:55 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
> > > First things first. You do understand now that casts you tried to pull
> > > off are UB, right?
>
> > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > > What exactly is UB? Casting in general produces UB, or only when I cast?
>
> > In your post
> > here:http://groups.google.com/group/comp.lang.c++/msg/1948e01fd0971cac,
> > I claimed that first two casts were UB. You claimed that they were
> > not. I proved you that they were (read back, please).
>
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > You haven't proved anything is UB,
>
> Yes I have. Read this again:
>
> http://groups.google.com/group/comp.lang.c++/msg/e274c527afabc5f4
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> This is your code that is wrong not the cast.
Problem line is
Base (*p2)[3] = (Base (*)[3])new Derived[2][3];
and __you__ wrote it first.
I changed Base in a way that shows that your code won't work. But I
did not change the offending part.
It looks like you think that "not UB" means "seems to work on my
code"?
> You cannot even explain what
> is wrong with the cast in your opinion , its just wrong?
My explanation is fine compared to your lack of understanding what
"proof by contradiction" means.
> I provided the following code as an alternative which you snipped and
> ignored. And you replaced it with your buggy shit code.
Not true. Nothing in what __I__ wrote is wrong. Errors are in what
__you__ have written, that I took over. My purpose was clear: to show
you __how__ and __why__ what you wrote fails. You really seem to think
that "not UB" means "seems to work on my code".
> The following is the same C cast but in C++ style, is this also UB in your
> mind?
>
> template <typename T, int S>
> T* foo(){
> return static_cast<T*>(::operator new(S * sizeof(T)));}
>
> int main() {
> int (*p)[6] = foo<int[6], 6>();
>
> }
It does not matter whether cast is C or C++-style.
Yes, this is UB, and it's __much__ worse than your old examples. If
you try this on __any__ type that has a constructor, this is going to
fail __massively__. Just put e.g. this in your main:
std::string (*p)[6] = foo<string[6], 6>();
And watch this lunacy of yours fail.
You can legally use static_cast to go from void* to some other type,
that's OK, but that does not mean that code can't exhibit UB.
Goran.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-01 15:32 +0100 |
| Message-ID | <smllp.3208$7u3.2677@newsfe04.ams2> |
| In reply to | #2966 |
"Goran" <goran.pusic@gmail.com> wrote in message
news:3bb28f62-1cc0-42a0-9d5a-0c7c9960b817@w36g2000vbi.googlegroups.com...
On Apr 1, 12:53 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Goran" <goran.pu...@gmail.com> wrote in message
>
> news:b371e97b-2d73-4cb0-8f96-72f79f8fb61f@r13g2000yqk.googlegroups.com...
> On Mar 31, 7:20 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
>
>
> > "Goran" <goran.pu...@gmail.com> wrote in message
>
> >news:c59c6538-f590-41aa-8336-e44ce7315c8a@1g2000yqq.googlegroups.com...
> > On Mar 31, 4:55 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
> > > First things first. You do understand now that casts you tried to pull
> > > off are UB, right?
>
> > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > > What exactly is UB? Casting in general produces UB, or only when I
> > > cast?
>
> > In your post
> > here:http://groups.google.com/group/comp.lang.c++/msg/1948e01fd0971cac,
> > I claimed that first two casts were UB. You claimed that they were
> > not. I proved you that they were (read back, please).
>
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > You haven't proved anything is UB,
>
> Yes I have. Read this again:
>
> http://groups.google.com/group/comp.lang.c++/msg/e274c527afabc5f4
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> This is your code that is wrong not the cast.
Problem line is
Base (*p2)[3] = (Base (*)[3])new Derived[2][3];
and __you__ wrote it first.
I changed Base in a way that shows that your code won't work. But I
did not change the offending part.
It looks like you think that "not UB" means "seems to work on my
code"?
> You cannot even explain what
> is wrong with the cast in your opinion , its just wrong?
My explanation is fine compared to your lack of understanding what
"proof by contradiction" means.
> I provided the following code as an alternative which you snipped and
> ignored. And you replaced it with your buggy shit code.
Not true. Nothing in what __I__ wrote is wrong. Errors are in what
__you__ have written, that I took over. My purpose was clear: to show
you __how__ and __why__ what you wrote fails. You really seem to think
that "not UB" means "seems to work on my code".
> The following is the same C cast but in C++ style, is this also UB in your
> mind?
>
> template <typename T, int S>
> T* foo(){
> return static_cast<T*>(::operator new(S * sizeof(T)));}
>
> int main() {
> int (*p)[6] = foo<int[6], 6>();
>
> }
It does not matter whether cast is C or C++-style.
Yes, this is UB, and it's __much__ worse than your old examples. If
you try this on __any__ type that has a constructor, this is going to
fail __massively__. Just put e.g. this in your main:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
It's your use of the code that produces undefined behaviour, this code is
identical to the code used in std::allocator.
Just because you can use this code in a way that produces UB does not mean
the code itself produces UB.
If you theory was correct every container in the std lib would produce UB
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
std::string (*p)[6] = foo<string[6], 6>();
And watch this lunacy of yours fail.
You can legally use static_cast to go from void* to some other type,
that's OK, but that does not mean that code can't exhibit UB.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
As I said above you can make almost any code produce UB if you use it
incorrectly. It's not the code I posted that produces UB , its your
incorrect useage of the code.
If you think the code I posted produces UB then just compare that code to
the constructor in std::allocator. As the code is identical you must also
think std::allocator produces UB.
You call it lunacy but its your usage that is lunacy not the code from the
std lib.
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-04-01 11:24 -0700 |
| Message-ID | <74cf0a69-ad9e-421e-a74e-1d4590db3ba1@a12g2000yqk.googlegroups.com> |
| In reply to | #2973 |
On Apr 1, 4:32 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Goran" <goran.pu...@gmail.com> wrote in message
>
> news:3bb28f62-1cc0-42a0-9d5a-0c7c9960b817@w36g2000vbi.googlegroups.com...
> On Apr 1, 12:53 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
>
>
> > "Goran" <goran.pu...@gmail.com> wrote in message
>
> >news:b371e97b-2d73-4cb0-8f96-72f79f8fb61f@r13g2000yqk.googlegroups.com...
> > On Mar 31, 7:20 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
> > > "Goran" <goran.pu...@gmail.com> wrote in message
>
> > >news:c59c6538-f590-41aa-8336-e44ce7315c8a@1g2000yqq.googlegroups.com...
> > > On Mar 31, 4:55 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
> > > > First things first. You do understand now that casts you tried to pull
> > > > off are UB, right?
>
> > > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > > > What exactly is UB? Casting in general produces UB, or only when I
> > > > cast?
>
> > > In your post
> > > here:http://groups.google.com/group/comp.lang.c++/msg/1948e01fd0971cac,
> > > I claimed that first two casts were UB. You claimed that they were
> > > not. I proved you that they were (read back, please).
>
> > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > > You haven't proved anything is UB,
>
> > Yes I have. Read this again:
>
> >http://groups.google.com/group/comp.lang.c++/msg/e274c527afabc5f4
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > This is your code that is wrong not the cast.
>
> Problem line is
>
> Base (*p2)[3] = (Base (*)[3])new Derived[2][3];
>
> and __you__ wrote it first.
>
> I changed Base in a way that shows that your code won't work. But I
> did not change the offending part.
>
> It looks like you think that "not UB" means "seems to work on my
> code"?
>
> > You cannot even explain what
> > is wrong with the cast in your opinion , its just wrong?
>
> My explanation is fine compared to your lack of understanding what
> "proof by contradiction" means.
>
> > I provided the following code as an alternative which you snipped and
> > ignored. And you replaced it with your buggy shit code.
>
> Not true. Nothing in what __I__ wrote is wrong. Errors are in what
> __you__ have written, that I took over. My purpose was clear: to show
> you __how__ and __why__ what you wrote fails. You really seem to think
> that "not UB" means "seems to work on my code".
>
> > The following is the same C cast but in C++ style, is this also UB in your
> > mind?
>
> > template <typename T, int S>
> > T* foo(){
> > return static_cast<T*>(::operator new(S * sizeof(T)));}
>
> > int main() {
> > int (*p)[6] = foo<int[6], 6>();
>
> > }
>
> It does not matter whether cast is C or C++-style.
>
> Yes, this is UB, and it's __much__ worse than your old examples. If
> you try this on __any__ type that has a constructor, this is going to
> fail __massively__. Just put e.g. this in your main:
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> It's your use of the code that produces undefined behaviour, this code is
> identical to the code used in std::allocator.
... In some implementation you saw somewhere, you mean, right? Cause I
don't think standard prescribes exact code for
std::allocator::allocate.
> Just because you can use this code in a way that produces UB does not mean
> the code itself produces UB.
How do I know that your goal was to return uninitialized storage?
That's very unusual, clearly documented for allocator::allocate, and
in no way implied or visible by your code.
> If you theory was correct every container in the std lib would produce UB
I don't do theory. I do practice. I had no way of knowing that your
goal was to return uninitialized memory from "f". (In fact, I think
you didn't even realize what you did before reading my response). In
practice, you don't do that without clearly stating so. If you do, I
am glad you I don't work where you work. In practice, also, all
containers __construct__ objects in storage returned by
allocator::allocate (what, did you think otherwise!?).
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> std::string (*p)[6] = foo<string[6], 6>();
>
> And watch this lunacy of yours fail.
>
> You can legally use static_cast to go from void* to some other type,
> that's OK, but that does not mean that code can't exhibit UB.
>
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> As I said above you can make almost any code produce UB if you use it
> incorrectly. It's not the code I posted that produces UB , its your
> incorrect useage of the code.
My usage is just fine given the interface of "f". It returns T*. Why
__wouldn't__ I be able to use it with std::string? Answer: because
either code itself is bad, either it's intention is unclear or poorly
documented.
> If you think the code I posted produces UB then just compare that code to
> the constructor in std::allocator. As the code is identical you must also
> think std::allocator produces UB.
That conclusion is wrong and based on poor logic. No, I do not think
that allocator::allocate (one that does static_cast<T*>(::new(sizeof T
* n), which, I claim, is not __required__ by the standard) produces
UB, because I know that whatever it produces will be constructed
before reaching any other code, or else, implementation has a bug.
Your function, OTOH, spit out uninitialized storage as if it was
something people do as a matter of fact.
(By the way, there's no reason to mention any constructor. You are
clearly talking about allocator::allocate, and that does no
construction whatsoever).
Goran.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-02 01:55 +0100 |
| Message-ID | <1uulp.7571$5t2.4847@newsfe06.ams2> |
| In reply to | #2980 |
"Goran" <goran.pusic@gmail.com> wrote in message
news:74cf0a69-ad9e-421e-a74e-1d4590db3ba1@a12g2000yqk.googlegroups.com...
> > > > First things first. You do understand now that casts you tried to
> > > > pull
> > > > off are UB, right?
>
> > > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > > > What exactly is UB? Casting in general produces UB, or only when I
> > > > cast?
>
> > > In your post
> > > here:http://groups.google.com/group/comp.lang.c++/msg/1948e01fd0971cac,
> > > I claimed that first two casts were UB. You claimed that they were
> > > not. I proved you that they were (read back, please).
>
> > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > > You haven't proved anything is UB,
>
> > Yes I have. Read this again:
>
> >http://groups.google.com/group/comp.lang.c++/msg/e274c527afabc5f4
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > This is your code that is wrong not the cast.
>
> Problem line is
>
> Base (*p2)[3] = (Base (*)[3])new Derived[2][3];
>
> and __you__ wrote it first.
>
> I changed Base in a way that shows that your code won't work. But I
> did not change the offending part.
>
> It looks like you think that "not UB" means "seems to work on my
> code"?
>
> > You cannot even explain what
> > is wrong with the cast in your opinion , its just wrong?
>
> My explanation is fine compared to your lack of understanding what
> "proof by contradiction" means.
>
> > I provided the following code as an alternative which you snipped and
> > ignored. And you replaced it with your buggy shit code.
>
> Not true. Nothing in what __I__ wrote is wrong. Errors are in what
> __you__ have written, that I took over. My purpose was clear: to show
> you __how__ and __why__ what you wrote fails. You really seem to think
> that "not UB" means "seems to work on my code".
>
> > The following is the same C cast but in C++ style, is this also UB in
> > your
> > mind?
>
> > template <typename T, int S>
> > T* foo(){
> > return static_cast<T*>(::operator new(S * sizeof(T)));}
>
> > int main() {
> > int (*p)[6] = foo<int[6], 6>();
>
> > }
>
> It does not matter whether cast is C or C++-style.
>
> Yes, this is UB, and it's __much__ worse than your old examples. If
> you try this on __any__ type that has a constructor, this is going to
> fail __massively__. Just put e.g. this in your main:
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> It's your use of the code that produces undefined behaviour, this code is
> identical to the code used in std::allocator.
... In some implementation you saw somewhere, you mean, right? Cause I
don't think standard prescribes exact code for
std::allocator::allocate.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
You said this code produced UB , so even if it's only one implementation you
still say this particular implementation of the std lib produces UB.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Just because you can use this code in a way that produces UB does not mean
> the code itself produces UB.
How do I know that your goal was to return uninitialized storage?
That's very unusual, clearly documented for allocator::allocate, and
in no way implied or visible by your code.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Your argument is that an int* points to a single int and not to an array, or
have you forgotten that?
I have said that an int* can point to a single int or an array of int. I am
trying to show you that pointers can point to anything.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> If you theory was correct every container in the std lib would produce UB
I don't do theory. I do practice. I had no way of knowing that your
goal was to return uninitialized memory from "f". (In fact, I think
you didn't even realize what you did before reading my response). In
practice, you don't do that without clearly stating so. If you do, I
am glad you I don't work where you work. In practice, also, all
containers __construct__ objects in storage returned by
allocator::allocate (what, did you think otherwise!?).
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
No? well funnily enough thats what new does, it returns memory. Strange how
you couldn't work that out.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> std::string (*p)[6] = foo<string[6], 6>();
>
> And watch this lunacy of yours fail.
>
> You can legally use static_cast to go from void* to some other type,
> that's OK, but that does not mean that code can't exhibit UB.
>
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> As I said above you can make almost any code produce UB if you use it
> incorrectly. It's not the code I posted that produces UB , its your
> incorrect useage of the code.
My usage is just fine given the interface of "f". It returns T*. Why
__wouldn't__ I be able to use it with std::string? Answer: because
either code itself is bad, either it's intention is unclear or poorly
documented.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Your usage is not fine , it produces UB.
The code presented doesn't produceUB without your code. Its behaviour is
perfectly defined until your code is added.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> If you think the code I posted produces UB then just compare that code to
> the constructor in std::allocator. As the code is identical you must also
> think std::allocator produces UB.
That conclusion is wrong and based on poor logic. No, I do not think
that allocator::allocate (one that does static_cast<T*>(::new(sizeof T
* n), which, I claim, is not __required__ by the standard) produces
UB, because I know that whatever it produces will be constructed
before reaching any other code, or else, implementation has a bug.
Your function, OTOH, spit out uninitialized storage as if it was
something people do as a matter of fact.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
The code is perfectly legal and defined code, it can be used anywhere by any
procedure. Your incorrect usage produces UB not the code on its own.
If a piece of code allocates an array of Cats and you treat it like an array
of Dogs your code is wrong , not the code that creates the array of Cats.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
(By the way, there's no reason to mention any constructor. You are
clearly talking about allocator::allocate, and that does no
construction whatsoever).
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Whether its a constructor or not is irrelevant to the discussion, this is
simply an avoidance tactic to change the subject. You say this code produces
UB when it is actually YOUR code that produces the UB.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-04-02 23:32 -0700 |
| Message-ID | <45e5fa30-08c9-4301-b577-f4a1f7b64518@w7g2000yqe.googlegroups.com> |
| In reply to | #2984 |
On Apr 2, 2:55 am, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Goran" <goran.pu...@gmail.com> wrote in message
>
> news:74cf0a69-ad9e-421e-a74e-1d4590db3ba1@a12g2000yqk.googlegroups.com...
>
>
>
> > > > > First things first. You do understand now that casts you tried to
> > > > > pull
> > > > > off are UB, right?
>
> > > > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > > > > What exactly is UB? Casting in general produces UB, or only when I
> > > > > cast?
>
> > > > In your post
> > > > here:http://groups.google.com/group/comp.lang.c++/msg/1948e01fd0971cac,
> > > > I claimed that first two casts were UB. You claimed that they were
> > > > not. I proved you that they were (read back, please).
>
> > > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > > > You haven't proved anything is UB,
>
> > > Yes I have. Read this again:
>
> > >http://groups.google.com/group/comp.lang.c++/msg/e274c527afabc5f4
> > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > > This is your code that is wrong not the cast.
>
> > Problem line is
>
> > Base (*p2)[3] = (Base (*)[3])new Derived[2][3];
>
> > and __you__ wrote it first.
>
> > I changed Base in a way that shows that your code won't work. But I
> > did not change the offending part.
>
> > It looks like you think that "not UB" means "seems to work on my
> > code"?
>
> > > You cannot even explain what
> > > is wrong with the cast in your opinion , its just wrong?
>
> > My explanation is fine compared to your lack of understanding what
> > "proof by contradiction" means.
>
> > > I provided the following code as an alternative which you snipped and
> > > ignored. And you replaced it with your buggy shit code.
>
> > Not true. Nothing in what __I__ wrote is wrong. Errors are in what
> > __you__ have written, that I took over. My purpose was clear: to show
> > you __how__ and __why__ what you wrote fails. You really seem to think
> > that "not UB" means "seems to work on my code".
>
> > > The following is the same C cast but in C++ style, is this also UB in
> > > your
> > > mind?
>
> > > template <typename T, int S>
> > > T* foo(){
> > > return static_cast<T*>(::operator new(S * sizeof(T)));}
>
> > > int main() {
> > > int (*p)[6] = foo<int[6], 6>();
>
> > > }
>
> > It does not matter whether cast is C or C++-style.
>
> > Yes, this is UB, and it's __much__ worse than your old examples. If
> > you try this on __any__ type that has a constructor, this is going to
> > fail __massively__. Just put e.g. this in your main:
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > It's your use of the code that produces undefined behaviour, this code is
> > identical to the code used in std::allocator.
>
> ... In some implementation you saw somewhere, you mean, right? Cause I
> don't think standard prescribes exact code for
> std::allocator::allocate.
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> You said this code produced UB , so even if it's only one implementation you
> still say this particular implementation of the std lib produces UB.
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
No, your conclusion is wrong. The differences between your code and
the standard library one are:
* standard library won't ever pass said pointer to code that can use
it to produce UB
* standard library __in question__ knows that it's safe to go from
void* allocated from ::operator new to T*, because standard library is
tied to implementation. As far as I know, this passage is __not
guaranteed__ by the standard. The problem, obviously, are alignment
requirements of the platform (e.g. ::operator new returns pointers
aligned on 4-byte boundary, but e.g. double must be aligned on 8-byte
boundary, in which case the very cast inside f is UB).
> > Just because you can use this code in a way that produces UB does not mean
> > the code itself produces UB.
>
> How do I know that your goal was to return uninitialized storage?
> That's very unusual, clearly documented for allocator::allocate, and
> in no way implied or visible by your code.
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Your argument is that an int* points to a single int and not to an array, or
> have you forgotten that?
Irrelevant. Your question __here__ was if the code you offered was OK.
It wasn't (or at best, it was hardly OK).
> I have said that an int* can point to a single int or an array of int. I am
> trying to show you that pointers can point to anything.
Why, yes, they can, in hands of people like you, who cast nilly-willy
and claim that code is correct because they see it works, on code they
need, on implementation they need. Things are, however, slightly more
complicated and their very code might not work tomorrow on their very
implementation (like when they use "f" with std::string).
That said... In your code, "p" is int(*)[6]. Type-wise, f returns that
very same thing. You showed __nothing__ on the lines of your argument.
In addition, implementation of f is just bad, because it returns
uninitialized storage, and because it's implementation-dependent.
But fair enough. So your argument is that a pointer can point to __an
array__. If so, how do you explain what is happening here?
int a[2][2] = {1, 2, 3, 4};
int* p = a[0]; // By your argument, p points to an array, right?
assert(*p = 1); // OK;
p++;
assert(*p==2);
Now, hang on! p points to an array. I incremented p. Normally, when
you increment a pointer, it points to a next element. If p points to
an __array__ (a[0]), and I increment it, then it should point to a[1].
Yet, it doesn't. Why? Perhaps because p actually points to a __first
element__ of an array? (proof by contradiction, remember that?)
In other words... Saying that pointer points to an array leads to
surprising results when employing simple logic to pointers, array-to-
pointer conversion, pointer arithmetic and who knows what else. Saying
that is __choke full__ of contradictions (first of them obviously
being what pointer __type__ is).
People do say what you say ("p points to _that_ array"), and that's,
quite frankly, OK as far as ease of communication is concerned. What
is __implied__, however, is that pointer actually points to the first
element. Muddling waters like you're trying to do serves no-one.
Goran.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-03 13:21 +0100 |
| Message-ID | <SDZlp.2832$2W5.1941@newsfe16.ams2> |
| In reply to | #3016 |
"Goran" <goran.pusic@gmail.com> wrote in message
news:45e5fa30-08c9-4301-b577-f4a1f7b64518@w7g2000yqe.googlegroups.com...
> > > > > First things first. You do understand now that casts you tried to
> > > > > pull
> > > > > off are UB, right?
>
> > > > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > > > > What exactly is UB? Casting in general produces UB, or only when I
> > > > > cast?
>
> > > > In your post
> > > > here:http://groups.google.com/group/comp.lang.c++/msg/1948e01fd0971cac,
> > > > I claimed that first two casts were UB. You claimed that they were
> > > > not. I proved you that they were (read back, please).
>
> > > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > > > You haven't proved anything is UB,
>
> > > Yes I have. Read this again:
>
> > >http://groups.google.com/group/comp.lang.c++/msg/e274c527afabc5f4
> > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > > This is your code that is wrong not the cast.
>
> > Problem line is
>
> > Base (*p2)[3] = (Base (*)[3])new Derived[2][3];
>
> > and __you__ wrote it first.
>
> > I changed Base in a way that shows that your code won't work. But I
> > did not change the offending part.
>
> > It looks like you think that "not UB" means "seems to work on my
> > code"?
>
> > > You cannot even explain what
> > > is wrong with the cast in your opinion , its just wrong?
>
> > My explanation is fine compared to your lack of understanding what
> > "proof by contradiction" means.
>
> > > I provided the following code as an alternative which you snipped and
> > > ignored. And you replaced it with your buggy shit code.
>
> > Not true. Nothing in what __I__ wrote is wrong. Errors are in what
> > __you__ have written, that I took over. My purpose was clear: to show
> > you __how__ and __why__ what you wrote fails. You really seem to think
> > that "not UB" means "seems to work on my code".
>
> > > The following is the same C cast but in C++ style, is this also UB in
> > > your
> > > mind?
>
> > > template <typename T, int S>
> > > T* foo(){
> > > return static_cast<T*>(::operator new(S * sizeof(T)));}
>
> > > int main() {
> > > int (*p)[6] = foo<int[6], 6>();
>
> > > }
>
> > It does not matter whether cast is C or C++-style.
>
> > Yes, this is UB, and it's __much__ worse than your old examples. If
> > you try this on __any__ type that has a constructor, this is going to
> > fail __massively__. Just put e.g. this in your main:
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > It's your use of the code that produces undefined behaviour, this code
> > is
> > identical to the code used in std::allocator.
>
> ... In some implementation you saw somewhere, you mean, right? Cause I
> don't think standard prescribes exact code for
> std::allocator::allocate.
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> You said this code produced UB , so even if it's only one implementation
> you
> still say this particular implementation of the std lib produces UB.
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
No, your conclusion is wrong. The differences between your code and
the standard library one are:
* standard library won't ever pass said pointer to code that can use
it to produce UB
* standard library __in question__ knows that it's safe to go from
void* allocated from ::operator new to T*, because standard library is
tied to implementation. As far as I know, this passage is __not
guaranteed__ by the standard. The problem, obviously, are alignment
requirements of the platform (e.g. ::operator new returns pointers
aligned on 4-byte boundary, but e.g. double must be aligned on 8-byte
boundary, in which case the very cast inside f is UB).
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Its up to you to use the code responsibly. According, to you every piece of
code that is breakable would produce UB.
It was clear what the piece of code posted did. You, either deliberately or
unknowingly, used this code inappropriately to produce an error.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > Just because you can use this code in a way that produces UB does not
> > mean
> > the code itself produces UB.
>
> How do I know that your goal was to return uninitialized storage?
> That's very unusual, clearly documented for allocator::allocate, and
> in no way implied or visible by your code.
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Your argument is that an int* points to a single int and not to an array,
> or
> have you forgotten that?
Irrelevant. Your question __here__ was if the code you offered was OK.
It wasn't (or at best, it was hardly OK).
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Yes quite true , your argument is quite irrelevant.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> I have said that an int* can point to a single int or an array of int. I
> am
> trying to show you that pointers can point to anything.
Why, yes, they can, in hands of people like you, who cast nilly-willy
and claim that code is correct because they see it works, on code they
need, on implementation they need. Things are, however, slightly more
complicated and their very code might not work tomorrow on their very
implementation (like when they use "f" with std::string).
That said... In your code, "p" is int(*)[6]. Type-wise, f returns that
very same thing. You showed __nothing__ on the lines of your argument.
In addition, implementation of f is just bad, because it returns
uninitialized storage, and because it's implementation-dependent.
But fair enough. So your argument is that a pointer can point to __an
array__. If so, how do you explain what is happening here?
int a[2][2] = {1, 2, 3, 4};
int* p = a[0]; // By your argument, p points to an array, right?
assert(*p = 1); // OK;
p++;
assert(*p==2);
Now, hang on! p points to an array. I incremented p. Normally, when
you increment a pointer, it points to a next element. If p points to
an __array__ (a[0]), and I increment it, then it should point to a[1].
Yet, it doesn't. Why? Perhaps because p actually points to a __first
element__ of an array? (proof by contradiction, remember that?)
In other words... Saying that pointer points to an array leads to
surprising results when employing simple logic to pointers, array-to-
pointer conversion, pointer arithmetic and who knows what else. Saying
that is __choke full__ of contradictions (first of them obviously
being what pointer __type__ is).
People do say what you say ("p points to _that_ array"), and that's,
quite frankly, OK as far as ease of communication is concerned. What
is __implied__, however, is that pointer actually points to the first
element. Muddling waters like you're trying to do serves no-one.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Its not me you argue agaisnt , its the C++ language. It doesn't matter how
much you try to explian how you think the type system works, if you had any
clue you'd understand that the asm PTR directive doesn't define what is
pointed to, and the C++ type doesn't define what is pointed to.
If you treat a pointer to an array, as if it doesn't point to an array then
you are going to make mistakes. And its your codes' bad use of pointers that
is erroneous here.
My original question was:
Suppose I have the following code:
int (*p)[5] = (int (*)[5])new int[5];
How do I delete the allocated memory?
Now you said this code produced UB , and I have asked you to ellaborate,
where exactly is the UB?
You have answered this by adding some of your own code that uses my code
irresponsibly but that is your code that causes the error , not my code.
The said pointer type points to a 1d array, but its type suggests it points
to a 2d array or the &address of a 1d array.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-04-04 02:47 -0700 |
| Message-ID | <7ee927dd-06d3-4bf9-a25d-b6ed47bf1f78@z37g2000vbl.googlegroups.com> |
| In reply to | #3022 |
On Apr 3, 2:21 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Goran" <goran.pu...@gmail.com> wrote in message
>
> news:45e5fa30-08c9-4301-b577-f4a1f7b64518@w7g2000yqe.googlegroups.com...
>
>
>
> > > > > > First things first. You do understand now that casts you tried to
> > > > > > pull
> > > > > > off are UB, right?
>
> > > > > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > > > > > What exactly is UB? Casting in general produces UB, or only when I
> > > > > > cast?
>
> > > > > In your post
> > > > > here:http://groups.google.com/group/comp.lang.c++/msg/1948e01fd0971cac,
> > > > > I claimed that first two casts were UB. You claimed that they were
> > > > > not. I proved you that they were (read back, please).
>
> > > > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > > > > You haven't proved anything is UB,
>
> > > > Yes I have. Read this again:
>
> > > >http://groups.google.com/group/comp.lang.c++/msg/e274c527afabc5f4
> > > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > > > This is your code that is wrong not the cast.
>
> > > Problem line is
>
> > > Base (*p2)[3] = (Base (*)[3])new Derived[2][3];
>
> > > and __you__ wrote it first.
>
> > > I changed Base in a way that shows that your code won't work. But I
> > > did not change the offending part.
>
> > > It looks like you think that "not UB" means "seems to work on my
> > > code"?
>
> > > > You cannot even explain what
> > > > is wrong with the cast in your opinion , its just wrong?
>
> > > My explanation is fine compared to your lack of understanding what
> > > "proof by contradiction" means.
>
> > > > I provided the following code as an alternative which you snipped and
> > > > ignored. And you replaced it with your buggy shit code.
>
> > > Not true. Nothing in what __I__ wrote is wrong. Errors are in what
> > > __you__ have written, that I took over. My purpose was clear: to show
> > > you __how__ and __why__ what you wrote fails. You really seem to think
> > > that "not UB" means "seems to work on my code".
>
> > > > The following is the same C cast but in C++ style, is this also UB in
> > > > your
> > > > mind?
>
> > > > template <typename T, int S>
> > > > T* foo(){
> > > > return static_cast<T*>(::operator new(S * sizeof(T)));}
>
> > > > int main() {
> > > > int (*p)[6] = foo<int[6], 6>();
>
> > > > }
>
> > > It does not matter whether cast is C or C++-style.
>
> > > Yes, this is UB, and it's __much__ worse than your old examples. If
> > > you try this on __any__ type that has a constructor, this is going to
> > > fail __massively__. Just put e.g. this in your main:
> > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > > It's your use of the code that produces undefined behaviour, this code
> > > is
> > > identical to the code used in std::allocator.
>
> > ... In some implementation you saw somewhere, you mean, right? Cause I
> > don't think standard prescribes exact code for
> > std::allocator::allocate.
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > You said this code produced UB , so even if it's only one implementation
> > you
> > still say this particular implementation of the std lib produces UB.
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> No, your conclusion is wrong. The differences between your code and
> the standard library one are:
>
> * standard library won't ever pass said pointer to code that can use
> it to produce UB
> * standard library __in question__ knows that it's safe to go from
> void* allocated from ::operator new to T*, because standard library is
> tied to implementation. As far as I know, this passage is __not
> guaranteed__ by the standard. The problem, obviously, are alignment
> requirements of the platform (e.g. ::operator new returns pointers
> aligned on 4-byte boundary, but e.g. double must be aligned on 8-byte
> boundary, in which case the very cast inside f is UB).
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Its up to you to use the code responsibly. According, to you every piece of
> code that is breakable would produce UB.
The problem is rather that, according to you, it's somehow OK to
return uninitialized storage under the guise of T*. It's not (or at
least, it has to be clearly stated).
> It was clear what the piece of code posted did. You, either deliberately or
> unknowingly, used this code inappropriately to produce an error.
Yes, it was deliberate. Because if you try to actually __construct__
objects in the storage you allocated, things do not go so well, now do
they? And if you don't construct, well, so you managed to legally cast
a void* pointer to T*, which is rather underwhelming. Your cast is
legal, which does not make code good (or interesting, for that
matter).
> Its not me you argue agaisnt , its the C++ language. It doesn't matter how
> much you try to explian how you think the type system works, if you had any
> clue you'd understand that the asm PTR directive doesn't define what is
> pointed to,
Oh, come on! asm PTR directive might exist in some assembler toolkit,
but it bears no relevance to the language. Even asm itself is
implementation-dependent. It also bears no relevance to malloc/free,
or any operator new. Why are you mentioning that?
> and the C++ type doesn't define what is pointed to.
It does, and it's completely clear: T* points to an object of type T.
What are you on about!?
> If you treat a pointer to an array, as if it doesn't point to an array then
> you are going to make mistakes. And its your codes' bad use of pointers that
> is erroneous here.
Yes, but there's a purpose: it's to show you what your insistence on
saying that e.g. "p" in "p = new TYPE[s]" points to an array leads to.
It's just fraught with danger, and there's no practical purpose (or at
least, you failed to show one).
> My original question was:
> Suppose I have the following code:
>
> int (*p)[5] = (int (*)[5])new int[5];
>
> How do I delete the allocated memory?
And my original answer was: you allocated an array of ints, you should
call delete[] on the pointer to the first element of that array, which
was returned from "new. Easy as a pie. That is, your code should be:
int *p = new int[5];
delete [] p;
I have no idea why you want to use all these casts. You failed to
explain that. E.g. example you offered here:
http://groups.google.com/group/comp.lang.c++/msg/d0013eb81268f0ce
was pretty bad code, and you avoided to explain what you really
wanted. The other example, with Base and Derived, was also bad,
because it could only work when indexing a pointer to Base resulted in
a same value as when indexing a pointer to Derived> That is, I think,
implementation-dependent, and also rather constraining in practice.
Goran.
[toc] | [prev] | [next] | [standalone]
| From | "Paul" <pchristor@yahoo.co.uk> |
|---|---|
| Date | 2011-04-04 13:33 +0100 |
| Message-ID | <bUimp.25747$7u3.2549@newsfe04.ams2> |
| In reply to | #3077 |
"Goran" <goran.pusic@gmail.com> wrote in message
news:7ee927dd-06d3-4bf9-a25d-b6ed47bf1f78@z37g2000vbl.googlegroups.com...
On Apr 3, 2:21 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Goran" <goran.pu...@gmail.com> wrote in message
>
> news:45e5fa30-08c9-4301-b577-f4a1f7b64518@w7g2000yqe.googlegroups.com...
>
>
>
> > > > > > First things first. You do understand now that casts you tried
> > > > > > to
> > > > > > pull
> > > > > > off are UB, right?
>
> > > > > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > > > > > What exactly is UB? Casting in general produces UB, or only when
> > > > > > I
> > > > > > cast?
>
> > > > > In your post
> > > > > here:http://groups.google.com/group/comp.lang.c++/msg/1948e01fd0971cac,
> > > > > I claimed that first two casts were UB. You claimed that they were
> > > > > not. I proved you that they were (read back, please).
>
> > > > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > > > > You haven't proved anything is UB,
>
> > > > Yes I have. Read this again:
>
> > > >http://groups.google.com/group/comp.lang.c++/msg/e274c527afabc5f4
> > > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > > > This is your code that is wrong not the cast.
>
> > > Problem line is
>
> > > Base (*p2)[3] = (Base (*)[3])new Derived[2][3];
>
> > > and __you__ wrote it first.
>
> > > I changed Base in a way that shows that your code won't work. But I
> > > did not change the offending part.
>
> > > It looks like you think that "not UB" means "seems to work on my
> > > code"?
>
> > > > You cannot even explain what
> > > > is wrong with the cast in your opinion , its just wrong?
>
> > > My explanation is fine compared to your lack of understanding what
> > > "proof by contradiction" means.
>
> > > > I provided the following code as an alternative which you snipped
> > > > and
> > > > ignored. And you replaced it with your buggy shit code.
>
> > > Not true. Nothing in what __I__ wrote is wrong. Errors are in what
> > > __you__ have written, that I took over. My purpose was clear: to show
> > > you __how__ and __why__ what you wrote fails. You really seem to think
> > > that "not UB" means "seems to work on my code".
>
> > > > The following is the same C cast but in C++ style, is this also UB
> > > > in
> > > > your
> > > > mind?
>
> > > > template <typename T, int S>
> > > > T* foo(){
> > > > return static_cast<T*>(::operator new(S * sizeof(T)));}
>
> > > > int main() {
> > > > int (*p)[6] = foo<int[6], 6>();
>
> > > > }
>
> > > It does not matter whether cast is C or C++-style.
>
> > > Yes, this is UB, and it's __much__ worse than your old examples. If
> > > you try this on __any__ type that has a constructor, this is going to
> > > fail __massively__. Just put e.g. this in your main:
> > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> > > It's your use of the code that produces undefined behaviour, this code
> > > is
> > > identical to the code used in std::allocator.
>
> > ... In some implementation you saw somewhere, you mean, right? Cause I
> > don't think standard prescribes exact code for
> > std::allocator::allocate.
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > You said this code produced UB , so even if it's only one implementation
> > you
> > still say this particular implementation of the std lib produces UB.
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> No, your conclusion is wrong. The differences between your code and
> the standard library one are:
>
> * standard library won't ever pass said pointer to code that can use
> it to produce UB
> * standard library __in question__ knows that it's safe to go from
> void* allocated from ::operator new to T*, because standard library is
> tied to implementation. As far as I know, this passage is __not
> guaranteed__ by the standard. The problem, obviously, are alignment
> requirements of the platform (e.g. ::operator new returns pointers
> aligned on 4-byte boundary, but e.g. double must be aligned on 8-byte
> boundary, in which case the very cast inside f is UB).
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Its up to you to use the code responsibly. According, to you every piece
> of
> code that is breakable would produce UB.
The problem is rather that, according to you, it's somehow OK to
return uninitialized storage under the guise of T*. It's not (or at
least, it has to be clearly stated).
> It was clear what the piece of code posted did. You, either deliberately
> or
> unknowingly, used this code inappropriately to produce an error.
Yes, it was deliberate. Because if you try to actually __construct__
objects in the storage you allocated, things do not go so well, now do
they? And if you don't construct, well, so you managed to legally cast
a void* pointer to T*, which is rather underwhelming. Your cast is
legal, which does not make code good (or interesting, for that
matter).
> Its not me you argue agaisnt , its the C++ language. It doesn't matter how
> much you try to explian how you think the type system works, if you had
> any
> clue you'd understand that the asm PTR directive doesn't define what is
> pointed to,
Oh, come on! asm PTR directive might exist in some assembler toolkit,
but it bears no relevance to the language. Even asm itself is
implementation-dependent. It also bears no relevance to malloc/free,
or any operator new. Why are you mentioning that?
> and the C++ type doesn't define what is pointed to.
It does, and it's completely clear: T* points to an object of type T.
What are you on about!?
> If you treat a pointer to an array, as if it doesn't point to an array
> then
> you are going to make mistakes. And its your codes' bad use of pointers
> that
> is erroneous here.
Yes, but there's a purpose: it's to show you what your insistence on
saying that e.g. "p" in "p = new TYPE[s]" points to an array leads to.
It's just fraught with danger, and there's no practical purpose (or at
least, you failed to show one).
> My original question was:
> Suppose I have the following code:
>
> int (*p)[5] = (int (*)[5])new int[5];
>
> How do I delete the allocated memory?
And my original answer was: you allocated an array of ints, you should
call delete[] on the pointer to the first element of that array, which
was returned from "new. Easy as a pie. That is, your code should be:
int *p = new int[5];
delete [] p;
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
No, All you said was that is was UB.
[toc] | [prev] | [next] | [standalone]
| From | Goran <goran.pusic@gmail.com> |
|---|---|
| Date | 2011-04-04 11:06 -0700 |
| Message-ID | <549af0b7-ad06-4525-a820-be05a7dbe240@w7g2000yqe.googlegroups.com> |
| In reply to | #3080 |
On Apr 4, 2:33 pm, "Paul" <pchris...@yahoo.co.uk> wrote: > > My original question was: > > Suppose I have the following code: > > > int (*p)[5] = (int (*)[5])new int[5]; > > > How do I delete the allocated memory? > > And my original answer was: you allocated an array of ints, you should > call delete[] on the pointer to the first element of that array, which > was returned from "new. Easy as a pie. That is, your code should be: > > int *p = new int[5]; > delete [] p; > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > No, All you said was that is was UB. Not true. This: http://groups.google.com/group/comp.lang.c++/msg/b8ed179f99440d11 was my first response to your question. Goran.
[toc] | [prev] | [next] | [standalone]
Page 2 of 10 — ← Prev page 1 [2] 3 4 … 10 Next page →
Back to top | Article view | comp.lang.c++
csiph-web