Following up on Herb's three talk proposals posted yesterday, the other two titles and abstracts are now posted, this time of new talks (note: again, pending review and selection by the program committee, so this is not final -- they may or may not be selected if there is stronger material).

CppCon: My Proposed Talks (Part 2)

by Herb Sutter

From the post:

GC for C++, and C++ for GC: “Right” and “Wrong” Ways to Add Garbage Collection to C++ (1 to 2 hours)

"Garbage collection is essential to modern programming!" "Garbage collection is silly, who needs it!"

As is usual with extremes, both of these statements are wrong. Garbage collection (GC) is not needed for most C++ programs; we're very happy with determinism and smart pointers, and GC is absolutely penalizing when overused, especially as a default (or, shudder, only) memory allocator. However, the truth is that GC is also important to certain high-performance and highly-concurrent data structures, because it helps solve advanced lock-free problems like the ABA problem better than workarounds like hazard pointers.

This talk presents thoughts about how GC can be added well to C++, directly complementing (not competing with) C++'s existing strengths and demonstrating why, as Stroustrup says, "C++ is the best language for garbage collection."

 

Addressing C++’s #1 Problem: Defining a C++ ABI (1 hour)

"Why can't I share C++ libraries even between my own internal teams without using the identical compiler and switch settings?" "Why are operating system APIs written in unsafe C, instead of C++?" "Why can’t I use std::string in a public shared library interface; it's the C++ string, isn't it?!"

These and more perennial questions are caused by the same underlying problem: For various historical reasons, C++ does not have a standard binary interface, or ABI. Partial solutions exist, from the Itanium ABI which addresses only the language and only on some platforms, to COM and CORBA which do both less and far more than is needed.

It is deeply ironic that there actually is a way to write an API in C++ so that it has a de facto stable binary ABI on every platform: extern "C".

This session describes current work driven by the presenter to develop a standard C++ ABI. This does not mean having identical binaries on all platforms. It does mean tackling all of the above problems, including directly addressing the #1 valid reason to use C instead of C++, and removing a major obstacle to sharing binary C++ libraries in a modern way.