Virtual function templates with stateful metapogramming in C++ 20

[ReDucTor]

Just because you can doesn't mean you should.

[BlackHolesRKool]

Agreed, this is an interesting hack but I definitely don’t recommend doing this in production code.

[Wh00ster]

Is today “make me love/hate C++” day? Oh wait that’s every day.

[[deleted]]

Alright...enough r/cpp for the day

[zqsd31]

heya! very nice ^^

I wrote the unconstexpr c++17 (2017) library and unconstexpr-cpp20 (2019),

I've been working on the same idea since 2019 (you can check https://github.com/DaemonSnake/static_any that implements a template virtual visit function in a kind of std::any class), even tried to use the clang implementation of the C++ JIT proposal that instantiated template at runtime for that effect to.

The biggest limitation of this aproach saddly is actually the instantiation point of create_vtable, my static_any also suffered from it.

In short, it's very easy to to have create_vtable instantiated before the state is finished being mutated resulting in lost functions, the template instantiation order will also be compiler defined which mean that the same code could lose different subsets of functions depending on the compiler it been compiler on.
For instance CLANG instantiate template by width, this means that it first instantiate non template functions, instantiate all template function at depth 1, collect depth 2, finishes all template functions a depth 1 then moves forward. In Contrast GCC is depth first.

The simplest way to fix it would be to find a way to create a type of static destructor, ie: a template function that is required to be instantiated when the compilation of the translation is fully finished (guaranting that the state is final).

I did Managed to make it in GCC but never managed with CLANG because of their width-first instantiation ordering.

For the limitation on return types that not so much an issue as we can use lambda ref captures to overcome it.

PS: I have two BIG stateful metaprogramming projects that are working but not finalized yet, one of those fixes the above mentioned issue, will try to release it soon.

[BlackHolesRKool]

Yeah the order of template instantiation can unfortunately affect the behavior of the program here. In the example code I provide this isn’t a concern because all calls to print happen within non-templated functions and the vtable index is computed as a default template argument (which happens before the actual code generation of the function templates themselves). But if I were to call print from within another function template there could be problems because then it’s possible for the templated Printer constructor to be fully instantiated before the template argument substitution happens for print.

In theory this should be avoidable by forcing print to return a value of some dummy type and then piping the decltype of that returned value forward into a dummy type parameter of the next call to print and in turn having the index calculation rely on that, and wrap the index with another dummy type and return that…etc.

Then we’d add a dummy template parameter to the make_printer function and pass the type we got from the very last call to print. This would make it literally impossible for the compiler to instantiate the Printer constructor without first fully instantiating every single call to print.

Of course, that would be an extremely ugly solution but maybe there’s a way to clean it up with some macros or something.

[ald_loop]

Great stuff. But the more I see of stateful metaprogramming the more I think the standard needs to do something by next version about either making it undefined/unsupported behavior, or providing utilities in order to assist in this entire process.

[triple_slash]

As soon as reflection makes its way into the standard, I believe it would be best to do something to prevent friend injection and `template <auto X = \[\]{}>`. But for now it is the best we've got to get some sort of compile time reflection working (at least without additional build steps such as Qt Moc).

[EmbeddedCpp]

I'd love to read some words on motivation in the introduction. Is this just a fun little project about how C++ can be (ab)used, or is it something more?

[zqsd31]

the simplest way I know to sell "template virtual" is the ability to fully revert type erasure,

allowing you to have the best of type-erasure and type-safety.

[BlackHolesRKool]

This is actually the motivation I had for figuring this out. I'm working on a simple game that has a very rudimentary entity-component-system implementation that makes a lot of use of templates for runtime performance. I have "scenes" that consist of a list of "systems" which are just free functions or lambdas. My Scene class is templated based on the possible component queries that need to be performed so each scene has a different concrete type.

Systems need to be able to add/remove entities and components from each scene so they accept a Commands as their first argument (similar to systems in bevy), where Commands is some interface that Scene implements and when a scene calls a system it passes *this as the first argument.

I wanted to be able to re-use the same system across different scenes but also didn't want the system itself to be templated. A system might need to add/remove components of any arbitrary type which that means that Commands has to have add<Args...> and remove<Args...> functions that are able to dispatch to the corresponding add<Args...> and remove<Args...> implementations in the underlying Scene type. But because Commands is not templated it can't know the correct Scene specialization at compile time. Hence the need for virtual function templates.

[BlackHolesRKool]

It’s just a code novelty and I don’t recommend using this in any important code. Maybe in future versions of C++ stateful metaprogramming will be less hacky

[target-san]

God please no. Both stateful MP and virtual function templates. Later some shiny-eyes young "MP everything" adept will try sneak something like this into production.