This is not an example of polymorphism nor is it an example of a pattern. It's just an example of using a bool variable and nothing else (apart from a thick layer of huskies).
There is no way templates can replace polymorphism.
And where did I state otherwise? The point is that polymorphism tries to replace templates.
It is rather you are trying to replace the normal OOP approach with a crutch) Templates are in fact only needed for stored data and in some interfaces like IComparable<T>.
There are practically no performance benefits from them. In your second sample the compiler inlays everything, because everything is unambiguous there.
It is rather you are trying to replace the normal OOP approach with a crutch) Templates are in fact only needed for stored data and in some interfaces like IComparable<T>.
There are practically no performance benefits from them. In your second example, the compiler inlays everything, because everything is unambiguous there.
It's not my example, it's a classic example of dependency inversion. And don't pick on its simplicity, it just demonstrates an idea, if I wrote a sheet of code would you say "well yeah, that's a different thing"?
Templates have become a crutch, yes . . All right, I'll call it a day.
By the way, back to void*, I've just realized that even dynamic_cast does not work (does not compile) with it in C++, which is logical, because we just have an impersonal pointer to a memory area. That's why it can only be cast explicitly. Correspondingly, we need to know for sure what type lies there. That's why void* by itself is useless in C++. Everything is different in MQL. But for compatibility purposes we should avoid using dynamic_cast and delete with pointers of void* type
Button lamp through g with virtuality:
hackneyed examples.
This is not an example of polymorphism nor is it an example of a pattern. It's just an example of using a bool variable and nothing else (apart from a thick layer of huskies).
There is no way templates can replace polymorphism.
Templates cannot replace polymorphism in any way.
Where did I say otherwise? The point is that polymorphism is trying to replace templates.
And where did I state otherwise? The point is that polymorphism tries to replace templates.
It is rather you are trying to replace the normal OOP approach with a crutch) Templates are in fact only needed for stored data and in some interfaces like IComparable<T>.
There are practically no performance benefits from them. In your second sample the compiler inlays everything, because everything is unambiguous there.
It is rather you are trying to replace the normal OOP approach with a crutch) Templates are in fact only needed for stored data and in some interfaces like IComparable<T>.
There are practically no performance benefits from them. In your second example, the compiler inlays everything, because everything is unambiguous there.
It's not my example, it's a classic example of dependency inversion. And don't pick on its simplicity, it just demonstrates an idea, if I wrote a sheet of code would you say "well yeah, that's a different thing"?
Templates have become a crutch, yes . . All right, I'll call it a day.