What if I would chose template static polymorphism everywhere (when possible) against dynamic polymorphism/traditional class inheritance?

Actually I am aware about some obvious disguises:

- longer compilation time (not so huge actually);

- the fact I cannot provide the compiled object files;

- the need of more forward declarations for template specialization.

- multi-level inheritance forward declarations looks a little like boilerplate code... But nothing really terrible, since I do not use a lot of level of inheritance.

But what else? Are any other real recommendations against the use & abuse of static polymorphism?

Note also in most of cases I really do not need/use at all CRTP-like techniques.

Actually, I really like to not have to deal with virtual functions if possible ( ?° ?? ?°) ( I know I am obligated to deal with them anyway, like when using DirectX COM interfaces...)

They have different purposes.

Static polymorphism lets you swap out components in different builds, and is largely a technique for implementation hiding, which can reduce compile times...

Dynamic polymorphism is dynamic and actually polymorphic.

Cases for static polymorphism can get by using dynamic polymorphism, sure (but not vice versa)... but these cases can also use the PIMPL pattern or any other implementation-hiding technique.

In general it's a bad idea to use dynamic polymorphism when all you need is implementation hiding -- there's much more lightweight ways to achieve that.

In general it's a bad idea to use inheritance...

The OP is talking about a slightly different form of static polymorphism than you are, Hodgman. I think.

I believe you're referring to the approach of declaring functions and using the build system, linker, or #ifdef's to alter the implementation, which is more of a games thing than anything in my experience.

The OP sounds like they're talking more about "traditional" C++ static polymorphism, e.g. using templates and policies and metaprogramming to generate code from abstractions rather than using dynamic dispatch to hide implementations behind abstract code.

So far as what the OP is talking about... the biggest risks to that sort of template abuse are exactly what you outline. I think you're massively under-estimating their cost (e.g. the template thing _really does_ bloat compile times which is hard to measure with micro-tests and small hobby projects; it won't be obvious how screwed you are until your project reaches significant size and it's far too late to fix).

Fortunately, you need neither template abuse nor virtual function abuse. The trick is to not toss in abstractions of either variety except where you actually need them or they provide significant value. Or to move your abstractions up the stack (e.g. abstract over a system that manipulates a collection of objects rather than abstracting the individual objects).

I think you both partially answered my question (which made the answer complete ( ?° ?? ?°) ). Thank you.