Klaus is capable of giving so much information in such a short amount of time without being overwhelming. You know a talk is going to be great if he gives it.

Klaus repeatedly saying "However... we're not happy!" and continuing to strive for the ultimate perfection... he's definitely a German! :D

Nice talk! This is the most beautiful solution I have ever seen to solve the problem of a large number of class inheritances. Thanks, Klaus!

ahhhhh so THIS is type-erasure. I've always called it one of: - "the way C++ does dynamic dispatch like Common Lisp's defgeneric/defmethod" - "The thing Sean Parent introduces in that talk". This is MUCH shorter. Thanks, great talk, great explanation

Dear Mr. Klaus, you are a excellent teacher. This lecture indeed brought a smile to my face. Thank you.

Klaus gives us an elegant and very comprehensive speech, as always!

Thanks Klaus this was a pleasure to watch! It is one of my favorite topics as well for the same reason.

@CppCon

2 жыл бұрын

Great to hear!

I see that you end up with different native functions accepting (const-ref to) "leaf" classes (like Circle, Square). Those "strategy" functions will need to access member data indirectly via "getters", i.e. one getter per data member. I always found that classes filled with getters somehow breaks encapsulation. For classes as simple as circle and square, it's no big deal. But for more complex classes involving multiple data members, you will end up revealing several specific implementation details via those getters. I know TE wants to solve a problem, but it seems to do so at the cost of breaking encapsulation (i.e., revealing implementation details) of the fundamental classes. Fell free to share you opinions.

As always great talk. Thanks Klaus!

Thanks Klaus. Clear presentation of a beautiful idea. This motivates me to watch rest of Kluas' talks as well.

@CppCon

Жыл бұрын

Very pleased to hear that you are inspired to watch further presentations.

External polymorphism seems to be what other languages have landed on, e.g. Go's interfaces or Haskell's typeclasses. It makes so much sense to not tightly couple data inheritance with functionality inheritance (what we get with virtual functions), as the former is not always needed. This is definitely my favorite type erasure talk this far!

33:19 For those who missed, draw and serialize are implemented as free functions, which are referenced in the shape concept class polymorphically.

Wow, this solves a problem I just encountered yesterday and used ugly void* casting. What perfect timing!

This is such a great video on c++ design patterns! ❤

If Klaus was a professor at my university, I would have taken all his classes!

Amazing talk!

26:00 "std::variant is the opposite of type erasure. std::variant [gives you] a closed set of types and an open set of operations. Type Erasure gives you an open set of types and a close set of operations. "

Amazing talk

Great pattern, and presented so easy to grasp.

@CppCon

2 жыл бұрын

Glad it was helpful!

Good talk on the merits in addition to the mechanics of Type Erasure! I wonder how the proposed "Deduce This pattern" helps or interacts with Type Erasure.

Type erasure is great, but the final solution makes no mention of the original problem, which is namely using OpenGL or other graphics libraries with this shape ontology. It seems like as presented, this is really only solving half the problem which is that the Shape hierarchy is totally separate from the drawing hierarchy. But how to combine the drawing hierarchy in, is never explicitly explained in the final solution. There are a few that make sense to me (having an IRenderer interface, having n*m free functions like draw(const Circle&, OpenGlRenderer), draw(const Circle&, MetalRenderer&), draw(const Square&, OpenGlRenderer), etc). I believe the solution is there, but the presenter really should have gone the extra step to fully prove it.

@edobez

Жыл бұрын

I agree with you. For the first solution that you proposed (IRenderer), don’t we fall into the same hierarchy problems?

Excited

Excelent talk!

@CppCon

2 жыл бұрын

Glad you enjoyed it

I am inspired!

Seems to me if you're going to critique the simple inheritance model for having MetalBigEndianCircle *and* MetalLittleEndianCircle your final solution should support that too.

This is great, and I can't agree more that using inheritance as interface is one of the worst mistakes one can make in library design.

Amazing. This design pattern brings efficient existential types to the C++ world. Nicely presented as well.

@CppCon

2 жыл бұрын

Many thanks!

The answer was pod structs and free functions all along!

This is the first talk I've listened to on Type Erasure and Klaus beautifully lays down the concepts. Can you provide a link to the slides or the code used in the slides? PS : The description has a link to the repo for CppCon2020 and not 2021.

@CppCon

2 жыл бұрын

Thank you for bringing this to our attention. We are in the process of remedying this incorrect link.

@ratman-gimmecheez

Жыл бұрын

@@CppCon Any news on this?

@artemfediai7206

4 ай бұрын

@@CppConany news on that?

awesome!

@CppCon

2 жыл бұрын

Thanks!

The 'draw' and 'serialize' functions from the 'Shape' class should have example parameters entered instead of /*...*/. Eg another TE wrapper, 'Renderer'. Without it, you can't see at first glance how 'Shape' allows you to choose/change an implementation (which is easily noticeable when using a Strategy pattern).

@edobez

Жыл бұрын

I’m in fact trying to understand where the actual strategies would fit here

Is the example code from this talk available anywhere ? I can#t get the examples in the .pdf to compile and I'm pulling my hair out...

thank you

@CppCon

2 жыл бұрын

You're welcome

wonderful talk, i think external polymorphism is similar to crtp

at 29:15, why is the T&& passed to the ShapeModel constructor a rvalue reference? I thought it's a forwarding/universal reference, because it's a template with double &

@binary132

3 ай бұрын

It means the ownership is being transferred into the ShapeModel.

Hi Klaus, the C++ community, and CppCon... I am trying to follow along with your slides and implement this toy as exploration into a design I'm working on. For this, I'm sticking with the same code structure, just changing the names to look more like my application. What I am running into is a compiler error I don't understand (MS Visual Studio 2019, uses C++14) And it doesn't like it when I instantiate the "shape" class with a, say a "circle" (again I'm using different names). The complaint is where I am instantiating the pimple in the templated constructor (introduced at 35:29 in the video) pimpl { new Model(x) } And I get "error C2664: 'Shape::Model::Model(T &&)': Can't convert argument 1 from 'const T' to 'T &&' on the line... What am I missing? You mentioned some other resources where you (or others) go into details of this implementation in other talks, but not in the notes in show notes. Hope you can point out my issue or point me to where the discussion is more details. Thanks in advance!

@kjhgaseiyufbef1604

2 жыл бұрын

in a sibling comment hung biu suggests using Model::template Model(U&& u)

Thanks for the great talk! I gave it a shot and tried to implement the example. However, the constructor of ShapeModel with T&& and std::forward did not work for me. Instead, I tried a T const& without std::forward, as you described in earlier talks. That did work just fine. The error was "cannot bind rvalue reference of type 'Circle&&' to lvalue of type 'const Circle'. Is the code shown on the slides actually working, or did I mess up?

@ww-hc3qz

2 жыл бұрын

you are right，

@hungbiu8609

2 жыл бұрын

Change Model ctor to a templated ctor with additional type parameter like "Model::template Model(U&& u)". The problem is that given a concrete type argument Circle for class template Model, the ctor shown in the slides will be instantiated as "Model::Model(Circle&&)", hence it won't accept anything other than rvalue (yes the ctor shown in the slide is broken). However, if the Model ctor is supplied with another type parameter U, then compiler could substitute U with "const Circle" and instantiate the ctor as intented like this: "Model::template Model(const Circle&)". A forwarding reference should be independently deduced.

@kjhgaseiyufbef1604

2 жыл бұрын

You have to use a forwarding constructor with universal references and std::forward the arguments. However, if the forwarding constructor is templated, you also need to restrict it to work on all types except the type of the class, so that it doesn't shadow the copy constructor in overload resolution.

Where could I get the PPT of the above presentation?

OMG, I see Dr. Douglas Schmidt here :)

A question on the templated constructor. What if the constructor for Circle take a single parameter radius, but the Square constructor takes two, width and the height?

@edobez

Жыл бұрын

Did you find an answer for that?

@habits12

Жыл бұрын

You pass to shape constructor a concrete shape concept instance. You will fully construct a square with two parameters and pass it to shape, or circle with one parameter. Does it answer your question?

How can I invoke the overridden clone() member function of the ShapeModel class, and who is responsible for calling it? Can you assist me in comprehending this?

Great talk but doesn't compile (in VS2022 at least). It can't find the free functions for draw() and serialize(). If you rename these functions in ShapeConcept, e.g. to serialize_ and draw_, the compiler seems happier. The templated constructor for Shape doesn't appear to work either when you take the const lvalue reference, but seems happier with a forwarding reference.

@jamesbond0705

Жыл бұрын

For your problems (name-hiding and binding const lvalue ref to rvalue), the speaker corrects them in his 2022 CppCon talk. Please check P.19 and P.29 of cppcon.b-cdn.net/wp-content/uploads/2022/09/Type-Erasure-The-Implementation-Details-Klaus-Iglberger-CppCon-2022.pdf

Hi, guys! What design patterns are used in Type Erasure?

Also recommend checking out the talk "Runtime Polymorphism: Back to the Basics" from Louis Dionne who is the author of dyno

@Swedishnbkongu

2 жыл бұрын

And Sean Parents talk (on which o think Louis' is based or credits), better code: polymorphism

This seems very interesting but I’m having trouble reconciling both parts of the talk. The first part talks about a pattern for decoupling dependencies, via the Strategy pattern, and the second part presents a type erasure solution that is useful for collections of objects of different types that collectively conform to some interface. Where does the drawing strategy (e.g. OpenGL or Vulcan) fit into the TE design? Is the strategy passed into the Shape Draw function? How do the specific details of the actual shape (e.g. radius for circle) end up being accessible to an actual draw implementation? Or to swap it around, how does a Circle (which we can’t change) know anything about how to use, say, an OpenGL context to draw itself? I don’t see how erasing the type helps solve the original problem of decoupling the dependencies. What am I missing?

@jimhewes7507

Ай бұрын

I think type erasure is not a very good name for it. I think it's really just an inverse bridge pattern. The type is still there. But the type now just applies to the implementation (the functions) rather than to the data (the structure, Circle, Square.) In the bridge pattern we've handed to the class the implementation it should use. In "type erasure", or inverse bridge, we've handed to the implementation the class or data it should use. So now we're passing around a ShapeConcept (OpenGL or Vulcan) with a Circle inside of it instead of passing around a Circle (i.e. its base class Shape) with an OpenGL or Vulcan implementation inside of it. What's the difference? I wondered that myself. But I think the important thing is that a type is better identified as what implementation or interface it supports than what data it has. So we separate out the data by (inverse bridge pattern) and just identify the type by it's implementation. When we pass a thing to a function we typically only want to know what functions it supports. So it's better when a type tells you what the implementation is rather than what the data is.

Since the number of shape types is known at compile time, why not a tuple of vectors of shapes? In addition, non-instrusive serialization libraries are available, e.g. CEREAL.

Ok, so I have a collection of Shape objects including shapes like Circle, Square and Triangle. Now I want to find the average radius of all the Circle objects. How do I do that? I'll need to loop over all the Shape objects in the collection. I don't want to have to put a GetRadius() function in the ShapeConcept class because it's irrelevant to the Square and Triangle classes. Some functions are common to all Shapes like draw() and serialize() but some are specific to a particular Shape. I may want to use those functions. Not easy to do with this type erasure pattern.

Is this technique equivalent to type traits in rust?

@pushqrdx

2 жыл бұрын

90% sure it is, or at least they achieve the same means, i am not sure about implementation details

Slides are not in your Github page. I cannot access it.

Hm. "We dont have to deal with inheritance anymore". We still have virtual dispatch, dpnt we?

Gonna totally make a better example than shapes

This appears to be almost exactly a C++ implementation of the Rust trait system's fat-pointer type erasure.

Why not use variant instead of type erasure ?

awesome but I'm worried that it has pimples , have to squeeze the pus out of them lol🤠 seriously completely blown away took a bit of concentration but it's really obvious when you get it

@francisgrizzlysmit4715

Жыл бұрын

really clever love the loose coupling

Unfortunately I don’t see any “beauty” in this implementation because this still requires us to write boilerplate code and I don’t want to use any library for such simple things that a language is supposed to provide.

Interesting topic, incredibly slow delivery. This could've easily fit into 20 minutes just like the first talk about the topic he mentioned.

@kjhgaseiyufbef1604

2 жыл бұрын

1) he is not a native speaker; 2) many viewers are not native speakers; 3) this is supposed to be an talk for most levels of knowledge and intellect; 4) I listened to this on 1.5 just fine, it's easier to speed it up than to pause and go back constantly

This is so gross Good god I hope they never build this into the language. Just code in python or JavaScript if you want to erase your types.

Found the slides here: cppcon.digital-medium.co.uk/wp-content/uploads/2021/09/Type-Erasure-A-Design-Analysis.pdf Don't have the code though, but you can whip something up from the slides. I wish we had some working code too look at though.

@kurtischarnock4304

Жыл бұрын

Hero

Amazing talk, amazing concept. Sadly it reveals how shit C++ really is. You have to jump through hoops and do a lot of bainfuckery to achieve a very simple goal: tricking your compiler into doing what you want it to do. Newer languages, that don't waste your time as much, seem to support a lot of this stuff out of the box.