What's Wrong with C++ Templates? (2003)

This claim needs some support. C++ has notoriously slow compile times, but note that he's talking about efficiency of the code generated, not the efficiency of code generation itself, which I agree is damaged by templates.

> It might surprise you to hear that, considering that C++ is "efficient" while functional languages like ML and Scheme are "inefficient," but it's true. C++ templates hide your intentions from the compiler: did you mean type abstraction? Did you mean a syntax extension? Did you mean constant-folding or compile-time code generation? The compiler doesn't know, so it has to just blindly apply the copy-and-paste strategy and then see what happens.

I'm going to propose that this isn't a bug, it's a feature. The optimizer should be completely independent of syntax - and that's what C++ templates are, automatic AST expanders (plus some compile-time computation). All that the optimizer sees in the end are basically unrolled assembly instructions or IR, and we have battle-tested techniques to optimize this. Most of the heavy-duty optimizations in modern industrial compilers happen on the linear IR representation anyway.

While templated code can be fatter than non-, link-time optimization can often reduce bloat when your your ad-hoc polymorphic template is really just acting as a parametric-polymorphic function a la ML.

Now that I've played devil's advocate, someone more familiar with GHC, please tell me how Haskell has optimizations (e.g. deforestation? or is that just a solution for a problem that is specific to Haskell in the first place?) that make my assertions above untrue :)

And in my opinion, legibility is an extremely important feature when you're writing code that you plan to understand and maintain for years.

Writting less code is a nice-to-have, but if the cost is that it's a complete mess, I'm out.

Said another way: writing is ugly, and reading is inscrutable.

I'm not sure there's strong evidence (certainly none presented) about performance, etc

The gist of its workings is including a header and defining its type:

    #define T int
    #include <vec.h>

    #define T float
    #include <lst.h>

    #define T str
    #include <deq.h>

    typedef struct { void* data; } blob;
    blob blob_copy(blob* self) { ... } // Copy constructor
    void blob_free(blob* self) { ... } // Destructor
    blob blob_init(void* data) { ... } // Constructor
    blob blob_init_default(void) { ... } // Default constructor
    #define T blob
    #include <vec.h>

    int main(void)
    {
         vec_blob blobs = vec_blob_init();
         vec_bloc_push_back(&blobs, blob_init(...)); // Invokes constructor, element 0, passed by value
         vec_blob_resize(&blobs, 42); // Invokes default constructor for elements 1-42.
         vec_blob copy = vec_blob_copy(&blobs); // Invokes copy constructor for elements 0-42.
         vec_blob_free(&blobs); // Invokes destructor for elements 0-42.
         vec_blob_free(&copy);
    }

I don't use either of these tricks much. Metaprogramming is especially bad, pretty much unreadable once written.

There's a third useful thing people do with templates - pass integer numbers to compiler. Unlike meta-programming, doesn't hurt readability.

There're instructions like _mm_shuffle_ps or _mm_srli_epi16 or _mm_extract_epi32 which encode an integer into machine codes. Instructions can encode memory references like `ptr [rax+32]`. And even without low-level trickery, it's sometimes useful to compile the same code multiple times, with changes somewhere. Templates is an easy way to express that in C++, here's an example: https://stackoverflow.com/a/59495197/126995. A nice related feature is `if constexpr` from C++/17, such branches are resolved at compile-time and therefore free.

The main problem with templates are the compiler error messages.