Item 6: Use delete on pointer members in destructors.
Most of the time, classes performing dynamic memory allocation will use new in the constructor(s) to allocate
the memory and will later use delete in the destructor to free up the memory. This isn't too difficult to get right
when you first write the class, provided, of course, that you remember to employ delete on all the members that
could have been assigned memory in any constructor.
However, the situation becomes more difficult as classes are maintained and enhanced, because the
programmers making the modifications to the class may not be the ones who wrote the class in the first place.
Under those conditions, it's easy to forget that adding a pointer member almost always requires each of the
following:
Initialization of the pointer in each of the constructors. If no memory is to be allocated to the pointer in a
particular constructor, the pointer should be initialized to 0 (i.e., the null pointer).
Deletion of the existing memory and assignment of new memory in the assignment operator. (See also Item
17.)
Deletion of the pointer in the destructor.
If you forget to initialize a pointer in a constructor, or if you forget to handle it inside the assignment operator,
the problem usually becomes apparent fairly quickly, so in practice those issues don't tend to plague you. Failing
to delete the pointer in the destructor, however, often exhibits no obvious external symptoms. Instead, it
manifests itself as a subtle memory leak, a slowly growing cancer that will eventually devour your address
space and drive your program to an early demise. Because this particular problem doesn't usually call attention
to itself, it's important that you keep it in mind whenever you add a pointer member to a class.
Note, by the way, that deleting a null pointer is always safe (it does nothing). Thus, if you write your
constructors, your assignment operators, and your other member functions such that each pointer member of the
class is always either pointing to valid memory or is null, you can merrily delete away in the destructor without
regard for whether you ever used new for the pointer in question.
There's no reason to get fascist about this Item. For example, you certainly don't want to use delete on a pointer
that wasn't initialized via new, and, except in the case of smart pointer objects (see Item M28), you almost never
want to delete a pointer that was passed to you in the first place. In other words, your class destructor usually
shouldn't be using delete unless your class members were the ones who used new in the first place.
Speaking of smart pointers, one way to avoid the need to delete pointer members is to replace those members
with smart pointer objects like the standard C++ Library's auto_ptr.
Most of the time, classes performing dynamic memory allocation will use new in the constructor(s) to allocate
the memory and will later use delete in the destructor to free up the memory. This isn't too difficult to get right
when you first write the class, provided, of course, that you remember to employ delete on all the members that
could have been assigned memory in any constructor.
However, the situation becomes more difficult as classes are maintained and enhanced, because the
programmers making the modifications to the class may not be the ones who wrote the class in the first place.
Under those conditions, it's easy to forget that adding a pointer member almost always requires each of the
following:
Initialization of the pointer in each of the constructors. If no memory is to be allocated to the pointer in a
particular constructor, the pointer should be initialized to 0 (i.e., the null pointer).
Deletion of the existing memory and assignment of new memory in the assignment operator. (See also Item
17.)
Deletion of the pointer in the destructor.
If you forget to initialize a pointer in a constructor, or if you forget to handle it inside the assignment operator,
the problem usually becomes apparent fairly quickly, so in practice those issues don't tend to plague you. Failing
to delete the pointer in the destructor, however, often exhibits no obvious external symptoms. Instead, it
manifests itself as a subtle memory leak, a slowly growing cancer that will eventually devour your address
space and drive your program to an early demise. Because this particular problem doesn't usually call attention
to itself, it's important that you keep it in mind whenever you add a pointer member to a class.
Note, by the way, that deleting a null pointer is always safe (it does nothing). Thus, if you write your
constructors, your assignment operators, and your other member functions such that each pointer member of the
class is always either pointing to valid memory or is null, you can merrily delete away in the destructor without
regard for whether you ever used new for the pointer in question.
There's no reason to get fascist about this Item. For example, you certainly don't want to use delete on a pointer
that wasn't initialized via new, and, except in the case of smart pointer objects (see Item M28), you almost never
want to delete a pointer that was passed to you in the first place. In other words, your class destructor usually
shouldn't be using delete unless your class members were the ones who used new in the first place.
Speaking of smart pointers, one way to avoid the need to delete pointer members is to replace those members
with smart pointer objects like the standard C++ Library's auto_ptr.
Comments
Post a Comment
https://gengwg.blogspot.com/