In general I like templates.... but that example is just twisted....

Handle errors appropriately, don't wrap a C API like that for gods sake, thats just wasted code trying to be clever.

In 5 years time, someone will look at that and have to try and figure out what the you were trying to do.

I am absolutely unconvinced by the added value of wrapping the C functions. Using TMP would be useful to adapt the C functions to a different interface, but from my understanding all it does is catching the error.

Additionally, the author implements count in the worst way possible, it's highly inefficient and it will result in very long compilation time. You don't need to do tail recursion, you can just write:

template <class... T> using count = std::integral_constant<std::size_t, sizeof...(T)>;

Such errors make me uncomfortable as it seems the author isn't up to date on the topic. A+ for intent though.

agree... the example is terrible, attempting to wrap c functions like this gives you nothing but added complexity.

I think templates get a bad reputation because in practice many uses of templates are not appropriate.

Too many clever people saw 3 repetitions of a pattern and decided to show case every template trick to create a "generic library" that is compile-time optimized, usually to solve a problem that doesn't exist.

Multiply that many times through the course of a project and you end up with code that seems to try to maximizes job security.

Any abstraction can be taken too far, but I think templates tend to be particularly attractive because it is both mentally challenging and can easily produce huge volumes of code. It makes those who enjoy overcomplicating things feel productive. The same can be said of things like design patterns and "OOP extremism", but templates give that extra flair of "expertise".

On the other hand, I'm the exact opposite. I hate overly complex solutions to intrinsically simple problems. I use abstractions sparingly and only when they reduce overall, not just local complexity. Sometimes moving down a level of abstraction or two will yield a better solution. Write simple code. Focus on programming and solving the problem, not metaprogramming and the metaproblem. If you're spending weeks to write (and debug!) a huge "generic solution" spanning a dozen files and several thousand lines of code which someone else could do in an hour with a few dozen lines of code in one file, I don't think that's being clever at all. I've personally experienced this, being that "someone else".

The C++ purists will probably find this repulsive, but in some cases a macro will be the far simpler solution. What templates can do are not a strict superset of what the preprocessor can do.

"All problems in computer science can be solved by another level of indirection, except those caused by too many levels of indirection."

I'm quite fluent in both template metaprogramming and preprocessor metaprogramming. The former is significantly easier to write and understand, and, most importantly, to debug.

There are some things that can't be done via templates and you have to resort to the preprocessor, but for everything else, I will choose templates.

I do agree that premature generalization, in all forms, is often the root of all evil.

> What templates can do are not a strict superset of what the preprocessor can do.

C++ templates are Turing complete, but the C preprocessor is not.

This is great reading, and helped me clear up a few misconceptions about how SFINAE works. I really don't understand the negativity here.

Implementing generics was a good idea. However, templates were not. They should have been dismissed as a bad job years ago, and replaced by a better metaprogramming facility with less complexity, if at all possible (given the complexity of C++, it may not be). Kind of like what Rust did, by pretty much just stealing syntax-rules wholesale from Scheme.

I have discovered generics with the Ada language (yes, I am old). When learning C++ template, my first feelings were that it was an insane inconsistent hack. Many C++ compilers struggle during many years before standard was reasonably well supported. Standards have also evolved and consistency was guaranteed.

C++ template is an incredibly complex but also flexible and powerful beast that has no equivalent apart maybe the macro system of scheme. C++ templates allows to change the semantic of the program as if the language was changed. Genericity is just a special case of usage of C++ template. Its true nature is to extend the C++ language.

...The difference is, Scheme's macro system (syntax-rules: there are others) is elegant and simple, whereas C++ templates are still an insane inconsistant hack. They're just a standard insane, inconsistant hack.

But the other thing about the Scheme macro system is that while its (relative) simplicity, elegance, safety, and power lead to its adoption by other languages (most famously, JS (in the form of an external preprocessor) and rust), it's actually quite underpowered by Lisp standards, and thus most implementations provide a nonstandard system for hygenic imperative macros, usually either er/ir macros, sc/rsc macros, or syntax-case. Of the three, I'd say syntax-case is an overly complex mess, and that the other two both have merits.

So since TMP is doing similar substitutions (AFAICT: I haven't done the deep dive) to syntax-rules, it's got very real, and relatively common, limits. And as C++ slowly expands in scope, it will have to deal with problems that syntax-rules has already solved (what if a function creates a lambda or takes a function pointer argument called ioctl, and your template expansion calls ioctl?), and TMP hasn't AFAICT.

And even when they fix all that, they'll still have C++, which is about as regular as the Linux Kernel relase schedule combined with The DevTeam's.

Templates are quite complex for sure, but certainly not an hack.

They are also unlike scheme macro system which works at the AST level; C++ templates work at the type level, which scheme lacks entirely[1].

> what if a function creates a lambda or takes a function pointer argument called ioctl, and your template expansion calls ioctl?

Are you talking about macro hygiene? C++ templates are hygienic, except for type dependent lookup which intentionally isn't.

Ah, so there is hygene. I couldn't tell, so I assumed not.

Recently, I was looking into Ada and the way its generics worked was quite eye-opening.

I expected a single page that just says "Don't" in big letters :)

For this case it'd be justified (it even has lambdas!). TMP is great for data-centric code though, like math algorithms or data structure definitions with optimizations conditional on type traits.

Friends don't let friends program in C++ :) I'm holding out for Rust. Every now and then I think I should go native, then I try it and my productivity goes out of the window :/