delete a pointer

[Jorgen Grahn]

What bugs will hide:

delete a;
a = NULL;

From what it will hide these? Sounds surprizing. It exposes bugs and
does not hide.

In a sense, you're right. I was thinking about memory debuggers like
valgrind being able to detect access to free memory, who did the
access, and who freed it. But such a tool would not be triggered I
think if the same memory area was allocated again, which is a likely
scenario.

I was probably also thinking of another practice I dislike: always
initializing variables, even though you have no sensible default:

int foo(int a) {
int b = 0; // not a meaningful return value
switch(a) {
case 1: b = 2; break;
case 2: b = 3; break;
// forgot the default
}
return b;
}

Which prevents both the compiler itself and valgrind from warning you.

You should explain how this rule is harmful.

I think others have by now, but in a nutshell:

1. I dislike rules which do not make sense when applied. In my code
it would look like this, which is clearly silly:

Foo::~Foo() {
delete a;
a = NULL;
}

2. Uh, I can't come up with a (2), because I can't come up with any
other real-world uses for new/delete. I use it really rarely.

Perhaps that's a good side effect of such a rule: that people try
to avoid manual memory management.

You talk too much about slavery, bending over, harmful and hurting
things. This is not some sort of sado-maso newsgroup.

Quite the opposite. I talk about being proud of one's work and having
a feeling of personal responsibility. But I should have chosen my words
differently.

/Jorgen

 

[Öö Tiib]

In a sense, you're right. I was thinking about memory debuggers like
valgrind being able to detect access to free memory, who did the
access, and who freed it.  But such a tool would not be triggered I
think if the same memory area was allocated again, which is a likely
scenario.

Yes. De-referencing null pointers is easier to detect. Where
dereferenced, where set to null. Even some static analysis tools
manage to do it. Valgrind still helps when some other pointer pointing
at same object was not set to null but was dereferenced.

I was probably also thinking of another practice I dislike: always
initializing variables, even though you have no sensible default:

  int foo(int a) {
     int b = 0; // not a meaningful return value
     switch(a) {
        case 1: b = 2; break;
        case 2: b = 3; break;
        // forgot the default
     }
     return b;
  }

Which prevents both the compiler itself and valgrind from warning you.

Sure. It clearly hides bugs. Also it is good example why SESE does not
make sense with C++. I would write same situation example (with my
style applied) like:

int foo( int a )
{
switch( a )
{
// comment 2 lines out to get compiler error
default:
BUG( bug::UnexpectedValue, a );
case 1:
return 2;
case 2:
return 3;
}
}

I think others have by now, but in a nutshell:

1. I dislike rules which do not make sense when applied. In my code
it would look like this, which is clearly silly:

   Foo::~Foo() {
      delete a;
      a = NULL;
   }

If the pointer is destroyed itself then there is no such rule. Like in
destructor, leaving scope, removed from map. As lot i have seen
policies demanding setting pointer to 0 then these also say same
thing. OP said that coworker commented he must set pointer to 0, so i
assumed it was none of such pointless cases.

2. Uh, I can't come up with a (2), because I can't come up with any
other real-world uses for new/delete.  I use it really rarely.

I use them where smart pointers/templates/std.containers have been
suggested for removal by performance analysis. Cost of speed is
usually well known to one who searches services of big C or C++ gang
of devs, so it happens not that infrequently. Being careful is
especially important with rarely used techniques (be it unions, raw
pointers, function or member pointers, bit-packed structure members,
bit-wise logic, pointer arithmetic etc.).

Perhaps that's a good side effect of such a rule: that people try
to avoid manual memory management.

Good rule. Lots of techniques are valid for optimizations only.
Optimizing without performance analyze demanding it should be
considered dangerous and wasteful.