One of my recurring language design hot takes is that it's easier to design for speed and then make it easy to use than it is to make it easy to use and then try to speed it up.
#include <print>
#include <map>
#include <string>
int main(int argc, char** argv)
{
using namespace std::literals;
std::string foo = "foo:";
foo += argv[0];
std::map<std::string, int> m{
{foo, 123}
, {"count: "s + std::to_string(argc), 456}
};
std::println("{}", m);
}
* rvalue references
* the difference between auto, decltype, typeof
* unreadable template monstrosities
* various different flavors of "smart" pointer
* the continued existence of footguns relating to UB, dangling pointers, unexpected temporary lifetimes, etc
* total absence of a build system or package management
* legacy APIs that still take raw pointers
* concepts, a half-assed attempt at generic constraints
Where is C's build system and package management?
Yeah, because using _Generic alongside typeof and preprocessor macros isn't half-assed attempt at generics.
Now ideally we would all be using Modula-2, Ada, Delphi, VB, C#,.... and co, but given that even C compilers are nowadays written in C++, we make do with what we have, while avoiding C flaws as much as possible.
import std;
int main(int argc, char** argv)
{
using namespace std::literals;
auto foo = "foo:"s;
foo += argv[0];
std::map<std::string, int> m{
{foo, 123}
, {"count: "s + std::to_string(argc), 456}
};
std::println("{}", m);
}Since 1993, I only have used C when required to do for various reasons out of my control, or catching up with WG14 standards.