Back to Basics: Type Erasure - Arthur O'Dwyer - CppCon 2019

CppCon.org
-
Discussion & Comments: / cpp
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/CppCon/CppCon2019
-
This talk, based on Arthur's blog post ["What is Type Erasure?"](quuxplusone.github.io/blog/20..., will explain the notion of type erasure as seen in standard library types such as std::function and std::any. We'll see how to build the most naive form of type erasure using heap allocation and virtual functions; then iteratively optimize that design to improve its performance. At the extreme, we'll see how C++2a std::function_ref achieves trivial copyability.
Attendees will leave this session confident in their ability to implement type-erased classes, such as std::function, from scratch.
-
Arthur O'Dwyer
New York
Arthur O'Dwyer is the author of "Colossal Cave: The Board Game," "Mastering the C++17 STL" (the book), and "The STL From Scratch" (the training course). He runs professional C++ training courses, is occasionally active on the C++ Standards Committee, and has a blog mostly about C++.
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com
*-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----*

[@sideparting6845]

Interesting explanation, thanks. It amuses me somewhat that this is in a "basics" talk though.

[@pmcgee003]

Arthur O is great, love everything he does ... but his handle on the concept of basic is tenuous at best. 😁

[@qsvui]

nice explanation, thank you

[@serhiiprokhorov6976]

Hm, I guess we just exchange compile time (to figure out the type) with run time (to lookup particular affordance). And it is unavoidable space-to-time exchange problem. What is better? Depends on what you need.

[@keris3920]

While I agree that it depends on the situation, I mostly see compile time as a non-issue. Even for some of our larger projects, I'd much rather spend 15 minutes waiting on a compile than a week going through a release process because a customer found a bug that could have been caught at compile time.

[@JohnB5290]

If std::any supported throwing (i.e. had the toss member function shown at 36:50), we could get rid of std::exception_ptr.

[@robrick9361]

12:27 operator+ thing is dumb and confusing, the assignment already indicates that it's convertible to anyone who doesn't know and the plus just confuses people who already know

[@victorbazarov3794]

On slide 11, the first line of the second part of code ought to read "void *representation = &func;" , probably...

[@tbkih]

yep, I was going to say the same thing. I'm suprised so few people noticed, it's a bit confusing

[@artemiskearney8019]

Seems sort of like an alternate concept for interfaces - the template-derived-struct style gives you a sort of duck typing, but one could imagine ways to make implementations explicit at either the wrapped type's definition site or the affordance set's, or a mix of the two with a bit more work. How would the world be different if we'd been doing this from the beginning?

[@BeggarEngineering]

06:31 But... qsort_r is not in C standard library. qsort_s is.

[@RenamedChannel]

qsort_s is also part of an optional extension and is likely only available on Windows.

[@dennydaydreamer]

Great talk! I was wondering: if we pass a lambda by wrapping it in an std::function object, aren't we required to supply the function signature as the template parameter, and therefore we are restricted to that particular signature of lambda?

[@Quuxplusone]

Yes, for a certain definition of "signature." In the talk I use the word "affordance": std::function can hold any object that _affords_ calling-with-an-int-and-yielding-an-int-in-return. One example of such an object is [](int x) { return x+1; }, but another example is [](float x) { return x > 5; } - because it can be called with an int (which will be implicitly converted to float) and returns a bool (which can be implicitly converted to int). Another example is [](auto x) { return x; }, which is callable with just about anything: it certainly affords calling-with-an-int-and-returning-an-int, so it can be stored in a std::function. Its calling-with-an-int-and-returning-an-int affordance is exposed via std::function::operator(); everything else about the type (e.g., the fact that it's _also_ callable with a std::string) is "erased," and is not accessible through the std::function's public API at all. (Except via the "go fish" mechanism described at 32:20.)

[@RafaelSouza-wc9td]

did anybody understand the Wirth guy joke?

[@TheBigWazowski]

Worth and value are synonyms

[@childhood1888]

11:19

[@ultimatesoup]

I don't really see the usefulness of type erasure. What is an example of why you would want to do this? Wouldn't that be indicative of bad design?

[@WilhelmDrake]

I found Klaus Iglberger's talk on the subject to be very good at explaining this. See: Breaking Dependencies: Type Erasure - A Design Analysis - Klaus Iglberger - CppCon 2021 kzbin.info/www/bejne/apbIdoaAhtBgo9k

[@graham12345dd]

+ with that lambda....urghhhh. shocking. Painful to watch. Thanks but no thanks

[@pedromiguelareias]

Reinventing void* and it's almost as fast as polymorphism (which was already too slow). No. Namespaces, Templates, Destructors (or RAII) are the contributions of C++ to the world. Trying to compete with the newer languages is becoming vexing on this old lady. Like a F1 car with a passenger seat or a Moto GP bike with a top case.