C++ continues its long journey to making its template system an actual usable programming language.
The infamous template error messages are generally a result of two things: first, too many candidate functions because logic is cobbled together out of a nest of SFINAE overloads, which is ameliorated by moving the logic into normal code with if constexpr, etc; and second, type errors occurring deep in the call/expansion stack because unchecked values keep getting passed on just like in a dynamically typed language (which TMP basically is), which is ameliorated by moving the type checks higher up in the stack with concepts or static_assert.
50? That's it!? I work in a code base where a previous developer went nuts with overloads and I routinely get hundreds of lines of output for a single compiler error.
IDE's make this less of a problem.
You can use enable_if and static_assert, alongside type traits to check the types, and give useful error messages.
With C++20 you get concepts lite, which while not being as good as C++0x concepts, still simplify the code a lot, improve error messages, and remove the need for the classical tricks, when used alongside constexpr.
No need to go crazy with them.
C preprocessor macros are a hack, they are useful, but they come with plenty of issues. If you are using macros, there is a good chance there is a superior solution that uses templates.
Abstract classes impact performance, sometimes significantly, and it doesn't solve all problems templates solve. If you don't care, then you would probably be better off doing Java (or languages in the same family) than C++.
If you are not using genericity at all, it may actually be a good thing! Too much abstraction is a common problem. But sometimes you need it. Refusing to use generics will limit what you can do. And if it is your job, it will probably limit your pay too.
At least, as convuluted as C++ may be, template and compile time programming still rely on C++.
But in Rust, you don't need to delve into any kind of macro for polymorphism like you do in C++, since Rust has a real generics system. There is vastly more C++ code that instantiates templates than Rust code that uses macros.
Given that Rust IO and many crate attributes are macro based, not sure who wins out.
The only thing you may complain about are error messages due to duck typing at compile time gone wrong, and even that is kind of already sorted out in C++17.
Anyway, C++ today means C++23.
Naturally checking for speak() existence with enable_if, static_assert and type traits could be added, though this is an example, and nowdays we would make use of concepts anyway.
#include <iostream>
using namespace std;
class Duck {
public:
void speak() const {
cout << "quack";
}
};
class Dog {
public:
void speak() const {
cout << "auau";
}
};
class Cat {
public:
void speak() const {
cout << "miau";
}
};
template<typename T>
void speaking_animal(const T& animal) {
animal.speak();
cout << "\n\n";
}
template<typename... T>
void speaking_farm(const T&... animals) {
auto space_adder = [&](auto creature) -> void {
creature.speak();
cout << " ";
};
(space_adder(animals), ...);
}
int main() {
Duck duck;
Dog dog;
Cat cat;
speaking_animal(duck);
speaking_animal(dog);
speaking_animal(cat);
speaking_farm(duck, dog, cat);
}
It feels like programming in the last five years has turned into a competition of who can make the most abstract meta programming patterns. I think if you find yourself making use of this feature, you’re probably in a deep hole of your own making.
What is an example of a useful function that takes an arbitrary number of arguments each of which has an arbitrary type that isn’t as trivial as the examples given in the article? For super trivial stuff this is useful, and if std used this under the hood to provide std::first_arg or something, that would make sense. But the absence of this language feature doesn’t really seem like it’s holding back 99.9% of users.
Imagine what it could have been if it was designed for programmability from the start.
Circle C++ compiler was designed for that: https://www.circle-lang.org/quickref.html
You have to suck people in with, "hey, you can write these two similar C-like functions under one definition, the correct one of which is automatically deduced and used".
Because, how do you use it? How do you add debug printing to try and understand where the bug is? How do you debug even anything?
Like, suppose your concept has a composite requires statement that invokes a constexpr predicate of two derived types, and it is not "true" as you expected, so overload resolution picks the wrong function.
What is the analog of gdb to use in this situation?