Am I crazy to recreate a tiny garbage collection system inside my functions?

Question

I have some (C++) functions each containing several calls creating similar arrays of the same basic type on the heap. At various points in these functions, I may need to throw an exception. Keeping track of which arrays have been deleted is a pain, and quite error prone, so I was thinking about just adding the array pointers to a Set<ArrType*>, of which I can just delete every item when I catch an exception, like this:

try
{
   set<ArrType*> sHeap;
   ArrType* myArr = new ArrType[5];
   sHeap.Add(myArr);
   someExternalRoutine(myArr);
   ...
} 
catch(CString s)
{
   DeleteAllPointersInMyHeap(sHeap);
   throw(s);
}

It feels a bit like adding epicycles, but I can't get around the fact that any one of several external calls may throw an exception, and I need to definitely delete all the pointers allocated up to that point.

Is this just foolishness? Should I just add smaller try-catch blocks around the external calls? I'd still end up with little lists of delete A; delete B; delete D; after each one...

Answer 1

You should use a RAII techinque. You delegate the destruction to another object you create on the stack.

Then when that object goes out of scope it'll deallocate everything, no matter when it goes out of scope, even with an exception.

Answer 2

Why not use a smart pointer like boost::shared_array or use a stack-allocated std::vector? For single allocations rather than array allocations, you could use boost::shared_ptr.

These implement the RAII for you. Even if you're re-using a concept like RAII, you're still reinventing the wheel if there's already a concrete implementation out there that satisfies your requirements.

Answer 3

You don't have to rely on garbage collection.

You have std::auto_ptr that provides pointer like syntax and wraps a dynamically allocated object. When destroyed, it automatically destroys the object it points to.

You could implement something similar for arrays.

Answer 4

Instead of

try
{
   set<ArrType*> sHeap;
   ArrType* myArr = new ArrType[5];
   sHeap.Add(myArr);
   someExternalRoutine(myArr);
   ...
}

You just need:

{
   std::vector <ArrType> myArr(5);
   someExternalRoutine(myArr);
}

with no catch block. All allocation and deallocation (whether exceptions are thrown or not) will be handled for you - this is RAII.

Answer 5

This is a fine idea, although your implementation is a bit unwieldy. How about:

template <class T>
class Garbage
{
    std::vector<T *> v;

    Garbage(const Garbage &);
    Garbage operator=(const Garbage &);

public:
    Garbage() {}

    ~Garbage()
    {
        for (std::vector<T *>::iterator i = v.begin(); 
             i != v.end(); ++i) delete *i;
    }

    void swap(Garbage<T> &other)
    {
        v.swap(other.v);
    }

    T *remember(T *i)
    {
        v.push_back(i);
        return i;
    }

    void forget(T *i)
    {
        v.erase(std::remove(v.begin(), v.end(), i), v.end());
    }
};

Usage:

Garbage<Thing> g;

Thing *t1 = g.remember(new Thing());

Thing *t2 = g.remember(new Thing());

// decide we want to keep t1:
g.forget(t1);

Answer 6

Looks like you are overthinking it.

Rather than useing try {} catch {} use the RAII.
There are several ways to do this looking through the comments (all seem valid).

Option 1:
If you just need a single fixed(or expanding set of ArrType).
Where the lifespan ends at the end of the function

std::vector<ArrType>

Option 2:
If you need multiple arrays of ArrType Where the lifespan ends at the end of the function

boost::ptr_vector<ArrType>

This also allows you to remove the array from the ptr_vector when the object has a longer lifespan.

Notes on try {} catch {}

• Catch by ref
  • If you catch by a specific type you are suseptable to the slicing problem as derived types are copy constructed into the variable defined in the catch expression.
• Prefer to catch by const ref
• When re-throwing use throw; (without the expression)
  • This will re-throw the original exception rather than copying the new exception into the place where the exception handling mechanism hides the exception during stack unwinding.