Click here to Skip to main content
13,348,831 members (80,067 online)
Click here to Skip to main content
Add your own
alternative version


16 bookmarked
Posted 21 Mar 2004

A Functor that deletes Pointers from STL Sequence Containers

, 21 Mar 2004
Rate this:
Please Sign up or sign in to vote.
A policy based deletion functor that can be used with for_each function.


A great thing about STL containers is the way they automatically handle memory for us. By using standard sequence containers such as vector or deque instead of directly dealing with operators new[] and delete[], we avoid possibilities of memory leaks and make our code exception-safe. For instance, if we need a dynamic array of integers within a function, if we use std::vector<int> rather than int*, we would be relieved from worrying about calling delete to free up the memory before we exit the function:

vector<int> vectorArray (30); // the memory will be automatically freed
int* oldStyleArray = new int[30]; // be sure to call delete[] oldStyleArray;

However, things get more complicated if we put pointers into a standard container:

struct C
  char data_[50];
  vector <C*> dataArray;
for (int i = 0; i < 20 ; ++i)
  dataArray.push_back(new C());

After dataArray goes out of scope, only the memory occupied by the pointers itself will be freed, but the objects themselves will stay undeleted unless we do something like:

for (vector <C*>::iterator it = dataArray.begin(), 
  it != dataArray.end(); ++it)
  delete *it;

before dataArray goes out of scope.

The best way to deal with this issue is to never put raw pointers into containers, but to use smart pointers, such as boost::shared_ptr [1], or Loki::SmartPtr [2]:

vector <boost::shared_ptr<C> > dataArray;
for (int i = 0; i < 20 ; ++i)
  dataArray.push_back(boost::shared_ptr<C> (new C()));

Now, we won’t need to care about freeing up the objects.

However, in some instances we still may want to keep raw pointers in STL sequence containers, and in that case we may use some easier way to clean up the memory than hand-writing the loop. One common solution is to write a functor that would give us possibility of using an STL algorithm such as for_each [3].

for_each(dataArray.begin(), dataArray.end(), del_fun<C>());

This approach is better, but it still leaves a lot to be desired. For one thing, it always calls operator delete, which is not appropriate for the cases where the objects are created with new[] or malloc. Also, in some cases we may want to zero the pointers after we delete them.

To address these issues, I implemented a policy-based functor free_ptr.

Design of free_ptr

When using a functor for deleting objects, we are faced with two orthogonal decisions:

  1. Which function to use for deleting objects?
  2. Do we zero the pointers after deletions?

To give the user a choice to make the decisions, I used two separate policies: CleanUpPolicy and ZeroPtrPolicy:

template <typename T, class CleanUpPolicy = DeleteSingleObject, class 
ZeroPtrPolicy = DontZeroPtr>
struct free_ptr : std::unary_function <T*, void>
  void operator()(T*& ptr)

Thanks to the policy-based design, free_ptr is very simple to use, and yet highly customizable. For the most common scenario (single objects created with new, no need to zero pointers), it can be used like this:

for_each(dataArray.begin(), dataArray.end(), free_ptr<C>());

If the objects were created with new[], and we need to zero the pointers after deletion, we write something like:

for_each(dataArray.begin(), dataArray.end(), free_ptr<C, DeleteArray, 

For the CleanUpPolicy, we have the following choices:

  1. DeleteSingleObject (default) – calls delete for each pointer.
  2. DeleteArray – calls delete[] for each pointer.
  3. Free – calls free() for each pointer.

For the ZeroPtrPolicy, we have two choices:

  1. DontZeroPtr (default) – does nothing.
  2. ZeroPtr - sets each pointer to zero.

In ideal world, we would not even need CleanUpPolicy – if a pointer to a single object was a distinct type than a pointer to array of objects we could have used some template metaprogramming to recognize the right scenario at compile time. However, since this obviously is not the case, I tried to figure out some run-time mechanism to do that. I failed miserably: there does not seem to be a good way to distinguish whether a memory was allocated by new, new[] or malloc if we only have a pointer to this memory. I tried even some non-portable tricks, such as using _memsize to determine the size of the allocated memory block, however, even if we know the amount of allocated memory, it still does not necessarily shows us the number of objects pointed by the pointer. Therefore, the best I could come up with was CleanUpPolicy. One good thing with this solution is that in case of some custom memory-management schema, it would be very easy to write another CleanUpPolicy class and use it as easily as the ones I provided.

I should probably add that usage of free_ptr will not protect you from some bad programming practices. For instance, if you do something like:

vector <C*> dataArray;
dataArray.push_back(new C()); //single object

dataArray.push_back(new C[10]); //array of objects

dataArray.push_back((C*)malloc(sizeof(C))); // malloc-ed object

then free_ptr will not help you. As I said, it is unfortunate that the previous example will compile at all, but this is just another C-legacy that makes C++ less perfect.


I hope that this little article is useful in two ways: it demonstrates policy-based design, a powerful methodology for developing C++ libraries, and it also provides you with a cool little piece of code that you can find useful in your daily programming tasks.



This article, along with any associated source code and files, is licensed under The BSD License


About the Author

Nemanja Trifunovic
Software Developer (Senior) SAP
United States United States
Born in Kragujevac, Serbia. Now lives in Boston area with his wife and daughters.

Wrote his first program at the age of 13 on a Sinclair Spectrum, became a professional software developer after he graduated.

Very passionate about programming and software development in general.

You may also be interested in...

Comments and Discussions

GeneralRe: Small bug with for_each Pin
Nemanja Trifunovic16-Apr-04 5:52
memberNemanja Trifunovic16-Apr-04 5:52 
GeneralRe: Small bug with for_each Pin
iain_22-Apr-04 3:58
sussiain_22-Apr-04 3:58 
Questiontogether with Effective STL? Pin
seriema2-Apr-04 15:27
memberseriema2-Apr-04 15:27 
AnswerRe: together with Effective STL? Pin
Nemanja Trifunovic4-Apr-04 11:24
memberNemanja Trifunovic4-Apr-04 11:24 
GeneralSolution that allows map Pin
Summand25-Mar-04 11:46
memberSummand25-Mar-04 11:46 
GeneralRe: Solution that allows map Pin
Nemanja Trifunovic25-Mar-04 12:05
memberNemanja Trifunovic25-Mar-04 12:05 
GeneralRe: Solution that allows map Pin
Summand26-Mar-04 1:09
memberSummand26-Mar-04 1:09 
GeneralRe: Solution that allows map Pin
Simon Hughes28-Mar-04 22:48
memberSimon Hughes28-Mar-04 22:48 
GeneralI don't agree with your policy. Pin
WREY24-Mar-04 7:35
memberWREY24-Mar-04 7:35 
GeneralRe: I don't agree with your policy. Pin
Nemanja Trifunovic24-Mar-04 8:13
memberNemanja Trifunovic24-Mar-04 8:13 
GeneralFlexibility wins out !! Pin
WREY24-Mar-04 10:41
memberWREY24-Mar-04 10:41 
GeneralNice demonstration of policies Pin
thought23-Mar-04 23:20
memberthought23-Mar-04 23:20 
GeneralRe: Nice demonstration of policies Pin
Nemanja Trifunovic24-Mar-04 6:05
memberNemanja Trifunovic24-Mar-04 6:05 
Thanks for reading my article.

thought wrote:
you say that sometimes it is desireable to hold raw pointers instead of smart pointers in a standard container

I really said: in some instances we still may want to keep raw pointers in STL sequence containers Smile | :) . Reference-counted smart pointers incure some performance overhead, and for that reason some people don't like to use them. I would say that in most cases this performance penalty is neglible, but it really depends on the concrete situation.

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.180111.1 | Last Updated 22 Mar 2004
Article Copyright 2004 by Nemanja Trifunovic
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid