MESSAGE
| DATE | 2015-02-07 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [LIU Comp Sci] [mrbrklyn@panix.com: (fwd) Re: why not use naked delete ?]
|
From owner-learn-outgoing-at-mrbrklyn.com Sat Feb 7 19:48:40 2015
Return-Path:
X-Original-To: archive-at-mrbrklyn.com
Delivered-To: archive-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix)
id 5598F16116B; Sat, 7 Feb 2015 19:48:40 -0500 (EST)
Delivered-To: learn-outgoing-at-mrbrklyn.com
Received: by mrbrklyn.com (Postfix, from userid 28)
id 4684A161170; Sat, 7 Feb 2015 19:48:40 -0500 (EST)
Delivered-To: learn-at-nylxs.com
Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89])
by mrbrklyn.com (Postfix) with ESMTP id B4E7316116B
for ; Sat, 7 Feb 2015 19:48:39 -0500 (EST)
Received: from panix2.panix.com (panix2.panix.com [166.84.1.2])
by mailbackend.panix.com (Postfix) with ESMTP id A0B5413B3D
for ; Sat, 7 Feb 2015 19:48:39 -0500 (EST)
Received: by panix2.panix.com (Postfix, from userid 20529)
id 8FA8933CC8; Sat, 7 Feb 2015 19:48:39 -0500 (EST)
Date: Sat, 7 Feb 2015 19:48:39 -0500
From: Ruben Safir
To: learn-at-nylxs.com
Subject: [LIU Comp Sci] [mrbrklyn-at-panix.com: (fwd) Re: why not use naked delete ?]
Message-ID: <20150208004839.GC12868-at-panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: owner-learn-at-mrbrklyn.com
Precedence: bulk
Reply-To: learn-at-mrbrklyn.com
----- Forwarded message from Ruben Safir -----
Date: Fri, 6 Feb 2015 20:08:57 -0500 (EST)
From: Ruben Safir ,
To: mrbrklyn-at-panix.com
Subject: (fwd) Re: why not use naked delete ?
User-Agent: tin/2.0.0-20110823 ("Ardenistiel") (UNIX) (NetBSD/6.1.5 (i386))
-- forwarded message --
Path: reader1.panix.com!panix!goblin1!goblin.stu.neva.ru!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Bo Persson
Newsgroups: comp.lang.c++
Subject: Re: why not use naked delete ?
Date: Fri, 26 Dec 2014 13:11:54 +0100
Lines: 51
Message-ID:
References: <549d3f6c$0$280$14726298-at-news.sunsite.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: individual.net E9KmqUx2kN+f8h8nwpOtdgxzdcchQUb4IghzMEE33w+kKzSXB3
Cancel-Lock: sha1:WoFub1wZs9BJ1cFNhpRoZIpIbPo=
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
In-Reply-To: <549d3f6c$0$280$14726298-at-news.sunsite.dk>
Xref: panix comp.lang.c++:1111871
On 2014-12-26 11:58, arnuld wrote:
> After 5 years of working purely in C, finally I becawe jobless and have
> some time on my hands to start C++. Well, I kept on peeking into
> stroustrup from time to time but now I see with C++14 everything has
> changed. Even in C++, I will allocate memory using /new/ and then free it
> using /delete/ but now I see Stroustrup does not seem to agree to that:
>
> http://isocpp.org/blog/2014/12/myths-2
>
> He is calling it naked delete. I know there lot of other examples he has
> given but those are using generic/oo programming(half of that code is
> incomprehensible to me because IU just started C++ today). I am more
> concerned with simple procedural subset of C++:
>
> X* p = new X;
> X* q = p;
> delete p;
> // ...
> q->do_something(); // the memory that held *p may have been re-used
>
> STROUSTRUP: Don?t do that. Naked deletes are dangerous
>
> ARNULD: then what I should do ?
>
> Can someone point me to some direction in understanding this ?
>
>
Another part of the advice is not to use naked pointers either. :-)
Stroustrup shows how to use a unique_ptr when you need a single pointer
to an object. There is also a shared_ptr for when you want to share
ownership of the object. In both cases, the object is automagically
deleted when the last pointer goes away.
You could do:
auto p = std::make_shared();
auto q = p;
// do something that invalidates p
q->do_something(); // q is still valid here
Bo Persson
-- end of forwarded message --
----- End forwarded message -----
|
|
