A C++ wrapper for Apple CoreFoundation The wrapper makes it easy to manage memory when using CoreFoundation objects. It aims to act like a simple shared_ptr.

Here is a usage example:

cfobject_wrapper&lt;CGImageSourceRef&gt; imgSource(CGImageSourceCreateWithData(...), false);
...
dispatch_async(..., ^{
  foo(imgSource);
});
// no need to manually call CFRelease, and the CGImageSourceRef is automatically retained when copied to block and released when the block is destroyed.


Here is the code of the wrapper:

/** A wrapper for Apple's Core Foundation objects */
template&lt;typename _T&gt;
class cfobject_wrapper final
{
protected:
  _T _internal;

public:
  cfobject_wrapper()
  : _internal(nullptr)
  {
  }

public:
  explicit cfobject_wrapper(const _T&amp; ref, bool retain = true)
  {
    if (ref &amp;&amp; retain)
      CFRetain(ref);
    _internal = ref;
  }

public:
  cfobject_wrapper(const cfobject_wrapper&lt;_T&gt;&amp; ref)
  : _internal(ref._internal)
  {
    if (_internal)
      CFRetain(_internal);
  }

public:
  cfobject_wrapper(cfobject_wrapper&lt;_T&gt;&amp;&amp; ref)
  {
    _internal = std::move(ref._internal);
    ref._internal = nullptr;
  }

public:
  cfobject_wrapper&amp; operator=(cfobject_wrapper other)
  {
    std::swap(_internal, other._internal);
    return *this;
  }

public:
  ~cfobject_wrapper()
  {
    if (_internal)
    {
      CFRelease(_internal);
      _internal = nullptr;
    }
  }

public:
  _T internal() const
  {
    return _internal;
  }

public:
  explicit operator bool() const
  {
    return _internal != nullptr;
  }

};
This is a really great idea! I could certainly use a class like this. Here are some thoughts:
Don't Multiply Declare public
It's very odd that you're prefixing every single method with its visibility. I really hate working with code that has multiple public, private or protected sections. I expect all public methods and members to be grouped together, all protected methods and members to be grouped together, and all private methods and members to be grouped together (usually in that order). While it's not required by the language, it's a pain to constantly have to figure out which section you're in when reading, and it's a pain to write it out for every method prototype when you're writing the code.
Avoid protected Member Variables
In general protected member variables are a bad idea. They essentially mean that any other object of the class or subclass can change their value out from under you. There's a case to be made for public member variables when performance is of the utmost importance, but in general member variables should be private so you can control who's changing them and when.
Retains and Releases Should Be Matched
It's a little surprising that I can tell the constructor not to retain the object, but the destructor will still release it. This is almost like a false cognate in another language - it looks similar to another pattern where you tell the constructor of some object that you're going to manually manage the memory for a given resource, so it shouldn't delete it when destructed. I understand the reason why - some CF methods return retained objects. Still, as someone potentially reading the code, it's a little unexpected. In Objective-C you could autorelease the value when calling the constructor and not worry about the retain, but there's no such mechanism for the C interface to CoreFoundation. Furthermore, the likelihood that I'll remember to pass false to the constructor when I can't remember to do the release manually is unlikely. For that reason, I recommend at least removing the default value. I'm also left wondering if there's some better way to handle this particular case. (I guess a first-class interface to CoreFoundation from C++ would be the ideal answer, but that's not going to happen unless you write it yourself.)