You can find it on YouTube here. [ETA: Slides are here.] Here’s an embed, below:

## 12 thoughts on “My CppCon talk video is online”

Comments are closed.

Skip to content
# My CppCon talk video is online

##
12 thoughts on “My CppCon talk video is online”

You can find it on YouTube here. [ETA: Slides are here.] Here’s an embed, below:

Comments are closed.

Can you please share the slides from presentation somewhere?

Dear Herb,

I just watched this (great) talk and I very much like the

idea. However I do see one potential downside by factoring it out this way (which may not actually exist so feel free to tell me to RTFC). By having

do the tracing do you not lose the ability to merge the marking step with a normal graph traversal?

Cheers,

Pim

Slides from CPPCON 2016 can be found at https://github.com/CppCon/CppCon2016.

Great talk, Herb. Thank you!

I just noticed that in PDF, the slides that had the delayed “sticky” note added (starting at slide 7), it is always there and obstructs the slide. Is sharing the PowerPoint (OpenOffice Impress?) presentation an option?

Disregard my last comment. PDF has before note / after note slides.

@Pim: Yes, in the current implementation you do lose the ability to merge the marking with a normal graph traversal that the program would have done anyway. By decoupling it, the tradeoff is that you can choose to give that up in favor of that you don’t have to write the tracing logic yourself, and also gain more control over when/where tracing runs (e.g., it doesn’t have to wait for a caller to traverse, or be on a caller’s thread).

@Herb, thank you. Knowing which objects point to which other objects however, can’t you add a library function to traverse the graph marking the elements as well as executing a user provided functor and call collect minus the tracing step at the end? For simple cases this might alleviate the downside.

@Ray: Yup, I tried to break apart build slides into separate slides when a later build step would obscure an earlier part of the slide, for exactly this reason (so that handouts would be readable). Let me know if I missed any.

Very interesting talk, as always.

I think there’s a slight error on slides 19/20 about the iterative destructor, but please excuse me if I’m wrong.

Your algorithm iteratively finds a leaf and then destructs it, so the runtime should be O(N*h), where h is the height of the tree. Of course, for balanced trees h=log N, as you wrote. But your example of the linked list being a degenerate tree shows that this is actually worst-case O(N). Actually, the same holds for the default recursive destruction, which uses O(h) stack space. There you have listed it as “O(N) stack space”, not only O(log N) (in which case it probably would not be a problem).

So I think that the worst-case run-time for your iterative destruction (in this particular implementation) is actually O(N*N).

@Andre You are correct, and I’m pretty sure that in the talk I explained the worst-case of that slide, and definitely did a couple of slides later when talking about the linked list case as a tree of breadth 1.

Hi Herb,

You mentioned prior years talk on this material with regards to non-owners. Could you perhaps provide a link to which talk this is, I can’t seem to find anything. Thanks in advance.

Btw, Thanks for this great talk really improving and deepening my experience with handling ownership in some of the complex systems I’m looking at!!

@Avi You can find it here: https://youtu.be/hEx5DNLWGgA