
A brief guide to C++ template metaprogramming - Halienja
https://github.com/MCGallaspy/dr_strangetemplate
======
TickleSteve
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.

------
shin_lao
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.

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

------
cubaia
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.

~~~
userbinator
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."

~~~
gpderetta
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.

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

------
qwertyuiop924
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.

~~~
webreac
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.

~~~
qwertyuiop924
...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.

~~~
gpderetta
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.

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

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

~~~
ansgri
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.

