CppCon 2019: Arthur O'Dwyer “Back to Basics: Smart Pointers”

—
—
—
Smart pointers are one of the key features of modern C++. We'll cover the two fundamental strategies used by the standard smart pointers: unique ownership transfer and reference-counting. We'll show how shared_ptr uses control blocks to implement reference-counting of arbitrary objects, and how to use weak_ptr in conjunction with shared_ptr. We'll explain the convenience functions make_shared and make_unique, and demonstrate how they are more than just conveniences. Finally, we'll motivate, implement, and demystify the curiously recurring template enable_shared_from_this＜T＞.

Attendees will leave this session with a clear understanding of how C++11's smart pointers work under the hood.
—
Arthur O'Dwyer
New York

Arthur O'Dwyer is the author of "Colossal Cave: The Board Game," "Mastering the C++17 STL" (the book), and "The STL From Scratch" (the training course). He runs professional C++ training courses, is occasionally active on the C++ Standards Committee, and has a blog mostly about C++.
—

*-----*
*-----*

[LordShadow]

2:13 "auto putter", "unique putter", "shared putter", "weak pointer"

[ArpitAgarwal]

Your talks are very clear. Thanks for educating a new generation of CPP users.

[frikbrits]

Just had to smile at the "putter" 's. But still hugely informative talk.

[samhughes]

"I'd have trouble pointing at something and saying, 'Yes, this is a good example!'" This is such a relatable comment!

[sofasurfer]

The pubsub pattern is a good motivation for weak_ptr. The point of the pattern is to decouple publishers and subscribers. So publishers need to keep a list of subscribers, but that list should contain weak_ptr's so the subscribers arent forced into living longer than they're supposed to.
As a rule, if you store a pointer to an object, then either (A) you're responsible for keeping it alive and you should use a shared_ptr, or (B) it's not your job to keep it alive and you should use a weak_ptr and gracefully handle the case when it's not there.

[rrw]

I can see a lot of hard work went into that beard. Oh, and the talk was good.

[kamilziemian]

Very good presentation. My knowledge about smart pointers is much better after watching it.

[Skeksis]

At 45:45 - shared_from_this can only be called on a previously shared object. assert(p->shared_from_this() == nullptr) will throw a std::bad_weak_ptr since C++17, and is undefined behaviour on older standards.

[guppiefang]

Around 50:30, that Listener object that uses `shared_from_this()`, seems like a memory leak. The shared pointer will be stored in the lambda that is presumably stored in some internal list, waiting for connections, so now if you drop all shared_ptrs to the Listener, it will not deallocate. No? Am I imagining that incorrectly? I thought he was going to store a weak_ptr as part of the lambda for this reason.

[johnjones]

This talk could have better covered the difference between an owning and a non-owning raw pointer and the place for using non-owning raw pointers in conjunction with smart pointers (with no owning raw pointers)...

[wizardy]

Nice talk :) "enabled_shared_from_this" is a really long class name, would it be better to just call that "shared_this"?

[rahuldeshmukhpatil]

shared_ptr aliasing is something that must be in the talk !!!

[pajeetsingh]

"I use plain old C* with lots of fragmented memory because I am competent" - Linus

[qqiz]

When I pass unique_ptr by value, compiler complains that I wan to use copy constructor and it seems that compiler is right and this presentation is incorrect.

[deanroddey]

It's far better to have specific implementations of what I can 'janitorial' classes for things other than allocation/deallocation. Having generic unique pointer doing something like closing a file is very misleading. There's little that would tell the reader that that was going to happen. So it falls into the too clever for its own good category.

I have a broad family of such janitorial classes in my system to do all kinds of things, and they are much more self-documenting, and generally trivial to implement so no particular burden to have a bunch of them.

[jvsnyc]

So in a Nicolai Josuttis talk from the same year, he explains what an absolute disaster for performance you can have in a heavily multi-threaded application if you pass shared pointers around everywhere by value in each of a bunch of different threads:
This largely goes away if you pass them by reference, as they are no longer are contending to atomically increment and decrement the shared reference counter in the control block every time anyone blinks, breathes or scratches their nose.
I think what I got from *this* talk was that these functions all calling each other shouldn't have shared pointers in their signatures in the first place, whether or not they are heavily multi-threaded.
This talk might not have made as clear as some other talks what that means in practice for the befuddled developer -- sure, no explicit new or delete might be great (unless you need to pass in a custom deleter, perhaps) and we don't want any raw *owning* pointers, but where do unique_ptr <T> and shared_ptr<T> show in function signatures? If hardly ever, do we just see a .get() once and then it's raw pTurtle s all the way down?
Lastly, different talks seem to disagree about the main use cases for weak_ptr. This talk acknowledges that circular references are a thing, but seems to think they just shouldn't exist. That sounds almost ridiculous, or like trolling, many people work primarily with data structures with all kinds of circular references in them -- we might try to say "just forget about smart pointers in this case and program those the same way you would have in 1995" but I don't think that is really the take-home message from this talk, but it does feel that way for a good bit. If you are working with data structures that do contain cycles - maybe really advanced ones like the "doubly-linked list" do we ignore smart pointers or use weak_ptr's to save our butts? I don't think there is a third option.

[nutt.rangsiman]

Pointer makes C++ a fantastic OOP language.

[MasterOfMisc]

If your writing new and delete manually your doing it wrong! - Good talk by the way.

[liberatemi]

“Putter” - it’s not mini golf- but it is rather aggravating.

[__hannibaalbarca__]

It should be programmer{CS} be a good mathematician; and than we can get A Very Hi. Performance programming language _C++_