C++ Smart Pointers - Usage and Secrets - Nicolai Josuttis

shared_ptr and unique_ptr are the key smart pointers of Modern C++.

This talk gives an overview about when to use them and what you should know abvout it (including their hidden price).

Save the date for NDC TechTown 2020 (31st of August - 3rd of September)

Check out more of our talks at:

[jvsnyc]

I think this is the third video I've watched on Smart Pointers this week (maybe the sixth or seventh if you count small ones!!) and it is the first one that called to attention WHY the method on weak pointer is called .lock() and why it is necessary!!! This is what I would expect from this author/lecturer. There are talks and books I ignore because the people don't know enough to be worth trying to learn from, there are the talks and books I am scared of because the people are geniuses who know so much I think I can't keep up with them or follow them, and those I follow semi-religiously. I thought this author was in category two until I was better at C++ than I felt I was, but this talk just moved him into camp three. When he talks about C++ I will act like my dog does when I talk about food and walks!

[jvsnyc]

Second comment. After watching several other videos, I literally had nightmares wondering how shared pointers and weak pointers MUST work to actually function correctly...surely they couldn't be as simple an implementation as I imagined from the other talks or they wouldn't work reliably. At ~18:00 this video shows exactly the machinery that makes shared_ptr/weak_ptr safe for human consumption. Of course it has to be there, it wouldn't be safe to use otherwise. I don't personally save time by watching/reading material that omits such stuff because "just not thinking about it" is only an option until I go to sleep. This level of talk literally prevents nightmares for me.

[pazdziochowaty]

Calling release() after passing a unique_ptr to a function by reference can leak resource if the function did not take the ownership. release() sets the pointer to nullptr and returns raw pointer which is NOT deleted. It is up to the code which takes that pointer to call delete!
What you might have in mind is to call reset() function which deletes owned pointer and reset the unique_ptr to nullptr

[jvsnyc]

There are multiple good talks on this that seem to disagree on whether it is better to use weak_ptr<> or shared_ptr<> for back references from owned objects. Arthur O'Dwyer thinks it is fine to use raw pointers from B back to A. I guess it depends on whether you believe that you can ever get into a state where B exists independent of A, doesn't it? I guess in general, if you need to refer to something that may or may not be there anymore, and if they aren't, that's okay, but you need to find out, and if they are then that is your guy -- you need a weak pointer. Raw pointers should NEVER be allowed to dangle, so they are ideal as long as you are an observing pointer to something that you know hasn't disappeared since, and a very serious error otherwise.

[sprytnychomik]

Don't use raw pointers because of potential memory leaks, if you're not careful. Use smart pointers instead and deal with overhead, copying, moving, multithreading, custom deleters, actual uniqueness, code smells, new casting, bunch more deathtraps and... potential memory leaks if you're not careful. Brilliant!

[rafalmichalski]

On slide 57 (29:38) Do we have 0 or 1 weaks ?
On slied 90 Is there memory leak after invoking release with "&&" sink, when ownership is not lost there (reset method seems to be better here than release) ?

[jvsnyc]

On slide 29, ~11:33, I am not sure what is going on with the lines showing gp->print() and gp.use_count()
gp just contains null at this point, right? Was this a typo or is it supposed to show us something about the default behavior of a new created shared_ptr<T>?

[jvsnyc]

On passing shared pointers by reference, someone commenting on some other video raised the spectre of "if you do that, you can lose the reference to the object in question"...I didn't see how that could happen, but they seemed sure. Is there some race condition or corner case where passing a shared_ptr by reference isn't safe? I do understand some people think they shouldn't be appearing as parameters in calls at all, but only as part of another object, etc. -- but I don't see any *risk* in passing them by reference, only that someone else thought there was some danger in doing so.

[alexbutane]

Great video, thanks for sharing. i still got a problem tough.. i'm trying to allocate a private member vector of unique_ptr to a base class object ( m_objects ; ) and than to pushback derived classes into it trough a void function that gets nothing and returns nothing but it knows the vector member in the private section of the class because the cpp file belongs to its header file so i use ( <Derived1>(); ) but i always get these linkage errors 2019 and 1120 and i don't know what to do anymore..

[jvsnyc]

59:29 the audio says "Shared pointers were implemented and designed to have no performance overhead, end of discussion." Of course, we mean unique pointers in that sentence.

[jvsnyc]

~57:16 slide 90. I don't understand the call to .release(). If it somehow still had ownership when we got to that point, calling .release() and throwing away the value would be a memory leak. If it didn't, I am also not sure what it buys us, calling .release() on a moved-from object. I think we are rushing a bit as we come to the end of the presentation, and the normally very careful wording may have slipped. We definitely need a good style guide for all of these things, that is agreed for sure.

[vlad_serg]

57:00 Why he propose to release() the pointer? I think there must be reset(), because release leads to memory leak.

[vishwanathbiradar]

Very well explained. Thank you for sharing.

[xplorethings]

I love the semantics that smart pointers introduce. However, the syntactic support is just too weak. You either have to put templates everywhere, use template arguments everywhere or define a ridiculous amount of types to get something that gets you to readable code. Comparing "object*" to "std::unique_ptr<object>" one can clearly see this leads to unreadable code as soon as you need to use a collection. You could create a using alias, but now you have a type that is highly non-standard and will differ from project to project if not from one file to another. This is not a terribly high price to pay for the safety that smart pointers bring, but I, for one, would be a lot happier if they were a language feature, not library code. std::unordered_map<std::string, is kind of ridiculous and if you don't want to introduce obscure types, you will have to put up with code like that. Hopefully modules will at least solve the sprinkling of namespaces everywhere. unordered_map<string, vector<string$>> would be a lot cleaner and more readable (obviously $ for being an expensive shared_ptr :-))

[StefanReich]

Smart pointers are great and anyone who uses garbage collection must be a really crappy programmer

[greob]

Thank you very much for sharing! Very very interesting presentation.