What a fantastic talk. I love the fact that you were able to pull together all these concepts into a single extremely useful scenario, present it in all in less than an hour, and leave me drooling about the future possibilities. I'm not sure whether to be super excited about the future or super frustrated that we don't have these things yet. Metaclasses are just fantastic, code injection is killer, and with static reflection will do a lot to eliminate macros (finally). Some of the syntax is just gnarly, I guess that's the price of backwards compatibility, but the final result is so expressive and awesome. Anyway, thank you so much for sharing this talk, great food for thought.
Animal a = Cat{}; a.Speak();.... "I am a Miezekatze!" Awesome, great talk! I never really thought about making something like this work using modern C++.
Good thing C++ is keeping up with the best practices. Meta infromation with static compilation would result in very efficient generic code. I just hope it would be readable as well :D
I've often thought to myself value semantics are fine with runtime polymorphism if child classes do not introduce extra state. Then the slicing doesn't matter, and the vtable pointer is copied. Any disagreements?
How would the compiler be able to use in-place storage for the concrete type? Since there can be arbitrarily many concrete types, would the compiler need to enumerate all instantiations before deciding on the in-place storage size? It seems like another language feature would be needed to achieve this? I guess there can be a predetermined size specified and just compiler error if it doesn't fit? The SBO is a cool idea.
Late to the party but you got it in that last sentence. Sy described a storage-policy based setup, where you feed the metaclass what kind of storage policy you're looking for (code for that wasn't shown, presumably because this is still early days). The storage policy would indicate to the metaclass how you want concrete classes to be stored and he showed 3 examples: 1. Remote storage: always allocate the concrete type on the heap 2. SBO storage: specify a fixed size at the time of definition of the interface (eg when `animal` is defined); any concrete class that fits into the SBO would be copied into it, any larger type would be heap allocated 3. Local storage only: specify a fixed size at the time of definition of the interface (eg when `animal` is defined); concrete classes are _always_ copied into the local buffer. If an attempt is made to copy-in a concrete type that is too large for the buffer, a compiler error is emitted All 3 of these approaches perform the work on assignment / construction of the object, meaning that the compiler never has to enumerate classes to identify success / failure cases.
Note: if you replace the std::cout code in your godbolt example with printf, you don't get this huge ostream assembly... The copy constructor is not working though godbolt.org/z/KoxraP
![Dynamic Polymorphism With Code Injection and Metaclasses - Sy Brand [ ACCU 2021 ]](/img/1.gif)
The initial vtable implementation is what I was looking for. Thank you for such a great talk.
Great to hear!
What a fantastic talk. I love the fact that you were able to pull together all these concepts into a single extremely useful scenario, present it in all in less than an hour, and leave me drooling about the future possibilities.
I'm not sure whether to be super excited about the future or super frustrated that we don't have these things yet. Metaclasses are just fantastic, code injection is killer, and with static reflection will do a lot to eliminate macros (finally). Some of the syntax is just gnarly, I guess that's the price of backwards compatibility, but the final result is so expressive and awesome.
Anyway, thank you so much for sharing this talk, great food for thought.
Is the block evaluation consteval valid in C++20?
Animal a = Cat{}; a.Speak();.... "I am a Miezekatze!"
Awesome, great talk! I never really thought about making something like this work using modern C++.
Good thing C++ is keeping up with the best practices.
Meta infromation with static compilation would result in very efficient generic code.
I just hope it would be readable as well :D
Dynamic polymorphism personified!🎉
Amazing talk, Sy! One of the most inspiring ones at cppcon this year!
I've often thought to myself value semantics are fine with runtime polymorphism if child classes do not introduce extra state. Then the slicing doesn't matter, and the vtable pointer is copied. Any disagreements?
How would the compiler be able to use in-place storage for the concrete type? Since there can be arbitrarily many concrete types, would the compiler need to enumerate all instantiations before deciding on the in-place storage size? It seems like another language feature would be needed to achieve this? I guess there can be a predetermined size specified and just compiler error if it doesn't fit? The SBO is a cool idea.
Late to the party but you got it in that last sentence. Sy described a storage-policy based setup, where you feed the metaclass what kind of storage policy you're looking for (code for that wasn't shown, presumably because this is still early days). The storage policy would indicate to the metaclass how you want concrete classes to be stored and he showed 3 examples:
1. Remote storage: always allocate the concrete type on the heap
2. SBO storage: specify a fixed size at the time of definition of the interface (eg when `animal` is defined); any concrete class that fits into the SBO would be copied into it, any larger type would be heap allocated
3. Local storage only: specify a fixed size at the time of definition of the interface (eg when `animal` is defined); concrete classes are _always_ copied into the local buffer. If an attempt is made to copy-in a concrete type that is too large for the buffer, a compiler error is emitted
All 3 of these approaches perform the work on assignment / construction of the object, meaning that the compiler never has to enumerate classes to identify success / failure cases.
Mind blowing ! Great talk, thanks!
Links to libraries: github.com/boost-ext/te#similar-libraries
I really want some of this to make general serialization possible. Web development with C++ isn't really a nice experience atm.
Note: if you replace the std::cout code in your godbolt example with printf, you don't get this huge ostream assembly... The copy constructor is not working though godbolt.org/z/KoxraP
Great talk! Really enjoyed the material
These structures seem so re-usable, that IMHO they should be part of a standard library. (When reflection becomes part of the standard)
1:07 "Perks of virtual conferences"
One has to hate macros A LOT to think that code is nicer.
great talk
So this is basically c++ wanting to be c#. Am I getting it wrong?
Null it is the nothing we spend too much time caring about.