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.

@keris3920

3 жыл бұрын

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.

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

@tbkih

10 ай бұрын

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

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

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?

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.

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

2 жыл бұрын

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.)

did anybody understand the Wirth guy joke?

@TheBigWazowski

2 жыл бұрын

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?

@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 kzread.info/dash/bejne/ZpmZp7WDgc6Tndo.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.