CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default.”

Check all of Herb Sutter's CppCon videos from 2015-2016, especially this one: [VIDEO] He does a great job of walking through the thought process of deciding which of the options makes sense in different situations.

Herb Sutter gave a really great talk on this: [VIDEO] He has 3 guidelines: 1. Prefer scoped lifetimes by default (local members) 2. Else prefer unique_ptr and containers 3. Else consider shared_ptr His whole talk gives examples that show the flexibility of unique_ptr and how modern C++ can express ownership. See slide 5 here: [LINK]

Reference counting isn't deterministic in the presence of large complex data structures. You will know when memory gets deleted, but not how long it will take, nor how much stack space the destructors will require to run. Enjoy Herb Sutter's "Leak-Freedom in C++... By Default." at CppCon 2016, where he explains how those issues affect C++ and goes on to implement a tracing GC. [VIDEO]

Herb Sutter has a nice talk about how RAII can cause stack overflows or stop-the-world pauses if used badly. [VIDEO]

On single core without threading. If you add multi-threading and multi-core, there is lock contention for every single memory access to update the related counter. Additionally, if there is a big data structure in use, reaching zero will trigger a cascade deletion events reaching stop-the-world like effect. Which, depending on how the deletion was implemented, might trigger a stack overflow in very deep structures. Herb Sutter has a very interesting talk about the bad issues of reference counting and how to work around them. CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default.” [VIDEO] There are multiple ways to optimize reference counting, like deferred counting, cycle collectors and a couple of others, which when you are done with all them, ends up being quite similar to having a tracing GC anyway.

I recently watched Herb Sutter's talk "Leak-Freedom in C++", described in the article [1], and I can't help but notice that C++ community has a strong bias against garbage collection. ... And then he describes the very problem you can't solve without GC: memory management for graphs with cycles. Solving this problem is equivalent to implementing GC. Of course, having your own specialized GC may help, but you may also benefit from your own memory allocation. Why can't you acknowledge that there are problems that have GC as the only and best solution? (Note: it's possible to mix memory management approaches, e.g only pointers to graph nodes are being garbage collected and everything else has a nice hierarchical ownership.) [1] [VIDEO]

> Your prelude and the followup question is not well-formed. Thank you for your feedback, I appreciate it. > C++ programmers do not have a bias against GC as a specific problem-solving technique. Expert C++ programmers can embrace GC Please watch this portion of the video, and the way the speaker is pronouncing the word "collect": [VIDEO] Regarding general-purpose GC: I don't support using GC for everything . If there is a problem that can only be solved with GC, it doesn't mean that we should express our entire running programs in terms of dynamic cyclic graphs. I believe we can do much better, with much fewer resources.

>Please watch this portion of the video, and the way the speaker is pronouncing the word "collect": Herb was deliberately using circumlocution to avoid the phrase "garbage collection" so as to not poison the well. The latter part of the video explains his reasoning for presenting it that way: [VIDEO] >I don't support using GC for everything. [...] I believe we can do much better, with much fewer resources. This is a statement that sounds reasonable and balanced . How can anyone possibly disagree with it?!? The issue is that it's very difficult to take that universal wisdom and construct a real programming language that satisfies all the following properties seamlessly and elegantly: 1) language that has optional GC 2) has zero cost when not using it. This means no active tracing loop that checks object graphs and no large memory blocks reserved to allow reallocation and defragmention. 3) transparent syntax that's equally elegant for manual memory or GC in the same language To make your GC-when-appropriate advice real , one has to show a real implementation. E.g. one can fork the GCC or LLVM compilers and add GC to it. Or fork the Java OpenJDK compiler and show how syntax can remove the GC on demand. Or construct a new language from scratch. There may be some lessons learned from the D Language backing away from GC. Also, Apple Objective-C retreated from GC as well.