Amount of code to write and support, potentially the duration of compilation

Template it is good solution but it may be also have bad performance. It depends on the architecture and on the page size.... If you have very slow memory and very fat cpu RTTI may be preferable.

For user of the lib or for developer...

This is very specific example And optimizing such stuff first - very stupid "Premature optimization is the root of all evil"

I did not start the performance disscutions. We need improve performance only when it needed. The readability always preferred.

The alternative is the templates which are less error-prone and more performant on the runtime

I thing it starts here

The thing is if you need something that have more than.. say 10 parameters.. your design is bad

10??? More then 4 make a class or configurator

And Pavel tries to optimize something that should not be optimized with careful consideration and proper benchmarks IMHO

Well, there were talking about hundreds and thousands.. so at this point 4 or 10 are basically the same

And the other thing you should almost never prefer void* or std::any to templates

Aren't these completely different things? std::any and void* are for dynamic polymorphism and templates for the static one. I can't implement dynamic polymorphism with only templates

There are such people called C programmers, they have no static polymorphism

Aren't these completely different things? std::any and void* are for dynamic polymorphism and templates for the static one. I can't implement dynamic polymorphism with only templates

There are such people called C programmers, they have no static polymorphism

Ok in my case it is actually static, but doing it only through templates would be very painful

You mean dynamic?

Ok in my case it is actually static, but doing it only through templates would be very painful

If you are afrade of an error of templates chatGPT helps very well with it.

Not errors, horrors of parametrizing everything with every type that is going to be used. Imagine writing a vector each instance of which you need to parametrize with every type you want to store in vectors thoughout your application.

Polymorphism is "one name for different things" What you showed as an example "different names for one thing"

You have a typedef

I think we're talking about different things to be honest

Not errors, horrors of parametrizing everything with every type that is going to be used. Imagine writing a vector each instance of which you need to parametrize with every type you want to store in vectors thoughout your application.

So?

I was wrong. You are right. I mess static polymorphism with static cast. Two years of python programming makes me stupid. No, the C programming language does not have a built-in mechanism for static polymorphism like C++ does. Static polymorphism, also known as compile-time polymorphism, is achieved in C++ through features such as function overloading, templates, and inheritance.

You forgot one cool feature for compile-time polymorphism: constexpr

Like IPlayer, IGameObject - whatever

And how is this a polymorphism feature?

It’s a compile-time thing in itself. Let me show you a code.

You didn't answer my question and your example probably will not

In C++, a constexpr expression is an expression that can be evaluated at compile-time. The keyword "constexpr" is used to declare a function, object, or variable as being eligible for evaluation at compile-time

See and you will find out: struct Animal { virtual constexpr ~Animal() = default; virtual constexpr std::size_t num_legs() const = 0; }; struct Duck : Animal { constexpr std::size_t num_legs() const override { return 2; } }; struct Cat : Animal { constexpr std::size_t num_legs() const override { return 4; } }; constexpr std::size_t count_legs(const auto animals) { std::size_t legs{ 0 }; for (const auto a : animals) legs += a->num_legs(); return legs; } int main() { constexpr Duck d; constexpr Cat c; static_assert(count_legs(std::array<const Animal*, 2>{&d, & c}) == 6); } C++20 new feature: Compile time polymorphism!

That's not quite right If a function is constexpr, it can be evaluated both in compile-time or runtime If a variable is constexpr, it's always evaluated at compile-time

That's not quite right If a function is constexpr, it can be evaluated both in compile-time or runtime If a variable is constexpr, it's always evaluated at compile-time

No. There’s no certainty of evaluation at compile time with constexpr. If you want certainty use consteval

It depends on a standard you use.

It's important to note that constexpr expressions have certain restrictions. They must be composed of a subset of the C++ language that can be evaluated at compile-time, and they must be free of side effects. However, C++11, C++14, and C++17 introduced enhancements to the constexpr mechanism, expanding the range of expressions and functions that can be evaluated at compile-time.

Reread my message again and again

Define variable! An ‘std::vector’ is a variable object which cannot be constexpr. But I got what you meant. E.g., constexpr static size_t n {5};

That's not quite right If a function is constexpr, it can be evaluated both in compile-time or runtime If a variable is constexpr, it's always evaluated at compile-time

Here.

When you want complete guarantees on an object to be evaluated at compile time, as Turner said, you must declare it as static constexpr If guess, consteval will do the same too.

When you want complete guarantees on an object to be evaluated at compile time, as Turner said, you must declare it as static constexpr If guess, consteval will do the same too.