While C++98 had smart pointers of a sort; they weren\u00e2\u20ac\u2122t good enough for use. The language lacked the key feature that makes smart pointers work: move semantics. C++11 has introduced that language feature, and hence has solid smart pointers.<\/p>\n
The addition of smart pointers gives us some further options for passing references to objects when we\u00e2\u20ac\u2122re using C++11. These give us a way of expressing more specifically what a function wants to do with a pointer.<\/p>\n
f( unique_ptr<O> )<\/code><\/li>\nf( shared_ptr<O> )<\/code><\/li>\n<\/ul>\nAnd some weirdos:<\/p>\n
\nf( unique_ptr<O> * )<\/code><\/li>\nf( unique_ptr<O> & )<\/code><\/li>\nf( const unique_ptr<O> & )<\/code><\/li>\nf( shared_ptr<O> * )<\/code><\/li>\nf( shared_ptr<O> & )<\/code><\/li>\nf( const shared_ptr<O> & )<\/code><\/li>\n<\/ul>\nf(unique_ptr<O>)<\/code><\/h2>\nunique_ptr<\/code> is aptly named: it is a pointer that there can be only one of. There is no way to copy a unique_ptr<><\/code>, so the following will be disallowed by the compiler:<\/p>\n void<\/span> f(unique_ptr<O> p) {\n \/\/ ... see below ...<\/span>\n }\n\n \/\/ ... elsewhere in the forest ...<\/span>\n unique_ptr<O> myObject = new myObject;\n \/\/ ERROR: No copying<\/span>\n unique_ptr<O> copyObject = myObject;\n \/\/ ERROR: No copying, even for function parameters<\/span>\n f(myObject);<\/code><\/pre>\nThat means that f(unique_ptr<O>)<\/code> is not like f(O*)<\/code>, it\u00e2\u20ac\u2122s saying more than just \u00e2\u20ac\u0153f(p)<\/code> modifies p<\/code>\u00e2\u20ac\u009d. The only way to call this f()<\/code> is by giving up ownership of the passed object, so that there is still only one unique copy of the pointer. Our f()<\/code> declaration therefore tells the caller \u00e2\u20ac\u0153f(p)<\/code> takes ownership of p<\/code> and you need to explicitly give that ownership\u00e2\u20ac\u009d. How do we do that? With move semantics. There is no unique_ptr<><\/code> copy constructor, but there is a move constructor.<\/p>\n void<\/span> f(unique_ptr<O> p) {\n \/\/ ... see below ...<\/span>\n }\n\n \/\/ ... elsewhere in the forest ...<\/span>\n unique_ptr<O> myObject = new myObject;\n f(std::move(myObject));\n \/\/ ERROR: myObject is implicitly now a null unique_ptr<><\/span>\n myObject->modify();<\/code><\/pre>\nf()<\/code> here is promising that it will manage the lifetime of the given object (unique_ptr<><\/code> will, of course, free the underlying resource when it goes out of scope). We can therefore guess the form of f()<\/code> to a certain degree.<\/p>\n void<\/span> f(unique_ptr<O> p) {\n if<\/span>(p)\n someGlobalContainer.push_back(std::move(p));\n }<\/code><\/pre>\nOf particular note: unique_ptr<><\/code> as a parameter has pointer<\/em> semantics, not reference semantics. That is to say that it can be null, or rather the unique_ptr<><\/code> representation of null. It includes an operator bool()()<\/code>, which is automatically called in conditional contexts (like if(p)<\/code>), to allow you to check for that null representation. Importantly: you must check for it, just as you would check a pointer parameter was not nullptr<\/code> before you used it.<\/p>\nOther than that, we can see that once f()<\/code> has completed, p<\/code>\u00e2\u20ac\u2122s lifetime is no longer the concern of the caller. We\u00e2\u20ac\u2122ve explicitly said that f()<\/code> takes ownership. f()<\/code> implicitly tells the caller that it must pass an object that has long lifetime \u00e2\u20ac\u201c i.e.\u00c2\u00a0heap storage rather than automatic storage; that\u00e2\u20ac\u2122s pretty much guaranteed by use of a unique_ptr<><\/code>, which is very hard to trick into taking ownership of automatic storage \u00e2\u20ac\u201c and if you do that then you\u00e2\u20ac\u2122re already seriously broken.<\/p>\nA quick aside to mention the converse case is just as useful in C++11: when a function generates a new object, it should be returned as a unique_ptr<><\/code> too.<\/p>\n unique_ptr<O> g() {\n unique_ptr<O> ret = new O;\n ret->configure();\n\n \/\/ C++11 will automatically use move semantics for a returned<\/span>\n \/\/ automatic-storage variable<\/span>\n return<\/span> ret;\n }<\/code><\/pre>\nf(shared_ptr<O>)<\/code><\/h2>\nIt should be getting easy for you now. Unlike in the unique_ptr<><\/code> case, the caller gets to keep a copy of the pointer. You can<\/em> copy a shared_ptr<><\/code>. Be aware that a shared_ptr<><\/code> supplies that facility at non-zero cost. Reference counts have to be maintained, and they have to be atomic, so imply some degree of locking or memory barrier use. Both of which can have performance implications.<\/p>\nThat means the following is not illegal:<\/p>\n
void<\/span> f(shared_ptr<O> p) {\n \/\/ ... stores a copy ...<\/span>\n }\n\n \/\/ ... elsewhere in the forest ...<\/span>\n shared_ptr<O> myObject = new myObject;\n f(myObject);\n \/\/ myObject is still valid<\/span>\n myObject->modify();\n \/\/ When our shared_ptr<O> goes out of scope, the object is not<\/span>\n \/\/ necessarilly deleted<\/span><\/code><\/pre>\nYou have to be a little careful because shared_ptr<><\/code> means you should only control the object lifetime through shared_ptr<><\/code>, this combined with the ability to pass unwrapped pointers to a shared_ptr<><\/code> constructor means you must be careful not to delete the resource yourself.<\/p>\n void<\/span> f(shared_ptr<O> p) {\n \/\/ ... stores a copy ...<\/span>\n }\n\n \/\/ ... elsewhere in the forest ...<\/span>\n O *myObject = new myObject;\n f(myObject);\n delete myObject;<\/code><\/pre>\nWeirdos<\/h2>\n\nf( unique_ptr<O> * )<\/code><\/li>\nf( unique_ptr<O> & )<\/code><\/li>\nf( shared_ptr<O> * )<\/code><\/li>\nf( shared_ptr<O> & )<\/code><\/li>\n<\/ul>\nPassing a reference to a smart pointer says \u00e2\u20ac\u0153this function will change what your smart pointer refers to\u00e2\u20ac\u009d. The above are not the way to do that. If you have a function that wants to replace a smart pointer, you should be using move semantics and this form:<\/p>\n
\/\/ Used like this: x = f(std::move(x));<\/span>\nunique_ptr<O> f(unique_ptr<O> p) {\n \/\/ replace<\/span>\n p = unique_ptr<O>( new O );\n \/\/ return<\/span>\n return<\/span> p;\n}<\/code><\/pre>\nWhich more accurately expresses what you\u00e2\u20ac\u2122re doing \u00e2\u20ac\u201c the caller has to explicitly move()<\/code> their unique_ptr<><\/code> to f()<\/code> as above, and will be given a new pointer back. C++11 will force the use of std::move()<\/code> for the parameter and will automatically use move semantics to get the replacement unique_ptr<><\/code> back out.<\/p>\n\nf( const unique_ptr<O> & )<\/code><\/li>\nf( const shared_ptr<O> & )<\/code><\/li>\n<\/ul>\nSplutter. The function wants to be given control over a smart pointer it\u00e2\u20ac\u2122s not going to modify? Nonsense. There is no reason you\u00e2\u20ac\u2122d do either of these.<\/p>\n
Conclusions<\/h2>\n
Here then is how you should use each of these parameter variations:<\/p>\n
\nf(O&)<\/code><\/dt>\n- \u00e2\u20ac\u0153Modifies an O, which must exist. Does not delete the O. Does not take a copy of O.\u00e2\u20ac\u009d\n<\/dd>\n
f(O*)<\/code><\/dt>\n- Don\u00e2\u20ac\u2122t use it. Use
f(O&)<\/code>.\n<\/dd>\nf(const O&)<\/code><\/dt>\n- \u00e2\u20ac\u0153Queries an O, which must exist.\u00e2\u20ac\u009d\n<\/dd>\n
f(const O*)<\/code><\/dt>\n- \u00e2\u20ac\u0153Queries an O, which might not exist. Provides fallback or exception in the event that the O does not exist\u00e2\u20ac\u009d.\n<\/dd>\n
f(unique_ptr<O>)<\/code><\/dt>\n- \u00e2\u20ac\u0153Takes ownership of an O, if it exists. The caller must explicitly give ownership \u00e2\u20ac\u201c meaning it loses it\u00e2\u20ac\u009d.\n<\/dd>\n
f(shared_ptr<O>)<\/code><\/dt>\n- \u00e2\u20ac\u0153Takes shared ownership of an O, if it exists. The caller need not explicitly give ownership; however if it is not explicit it must not arbitrarily delete the now-shared O\u00e2\u20ac\u009d.\n<\/dd>\n<\/dl>\n","protected":false},"excerpt":{"rendered":"
While C++98 had smart pointers of a sort; they weren\u00e2\u20ac\u2122t good enough for use. The language lacked the key feature that makes smart pointers work: move semantics. C++11 has introduced that language feature, and hence has solid smart pointers. The addition of smart pointers gives us some further options for passing references to objects when\u2026 Read More »<\/a><\/span><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[66,82,42,6],"_links":{"self":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1182"}],"collection":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1182"}],"version-history":[{"count":3,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1182\/revisions"}],"predecessor-version":[{"id":1193,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1182\/revisions\/1193"}],"wp:attachment":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1182"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1182"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1182"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}