CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default.” on HackerTube: recommended by 2 Hacker News commenters across 4 separate months, 2016–2025.
talk · advanced · evergreen
Herb Sutter's CppCon 2016 talk on lifetime safety in C++, aiming for code free of leaks and dangling pointers by default. It covers smart pointers, ownership, reference counting pitfalls and deferred reclamation resembling garbage collection.
HN cites it in memory management debates for its treatment of reference counting problems, destructor stack overflows and deferred pointers.
“Check all of Herb Sutter's CppCon videos from 2015-2016, especially this one”
20 Hacker News comments link this video. Each one links back to its thread.
Check all of Herb Sutter's CppCon videos from 2015-2016, especially this one: ▶ this video He does a great job of walking through the thought process of deciding which of the options makes sense in different situations.
in “Smart pointers and move semantics in modern C++” · View on HN
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.” ▶ this 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.
in “Show HN: A pure reference counting GC in Go” · View on HN
Herb Sutter has a nice talk about how RAII can cause stack overflows or stop-the-world pauses if used badly. ▶ this video
in “Fearless Security: Memory Safety” · View on HN
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. ▶ this video
in “Lazarus – A Delphi-compatible cross-platform IDE” · View on HN
Herb Sutter gave a really great talk on this: ▶ 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]
in “Smart pointers and move semantics in modern C++” · View on HN
Regarding being "deterministic", CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default.” ▶ this video
in “The Garbage Collection Handbook” · View on HN
Several attempts have been made already, the problem is overcomming the community's resistance to have one in the box, recently they have removed the APIs introduced in C++11. It is also interesting how Herb Sutter avoiding making the comparision between deferred deallocation and GC algorithms on his talk until the last section. "CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default.”" ▶ this video
in “Retrofitting Temporal Memory Safety on C++” · View on HN
We have to agree to disagree then. Having to create borrow checker friendly data structures doesn't bring anything to the table when writing GUI applications (including design tooling), distributed applications (Akka, Orleans, Erlang style, RDMS SP), CLI tooling, compiler tooling.... In what concerns languages with automatic memory management and support for value types, my list is somehow different, D, Nim, C#, F#, Swift, Go, Linear Haskell, Ocaml with Effects, Eiffel, Common Lisp. And I leave Herb's talk regarding those issues with RC types, "CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default.” ▶ this video
in “What Is Rust's Hole Purpose?” · View on HN
About the same, Herb Sutter has a talk how that can even trigger stack overflow if the destructors are not written with care. "CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default.” ▶ this video By the way, C++/WinRT uses background threads to handle cascade deletions of COM references exactly because of this.
in “Sciter, the 5 MB Electron alternative, has switched to JavaScript” · View on HN
Yeah, right. CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default.” ▶ this video Better making use of the best practices advised by Herb, otherwise those destructors are going to surprise you.
in “Shenandoah in OpenJDK 17: Sub-millisecond GC pauses” · View on HN
> just because you don't like pointers, does not mean the rest of us can't use them perfectly safely. I actually use pointers quite safely. I just no longer see a need to ever return an allocation from `new` to a raw pointer unless I'm implementing my own pointer class. Herb Sutter's correct [0]. `std::unique_ptr` or `std::shared_ptr` or some other pointer container should __always__ hold new-allocated objects. Just like you should __always__ wear your seatbelt. It's no danger to you or anyone else, it's slightly inconvenient, and it saves a metric ton of headaches about "what if?". Because in reality a pointer container explicitly marks the scope of the allocation and if you're not wanting to use C++'s scoping rules then why are you using C++? [0] ▶ this video
in “How fast can you allocate a large block of memory in C++?” · View on HN
Yet all the languages with a tracing GC wipe the floor of Swift's reference counting implementation. "35C3 - Safe and Secure Drivers in High-Level Languages" [link] [link] The subject of Herb's talk was actually going through all the reference counting problems to introduce in the end a lightweight implementation of deferred pointers, which isn't nothing more than basic tracing GC. ▶ this video
in “Swift Generics Evolution” · View on HN
Very predicatable indeed. Go and C# running circles around Swift. "35C3 - Safe and Secure Drivers in High-Level Languages" [link] Possible stack overflows and unexpected pauses due to heavily nested data structures. "CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default." ▶ this video
in “Java 12” · View on HN
1. I think you may not realize what state of the art tracing GCs can accomplish. IBM's Metronome has pause times down to hundreds of microseconds. 2. It only takes freeing a tree with a few thousand nodes for it to become an issue. It happens in C++, too (heck, there've been cases where chained destructor calls overflowed the stack [1]). The reason why you don't hear more about it is because pause times just aren't that big a deal for most applications. In forum debates, people always discuss triple A video games and OS kernels and such, but in practice, only a minority of programmers actually have to deal with something even approaching hard real time requirements. Generally, most applications optimize more for throughput rather than pause times. 3. Yes, and it can be a problem for C/C++, too. It's rare, but not non-existent. Note that pools can actually make fragmentation worse for long-running processes. 4. Weak references work if you get them right. But for long-running processes, even a single error can accumulate over time. > On the GC side, it seems like you typically get bursty, unpredictable performance, in both time and memory. Modern GCs work very hard to keep collection pauses as short as possible, but almost inevitably that means keeping garbage around for longer, which means using a lot of memory. This ... is not at all how garbage collectors work, especially where real time is concerned. Not even remotely. I recommend "The Garbage Collection Handbook" (the 2011
in “Concurrency in Swift: One possible approach” · View on HN
Herb Sutter presented one in a talk a little while ago. [link] ▶ this video So it's totally doable in library without cost to those that do not need it.
in “In Defense of C++” · View on HN
>With modern C++ language features, the "complicated language with the manual memory management" a lot less obvious or necessary Not completely though, you still have to think a lot more about ownership and object lifetimes ( ▶ this video ), which is a lot better than manual new/delete, but still not as simple as just having a GC. Plus you have to deal with lifetimes of objects proxied to Java code, where something in the Java code becomes the object's owner. Though you can use a bindings generator like djinni ( [link] ) to handle this for you (with some tradeoffs). >Debugging is only complicated on Android It's gotten slightly better recently, but it still sucks. With Swift it's not trivial either, it's not that easy to set breakpoints into C++ code, stack traces on crashes are often not helpful (so any unhandled C++ exception that you didn't catch and convert into a Swift error is hard to track down, etc.)
in “React Native at Instagram” · View on HN
I was mainly talking about the C++ Guideline Support Library and GSL profile "checkers" that have been in process for the last couple of years. [link] [link] ▶ this video
in “Rust is Software's Salvation” · View on HN
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] ▶ this video
in “Reclaiming C++ Data Structures with Cycles” · View on HN
> 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": ▶ this 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.
in “Reclaiming C++ Data Structures with Cycles” · View on HN
>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: ▶ this 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.
in “Reclaiming C++ Data Structures with Cycles” · View on HN