Prev: Seeking recommendation on free or cheap C++ compiler
Next: shared_ptr declaration in if-statement ?
From: Seungbeom Kim on 12 Nov 2009 09:11
Neil Butterworth wrote:
> 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.

Expected and designed double-deletes are fine, of course.

> 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.

Sure, that is an important use case of pointers -- manual control of
the lifetime. If the lifetime is deterministic, you can just declare
a variable of that object type without any pointer involved.

> 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.

It's most common for member variables, but it doesn't happen necessarily
for member variables; it could happen also inside a function.

I would neither call "no NULLing" a "rule", nor make an "exception"
about it, because that would make things too rigid. Do whatever you
need in the most efficient form, but not more than what's needed; if
you want to examine the pointer later, setting it to NULL can be useful.

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

Of course. In fact, using a smart pointer makes the OP's question
rather irrelevant, because the smart pointer manages its internals
by itself and you don't have a choice about NULLing.

--
Seungbeom Kim

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

From: Pete Becker on 13 Nov 2009 16:20
Neil Butterworth wrote:
> 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.
>

Well, sure: NULL is often used to indicate "no resource", and that's
fine if it's been designed into the program's logic. When it comes in
through the back door as an attempt to work around a logic error, it's
treating a symptom and not the cause.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)

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

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