Back to Basics: Type Erasure - Arthur O'Dwyer - CppCon 2019
Vložit
- čas přidán 14. 05. 2024
- 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/
*-----*
Interesting explanation, thanks. It amuses me somewhat that this is in a "basics" talk though.
Arthur O is great, love everything he does ... but his handle on the concept of basic is tenuous at best. 😁
nice explanation, thank you
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.
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.
If std::any supported throwing (i.e. had the toss member function shown at 36:50), we could get rid of std::exception_ptr.
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
On slide 11, the first line of the second part of code ought to read "void *representation = &func;" , probably...
yep, I was going to say the same thing. I'm suprised so few people noticed, it's a bit confusing
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?
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?
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.)
06:31 But... qsort_r is not in C standard library. qsort_s is.
qsort_s is also part of an optional extension and is likely only available on Windows.
did anybody understand the Wirth guy joke?
Worth and value are synonyms
11:19
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?
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
czcams.com/video/4eeESJQk-mw/video.html
+ with that lambda....urghhhh. shocking. Painful to watch. Thanks but no thanks
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.