Dynamic Polymorphism with Metaclasses and Code Injection - Sy Brand - CppCon 2020

cppcon.org/
github.com/CppCon/CppCon2020
---
Dynamic polymorphism in C++ has historically meant virtual functions and inheritance. However, these form only one possible design for solving this problem, and they bring several implications on performance, ergonomics and flexibility. Type erasure is another way to implement dynamic polymorphism, as demonstrated in several talks by Sean Parent and adopted in other languages, such as Rust’s trait objects. But implementing type erasing objects which provide ergonomic interfaces in C++ is cumbersome and error-prone, leading to a large family of types and libraries with subtly different semantics and lower adoption rates compared to inheritance.
This talk will present a possible future design for interface-based type erasure in C++ that marries the convenience of inheritance to the benefits which it otherwise lacks. It will introduce the code injection and metaclasses facilities which are proposed for inclusion in C++ along with a prototype implementation of the design based on the experimental metaclasses Clang fork.
---
Sy Brand is Microsoft’s C++ Developer Advocate. Their background is in compilers and debuggers for embedded accelerators, but they’re also interested in generic library design, metaprogramming, functional-style C++, undefined behaviour, and making our communities more welcoming and inclusive.
---
Streamed & Edited by Digital Medium Ltd - events.digital-medium.co.uk
[e-mail]
*-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----*

[@adamodimattia]

Dynamic polymorphism personified!🎉

[@debashishdeka7698]

The initial vtable implementation is what I was looking for. Thank you for such a great talk.

[@CppCon]

Great to hear!

[@dgkimpton]

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.

[@vaderasss]

This is like watching the movie back to the future for c++

[@TNothingFree]

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

[@klaus13337]

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

[@robrick9361]

Is the block evaluation consteval valid in C++20?

[@jmparis83]

Mind blowing ! Great talk, thanks!

[@ihormay3418]

Great talk! Really enjoyed the material

[@joesilver75]

great talk

[@OperationDarkside]

I really want some of this to make general serialization possible. Web development with C++ isn't really a nice experience atm.

[@Swedishnbkongu]

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?

[@rolandschulz6811]

Links to libraries: github.com/boost-ext/te#similar-libraries

[@jhbonarius]

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

[@jhbonarius]

These structures seem so re-usable, that IMHO they should be part of a standard library. (When reflection becomes part of the standard)

[@foible2085]

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.

[@HasanKamalAlDeen]

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.

[@relegarum]

Amazing talk, Sy! One of the most inspiring ones at cppcon this year!

[@rinkaenbyou4816]

1:07 "Perks of virtual conferences"

[@larssamsung3033]

One has to hate macros A LOT to think that code is nicer.

[@stephenjames2951]

Null it is the nothing we spend too much time caring about.

[@LDdrums20]

So this is basically c++ wanting to be c#. Am I getting it wrong?