How to Make Custom Deleters More Expressive
Most of the times where we use std::unique_ptr, we’re fine without using a custom deleter. But sometimes, a custom deleter offers a way out of a tricky situation.
Now that we’ve seen how to use custom deleters and when they can be useful, I would like to share with you a technique to make their usage more expressive that our regular reader Sergio Adán showed, in reaction to the previous article.
When I read it I slapped my forehead and went “why didn’t I code like this, each time I used a custom deleter??” Let’s see what this is about.
Custom deleters are ugly
Like we saw in Smart developers use smart pointers (ep 3), to set a deleter into a unique_ptr requires adding a function type in the unique_ptr, and the underlying pointer had better be const. For example, with the type Computer:
std::unique_ptr<const Computer, void(*)(const Computer*)>;
But this is dense enough that looking at it too long is dangerous for your eyes. Spreading such an expression across production code is out of the question. So the natural way to go about this is to write an alias:
using ComputerConstPtr = std::unique_ptr<const Computer, void(*)(const Computer*)>;
which fares better in an interface:
void plugIn(ComputerConstPtr computer);
But the ugliness is still there when we create new instances of the unique_ptr because we have to pass a deleter each time:
ComputerConstPtr myComputer(new Computer, deleteComputer);
Where we defined deleters:
void deleteComputer(const Computer* computer){ delete computer;}
void doNotDeleteComputer(const Computer* computer){}
This poses three issues. The first one is that we shouldn’t have to specify anything in the case where we want the smart pointer to delete its resource. It’s what smart pointers are made for in the first place.
Granted, this one it particular because it could have to not delete its resource for some occurrences. But why would the nominal case of deleting it be burdened because of the special case?
The second issue appears with namespaces, and comes down to plain ugliness. Imagine that our Computer type was inside a nested namespace, like often in production code:
namespace store
{
namespace electronics
{
namespace gaming
{
class Computer
{
// ...
};
using ComputerConstPtr = std::unique_ptr<const Computer, void(*)(const Computer*)>;
void deleteComputer(const Computer* computer);
void doNotDeleteComputer(const Computer* computer);
}
}
}
And then at call site:
store::electronics::gaming::ComputerConstPtr myComputer(new store::electronics::gaming::Computer, store::electronics::gaming::deleteComputer);
This is a tough line of code. And for saying so little.
The last issue is that we define a delete and a doNotDelete function for each type on which we want to custom deleters. And even if their implementation has nothing specific to the type Computer, or any other type. However, note that even templating the deleters this way:
template<typename T>
void doDelete(const T* p)
{
delete p;
}
template<typename T>
void doNotDeleteComputer(const T* x)
{
}
…doesn’t make the code lighter. Indeed, we still need to specify the template type when instantiating the pointer:
store::electronics::gaming::ComputerConstPtr myComputer(new store::electronics::gaming::Computer, doDelete<store::electronics::gaming::Computer>);
A unique interface
Now here is what Sergio suggested, and that can fix the two above issues: use the same interface for all custom deleters on all types.
This can be defined in another namespace, a technical one. Let’s call this namespace util for the example. (I’ll use a slightly modified version of the comment’s initial code.)
Then in this namespace, we write all the common code that creates the custom unique_ptr. Let’s call this helper MakeConstUnique for instance. Here is all its code:
namespace util
{
template<typename T>
void doDelete(const T* p)
{
delete p;
}
template<typename T>
void doNotDelete(const T* x)
{
}
template<typename T>
using CustomUniquePtr = std::unique_ptr<const T, void(*)(const T*)>;
template<typename T>
auto MakeConstUnique(T* pointer)
{
return CustomUniquePtr<T>(pointer, doDelete<T>);
}
template<typename T>
auto MakeConstUniqueNoDelete(T* pointer)
{
return CustomUniquePtr<T>(pointer, doNotDelete<T>);
}
}
With this code, no need to define anything else to start using a unique_ptr on a particular type with custom deleters. For instance, to create an instance of a unique_ptr that does a delete of its resource when it gets out of scope, we write:
auto myComputer = util::MakeConstUnique(new store::electronics::gaming::Computer);
And to create one that does not delete its resource:
auto myComputer = util::MakeConstUniqueNoDelete(new store::electronics::gaming::Computer);
What is interesting about this interface is that:
- there is no longer any mention of
deletein the nominal case, - we can now use
auto, thanks to the return type ofMakeConstUnique.
Note that all this made us go down to one occurrence of the namespace of Computer, when we started with three:
store::electronics::gaming::ComputerConstPtr myComputer(new store::electronics::gaming::Computer, store::electronics::gaming::deleteComputer);
Specific deleters
Now what if, for some reason, we didn’t want to call delete on the class Computer, but a particular dedicated function? This can happen in types coming from C for example (but not only):
void deleteComputer(const Computer* computer)
{
specificFunctionThatFreesAComputer(computer);
}
To keep using MakeConstUnique with this type, we can totally specialize this template function for the type Computer. We could do this in the module defining Computer, by reopening the util namespace:
namespace util
{
template<>
auto MakeConstUnique(store::electronics::gaming::Computer* pointer)
{
return CustomUniquePtr<store::electronics::gaming::Computer>(pointer, specificFunctionThatFreesAComputer);
}
}
In this case, the client code probably doesn’t allocate its pointer with new either.
Whichever way, a resource gets to be disposed of
Let’s now test our interface, by adding a bit of logging in the Computer class:
class Computer
{
public:
explicit Computer(std::string&& id) : id_(std::move(id)){}
~Computer(){std::cout << id_ << " destroyed\n";}
private:
std::string id_;
};
And let’s pass both a resource on the heap and a resource on the stack to our interface:
store::electronics::gaming::Computer c("stack-based computer");
auto myHeapBasedComputer = util::MakeConstUnique(new store::electronics::gaming::Computer("heap-based computer"));
auto myStackBasedComputer = util::MakeConstUniqueNoDelete(&c);
When run this code outputs:
heap-based computer destroyed stack-based computer destroyed
A big thank you to Sergio for sharing this idea, that helps making custom deleters more expressive. And if, like Sergio, you want to react to something you read on Fluent C++, I’d love to hear what you have to say!
Related article:
Don't want to miss out ? Follow:
Share this post!
