Yesterday I posted three of my proposed talks for CppCon. These are the ones I’ve given publicly before, but they’re not retreads – all are fresh and up to date, with refreshed or new material.
But I’ve also proposed two brand new talks – titles and abstracts are below.
Note: The CppCon program committee will be considering the talk proposals to come up with a balanced program, so it’s possible that not all of these will be in the final program, but I have high hopes for most of these…
CppCon is building well. I don’t know how many talks there will be in the end as this depends on the program committee including in part how long the accepted talks are, but FWIW my talks are submissions #41 and #126-129. There’s some really great stuff in the pipeline on all sorts of topics of interest to C++ developers, not just about the language itself but also tools, specific domains, and lots of cool stuff that will be shown for the first time at CppCon.
I look forward to seeing many of you at CppCon this fall! If we have the right equipment in the main auditorium, there might even be a wind of change…
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.
Sutter’s Mill 
I do think C++ needs a way to standardize on an ABI for a given platform and I think this is one of the biggest issues right now with C++. I love your proposal: https://isocpp.org/blog/2014/05/n4028. I think this is going to have much more success then most are giving credit for. Solutions continue to grow and to expect everything to be done by one group is unrealistic. And to expect that all the individual groups will use the same compiler is also unrealistic. I really look forward to this proposal getting into the standard.
Standardize C++ ABI, it will take years, and the worst part is…. I’m sure Microsoft would donate the ABI spec used in C++/CX. Now that would be a GIANT step forward.
I really don’t listen to C++ motto of cross platform, if I need different compile modes i.e. switches for processor, debug and what have you, and I’m still not able to use the same binary, running on the same hardware (Windows, LINUX, OSX on x86 or x64) then we have a long way to go. The ABI layer cannot come soon enough!
Then we will also be able to test OS benchmarks for real. I hope you get the opportunity Herb to give this talk to the largest group possible.
I suppose that the ABA problem talk is referring to solving it *portably*. Windows NT solved needing a hazard pointer list with ExInterlockedPushEntrySList and its hack to the kernel’s exception handler to detect when a null pointer dereference occurs. And with 64-bit NT 6.3 (Windows 8.1) requiring cmpxchg16b, the solution to the ABA problem no longer cramps the address space – the counter value used to avoid the ABA problem is no longer occupying bits of the pointer.
One way to add garbage collection to C++ would be to add a compilation mode that is RTTI on crack, where you could enumerate the fields of a class at runtime. Then you could implement mark-and-sweep by following all the pointers you find. This is probably one of the “Wrong Ways” you speak of. =)
@kiassimilation: The organizers are still working out whether streaming/recording will be possible. If it’s done at all it should be at good quality, and they’re looking into options. Stay tuned…
I just dont see ABI as cpp#1 problem… compile times, no serialization, no iso networking header, no pure(constexpr!=pure)… maybe talk will help me see the error of my ways…
and for GC I really hope you explain how GC helps with ABA problem and lockfree stuff, it seems counter-intuitive to me that GC helps with performance. :D
Based upon my own experiences, and what previous commenters have posted, it looks like the ABI talk is a must. The GC one is interesting too and would look forward to it, but definitely put me down for the ABI talk.
These all look like excellent talks, but I would REALLY like to hear the lockfree, abi and gc talks. I love that you take on the “dangerous” (lockfree) and “sensitive” (abi and gc) topics. I can see why a presenter would like to avoid such topics (FUD, passionate heated debates etc. ), but that makes balanced, fact-based talks all the more welcome. (Last week I used your //build talk to shut up someone who was spreading FUD about C++ based on a failed project in the 1980s… it was pretty effective)
Glad to see that the ABI problem is getting more attention. My previous 2 talks at C++Now have been about this ABI problem and how to solve it with a library solution.
See
https://github.com/boostcon/cppnow_presentations_2014/blob/master/files/cppnow2014_bandela_presentation.pdf?raw=true for C++Now2014 – this is a higher level approach
https://github.com/boostcon/cppnow_presentations_2013/blob/master/tue/easy_binary_compat.pdf?raw=true for C++Now 2013 – this goes into more detail
I submitted a talk on the same to CppCon. I am looking forward to see your(Herb’s) approach, and comparing it to my current approach
Herb, are there plans to stream/record the CppCon videos for the general public as was done for GoingNative ’13?
as naive as this may sound, but is there any official plan to ‘standardize’ such an ABI for C++ in the future?
+1 for ABI talk!
The C++ ABI issues I have are not with the ABIs that _I_ write, but rather the ABIs my libraries link against — e.g. MSVCRT, Debug vs. Release, etc.
I would love to hear about the c++ ABI