Prev: Seeking recommendation on free or cheap C++ compiler
Next: shared_ptr declaration in if-statement ?
From: Neil Butterworth on 12 Nov 2009 01:29
Seungbeom Kim wrote:
> I agree. When you encounter a double-delete problem that you didn't
> expect, the correct solution is not to make the double-delete innocuous
> by setting the pointer to null (which won't work in many cases as
> mentioned above, or which will just hide the problem at best), but
> to find out why it is happening even though it is not intended, and
> to fix it so that it won't happen again.

There are of course double deletes that you DO expect. I used to
subscribe to the "NULLing is a waste of time" rule, but have noticed
several occurrences of a pattern where an object is sometimes lazily
created using new and sometimes not. The object is also often deleted
before the end of the lifetime of a containing class instance. This
tends to happen for large, expensive objects. Simplified, such a class
looks like this:

struct A {
A() : ptr(0) {}
~A() { delete ptr; }
void foo() {
if ( something ) {
ptr = new X;
...
delete ptr;
ptr = NULL;
}
}
// other stuff
X * ptr;
};

Here, it makes sense (IMHO) to NULL the pointer after deleting it, in
order to avoid special case code in the destructor. So I'd modify the
"no NULLing" rule to add an exception for member variables.

Of course, using a smart pointer might be an even better approach, but
that is a slightly different issue.

Neil Butterworth


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Francis Glassborow on 12 Nov 2009 01:30
Andrey Tarasevich wrote:
> yodadrinkslager wrote:
>> I seem to remember reading through the C++ FAQ Lite and reading an
>> arguement against setting a pointer to NULL after delete. Is there
>> such an arguement or did I imagine the whole thing?
>
> Yes, there is.
>
> The popular legend about setting a pointer to null after `delete` is
> that is will allegedly make you safe you from the double-delete problem
> (i.e. when the same pointer value is passed to `delete` more than once).
>
> In reality, the _real_ double-delete problem occurs most of the time
> when the same memory block is `delete`d multiple times through two or
> more _different_ pointer objects holding the same address. Needless to
> say, setting a pointer to null after `delete` will achieve absolutely
> nothing to prevent the problem.
>
> While it is true that setting a pointer to null after `delete` might
> save you from double-delete through the same pointer, in reality in 9
> cases out of 10 such a situation indicates a more generic problem with
> the overall logic of the code. Treating it as a mere double-delete in
> general case will only threat a symptom of the problem, not the problem
> itself, i.e. it will just sweep the issue under the carpet.
>

In addition, these days we generally avoid manually deleting and leave
it to an encapsulating object (smart pointer, container etc.) to handle
destruction.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Bo Persson on 12 Nov 2009 09:07
Hakusa(a)gmail.com wrote:
> On Nov 11, 8:22 pm, Andrey Tarasevich <andreytarasev...(a)hotmail.com>
> wrote:
>
>>> Is there
>>> such an arguement or did I imagine the whole thing?
>
>> Yes, there is.
>
>> While it is true that setting a pointer to null after `delete`
>> might save you from double-delete through the same pointer, in
>> reality in 9 cases out of 10 such a situation indicates a more
>> generic problem with the overall logic of the code. Treating it as
>> a mere double-delete in general case will only threat a symptom of
>> the problem, not the problem itself, i.e. it will just sweep the
>> issue under the carpet.
>
> Are you presenting an argument against NULLing a pointer after
> delete, meaning doing so is completely useless, or simply saying
> that it's not a cure-all? You seem to claim (by "Yes, there is")
> that you present such an argument, but after reading it i still
> feel it's a good idea to null one's pointers, but that other
> precautions (such as using a smart pointer?) should be considered.
>
> Would you mind clarifying?

The argument agains NULLing is that it hardly ever helps.

The question is: Why do you delete the object and still keep the
pointer around? A pointer is cheap to create, so you don't have to
resuse it. Just let it go out of scope right after the delete.



Bo Persson



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Nevin :-] Liber on 12 Nov 2009 09:07
In article <hdgvgj$hmk$1(a)news.eternal-september.org>,
Neil Butterworth <nbutterworth1953(a)gmail.com> wrote:

> struct A {
> A() : ptr(0) {}
> ~A() { delete ptr; }
> void foo() {
> if ( something ) {
> ptr = new X;
> ...
> delete ptr;
> ptr = NULL;
> }
> }
> // other stuff
> X * ptr;
> };

Which is why the recommendation is to use a smart pointer instead.

That struct as written as two double delete bugs in it, caused by the
compiler generated copy constructor and assignment operator, which do
the wrong thing. It also has a memory leak if ptr already points to an
object when A::foo is called.

I would rewrite it using either std::auto_ptr, tr1::unique_ptr, or
boost::scoped_ptr, as in:

struct A
{
void foo() {
if ( something ) {
ptr.reset(new X);
...
}
}
// other stuff
boost::scoped_ptr<X> ptr;
};

This code is both (a) simpler and (b) correct.

Unless you are writing a smart pointer or a pointer owning collection
class (and the need for the latter should mostly go away with
unique_ptr), you should never be calling delete explicitly; code which
does so is just too error prone.

> Here, it makes sense (IMHO) to NULL the pointer after deleting it, in
> order to avoid special case code in the destructor.

And if you use a smart pointer, you don't even need to write a
destructor. It just works.

> So I'd modify the
> "no NULLing" rule to add an exception for member variables.
>
> Of course, using a smart pointer might be an even better approach, but
> that is a slightly different issue.

Why is it a different issue? It's the correct solution to this problem
in all but a handful of cases.

--
Nevin ":-)" Liber <mailto:nevin(a)eviloverlord.com> 773 961-1620

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Nevin :-] Liber on 12 Nov 2009 09:09
In article
<5729ceaa-dd76-451c-a955-ea5026e9d89e(a)g23g2000yqh.googlegroups.com>,
"Hakusa(a)gmail.com" <hakusa(a)gmail.com> wrote:

> Are you presenting an argument against NULLing a pointer after delete,
> meaning doing so is completely useless, or simply saying that it's not
> a cure-all?

The recommendation is to use a smart pointer class instead of explicitly
calling delete. The problem is moot at that point.

--
Nevin ":-)" Liber <mailto:nevin(a)eviloverlord.com> 773 961-1620

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Seeking recommendation on free or cheap C++ compiler
Next: shared_ptr declaration in if-statement ?