3 ms·

The complication of templates arises from the fact that you need to know the inner workings of a C++ compiler instead of just a language definition. I know that

The complication of templates arises from the fact that you need to know the inner workings of a C++ compiler instead of just a language definition. I know that C++ is specified in a very implementation-oriented manner and I also know that many developers don't see the difference, but design ain't implementation. If you have proper macros you don't need to know the compiler internals. You have an API that generates code with the language semantics you already know. By definition that's simpler. It's also more powerful, btw.

mgaunard 5y ago
That is just not true. Compiling C++ is a very complicated task, I'd guess that there are less than a hundred people in the world with the experience of implenting a standard-conforming C++ compiler, and there are a lot more developers comfortable with templates. What exactly is your perceived problem? You need to have the template definition in order to instantiate it; that is pretty logical. Is this kind of basic common sense what you call "knowing the inner workings of the compiler"?
- choeger 5y ago
  Where shall I start? Template specialization order? Recursive template definitions for variadic arguments? Conditional template arguments? std::enable_if ?
  - mgaunard 5y ago
    Template specialization works under the same rules as overloading with some restrictions (this is actually how it is formally defined). The first step prior to overload resolution is name lookup, which discards template candidates whose declaration refers to dependent names on template parameters which wouldn't exist for that implicit instantiation. The only order that matters is what specializations are visible at the time of the instantiation, and adding more specializations after that is more likely than not to lead to ill-formed programs (due to the ODR rule that you must satisfy), so you can assume it doesn't happen. enable_if, recursion or whatever else you're referring to are merely trivial applications of the rules. I don't think it's unreasonable to have to understand how overloads are selected in order to program in C++. The semantics were not designed to match an implementation but rather to make the most sense. This has nothing to do with compiler internals; if anything many compilers implemented it incorrectly for decades.

mgaunard 5y ago

That is just not true. Compiling C++ is a very complicated task, I'd guess that there are less than a hundred people in the world with the experience of implenting a standard-conforming C++ compiler, and there are a lot more developers comfortable with templates. What exactly is your perceived problem? You need to have the template definition in order to instantiate it; that is pretty logical. Is this kind of basic common sense what you call "knowing the inner workings of the compiler"?

choeger 5y ago
Where shall I start? Template specialization order? Recursive template definitions for variadic arguments? Conditional template arguments? std::enable_if ?
- mgaunard 5y ago
  Template specialization works under the same rules as overloading with some restrictions (this is actually how it is formally defined). The first step prior to overload resolution is name lookup, which discards template candidates whose declaration refers to dependent names on template parameters which wouldn't exist for that implicit instantiation. The only order that matters is what specializations are visible at the time of the instantiation, and adding more specializations after that is more likely than not to lead to ill-formed programs (due to the ODR rule that you must satisfy), so you can assume it doesn't happen. enable_if, recursion or whatever else you're referring to are merely trivial applications of the rules. I don't think it's unreasonable to have to understand how overloads are selected in order to program in C++. The semantics were not designed to match an implementation but rather to make the most sense. This has nothing to do with compiler internals; if anything many compilers implemented it incorrectly for decades.