A C++ smart unique_ptr uses exactly the same amount of memory as a\nregular pointer, and has zero runtime cost. That is what we love about C++.
But what if I need a custom deleter for my pointer? Can I get it at zero cost too?
\n--- excerpt ---
\nSmart pointers are a major feature of C++11 that changed the way the language works.\nThey come in two versions: shared_ptr for shared ownership and unique_ptr for exclusive ownership.
In fact, unique_ptr represents an owning pointer. That's just like a good old\nT * pointer, except the compiler knows it owns its target, and will call delete for us\nas needed.
auto function(const std::string & x)\n{\n auto ptr = std::make_unique<Foo>(x);\n if (!someTest()) { throw Error(\"someTest failed\"); }\n return ptr;\n}And it does this with no overhead: a unique_ptr uses exactly the same amount of memory as a\nregular pointer, and has zero runtime cost. And that is what we love about C++.
I happen to have this amazing C library that I want to use:
\nstruct external_api {\n int data;\n // other api-relevant state\n};\n\nexternal_api * open_my_api()\n{\n external_api * api = malloc(sizeof(external_api));\n // initialize state here\n printf(\"External C api %p opened\\n\", api);\n return api;\n}\n\nvoid close_my_api(external_api * api)\n{\n free(api);\n printf(\"External C api %p closed\\n\", api);\n}\n\n// Plenty other functions using data in external_apiNothing complex so far. Assuming the header file is properly written, I can use it\nfrom C++ as usual:
\nvoid do_something()\n{\n auto * api = open_my_api();\n // do things using api\n close_my_api(api);\n}Great! Just be sure to close the api, we don't want to leak it. It's fine, we are all great\ndevelopers who would never forget the closing part. And will never recruit any intern or\nforgetful colleague. Wait… what happens if any operation in the do things part throws\nan exception?
\nNow would be a good time to review Herb Sutter's\nGuru of the Week #20 on code complexity.\nIt shows how a very simple function has 3 regular code paths and 20 invisible\nexceptional paths, many of which even experienced developers don't identify correctly.
Well… on exception we leak api. Not good.
In fact, we lost all the\nRAII\nsafety goodness that unique_ptr usually provides us.\nBut wait, api is a pointer to some allocated memory right? Why don't we use unique_ptr?
void do_something()\n{\n auto api = std::unique_ptr<external_api>(open_my_api());\n cout <<\" -> pointer size is \" <<sizeof(api) <<endl;\n // do things using api\n}$ ./attempt1\nExternal C api 0x56365fe89e70 opened\n -> pointer size is 8\nSegmentation faultunique_ptr — not quite what we expected.The issue of course, is unique_ptr is not aware of close_my_api() and attempts to clear\napi using delete. It may or may not crash on your system, depending on whether delete\nrelies on free under the hood. In any case, it will never invoke close_my_api().
But the template library has a solution: we can provide a custom deleter.
\nIndeed, the full signature of unique_ptr reads like this:
template<class T,\n class Deleter = std::default_delete<T>>\nclass unique_ptr;unique_ptr.So provided we fill in the correct template arguments, we can tell unique_ptr to use\nclose_my_api() instead of delete to clean up:
void do_something()\n{\n using Deleter = decltype(&close_my_api);\n auto api = std::unique_ptr<external_api, Deleter>(\n open_my_api(), close_my_api\n );\n cout <<\" -> pointer size is \" <<sizeof(api) <<endl;\n // do things using api\n}$ ./attempt2\nExternal C api 0x55f0667dee70 opened\n -> pointer size is 16\nExternal C api 0x55f0667dee70 closedunique_ptr.There is nothing wrong with this approach. It is correct and somewhat intuitive.\nIn fact, this approach is the one you\nusually\nfind on\nStackOverflow.
\nBut it is not zero-cost.1
\nThe size of the api pointer increased from 8 bytes to 16 bytes. That's a 100% increase.\nThe thing is we are now storing a copy of the address of close_my_api()\nin every unique_ptr. Which is a complete waste, since we know for sure all external_api\nobjects will always be deleted with close_my_api().
This is C++. We want zero-cost. Surely there must be a better way?
\nComing back to the template signature of unique_ptr, we notice it uses and odd\ndefault_delete default deleter. How about customizing its behavior, like\nthis answer suggests?
// INVALID - DO NOT DO THIS\ntemplate <> struct std::default_delete<external_api> {\n void operator()(external_api * ptr) { close_my_api(ptr); }\n};\n\nvoid do_something()\n{\n auto api = std::unique_ptr<external_api>(open_my_api());\n cout <<\" -> pointer size is \" <<sizeof(api) <<endl;\n // do things using api\n}std::default_delete. Do not try this at home.It would seem to work, except this is illegal. Although specializing default_delete\nis indeed allowed, it must follow the rules:
\n\nA program may add a template specialization […] only if […] the specialization meets the\nstandard library requirements for the original template.
\n
So what are the exact rules on default_delete::operator()? Section 20.8.1.1.2, item 3 reads:
\n\nEffects: calls delete on ptr.
\n
In other words: specializing default_delete is allowed only if the effects of the specialization are to call delete on the pointer.
➥ Thus our specialization does not meet the requirements for default_delete::operator(),\nand is not allowed by the C++ standard.
But we are on the right track.
\nInstead of hijacking std::default_delete, let's create our own.
As the existence of default_delete hints, the Deleter argument of unique_ptr actually\nallows function objects. That is, objects that behave as functions (supporting operator()).
This is exaclty what we will do. We use an empty object with just operator():
struct external_api_deleter {\n void operator()(external_api * ptr) const { close_my_api(ptr); }\n};\nusing api_ptr = std::unique_ptr<external_api, external_api_deleter>;\n\nvoid do_something()\n{\n auto api = api_ptr(open_my_api());\n cout <<\" -> pointer size is \" <<sizeof(api) <<endl;\n // do things using api\n}$ ./correct\nExternal C api 0x561c3a3fce70 opened\n -> pointer size is 8\nExternal C api 0x561c3a3fce70 closedSuccess!
\nOur unique_ptr calls close_my_api() correctly. Yet it does not store the pointer to it,\nas we can see from the final pointer size being 8 bytes.
What actually happens is that an instance of external_api_deleter is default-constructed\nand stored. As it is an empty class, this has perfect performance (this generates no\nassembly instruction). And thanks to\nempty base optimisation, is uses no storage\nat all.2
There we have it. Legal, correct, zero-cost deleter for unique_ptr.
I hope you enjoyed this post. I pushed the code of the examples\non github. Have a\nquestion? See an error? Send me a message!
\nIn addition, such a unique_ptr cannot be default-constructed, because the deleter\npointer must always be provided. This can be a minor inconvenience, or have a big impact.\nFor instance it prevents using map's operator[].
This is not guaranteed, but true in practice on all systems I tested this one.
\n↩\n