It's just ugly.
I've been using C++ as my main language since it was barely out of C with Classes stage and it pains me to see how it evolved from a language that extended C in clever and welcomed ways into this piece of committee-designed monstrosity with not a trace of its former elegance left in it.
std::auto_ptr is pretty bad, and so in C++ 11 they deprecate auto_ptr and introduced std::shared_ptr and std::unique_ptr so now finally their language has halfway usable pointers, with these unwieldy names and some odd semantics you just have to get used to. C-style pointers remain all of: Simpler to use by virtue of their terse syntax, still necessary, and unsafe. std::auto_ptr still exists forever, but is officially deprecated.
At first C lacks strings, promoting string literals to a strange array with an extra zero value in it. Eventually C++ gets std::string and std::wstring but, nothing of value about these strings is defined, so they're both pretty useless and of course dangerous. In C++ 17 it gets std::string_view which finally expresses one of the things you probably first wanted, but it provides no enforcement of the most obvious expectation you have - C++ allows a string_view to outlive the underlying string, causing Undefined Behaviour. In C++ 20 you get to use ranged behaviour, and, that extra zero value bites you hard because of course you didn't mean the zero value but in C++ that's "part" of your string. They also, finally, decide that UTF-8 might be a good idea and define yet another type of string to mean UTF-8 encoded, about five years after everybody who matters was of course encoding strings as UTF-8.
std::auto_ptr is fully removed since C++17.
I agree with most of your comment, but I think it reinforces the grandparent's point. The warts of std::string and null terminated strings are not "problems introduced by C++'s other recent additions".
So it's strange to provide them with stuff like terse built-in syntax, while not providing anything similar for the thing people will want all the time, ownership. Result: The Right Thing™ is harder to do and wastes visual space compared to the Wrong Thing. A "correct" program ends up full of boilerplate just to get what you'd obviously want.
Such as what? std::string_view represents exactly one thing, and that’s a slice into a string with a lifetime longer than it. That’s basically it. There aren’t really and other additional feature to it, so I feel like you may be confused as to what it does.
In 2011 there probably wasn't a mainstream non-GC language doing that. C++ would have been innovating here, and maybe C++ in 2011 didn't want to be innovating. By 2017 when C++ 17 introduces std::string_view it's behind the curve, this is not an exciting new feature, it's a weak imitation of what everybody else was already doing better.
> Well, the standard library doesn't have matrices or regular expressions, either
C++ does provide a standard regex library now, matrices can be made either with vectors or you can use boost libs for it.
> The standard library doesn't support listing directories
Same for filesystems, it now comes with the standard set of libraries
For C++, it’s time and time again seen, that Boost libs are used as the experimentation stage to filter things and add to the C++ standard library, and boost is pretty feature rich with all sorts of utilities you might need to build a robust program.
> In C++, things are different - there are no modules.
C++20 is adding features related to modules support like in other programming languages (haskell, etc).
Sure C++ is an old programming language with too many weird features, which end up hurting devs , but as long as you stick to the fine features.
C++ is pretty fun to use. It has type inference now, those ugly looking long type-declarations, can easily be fixed by appropriate use of the “using” keyword in local scope (if you’re that worried about polluting the global namespace i.e)
I think C++ gets unnecessary hate , every language has its quirks, you just avoid the bad stuff and stick with the good bits.
C++ is the single most complex programming language ever devised. I don't think it deserves hate per se, but it there is no other language as hard to learn, as hard to write safe code for, and as hard to read.
Even your example of type inference is actually very hard to learn. If I do `auto x = 7;` will x be const or not? If I have `const int &y = 7; auto x = y;` will x be const int? int? const int&? What if it's a pointer, or volatile instead?
The simplest answer to your question of how to know what type the compiler will choose for type inferenced variables, is by compiling an example code snippet and printing out the type using either something like decltype or typeid (preferably the former).
But the thing is, the point of type inference is you want to abstract away the type, if you want to explicitly be aware of the type at all times, you should explicitly state it in declarations.
The issues described is inherent in the very notion of letting the compiler infer the type for you, which leads to this ambiguity.
If you want to avoid it, then best to be explicit, if you dont care about the type and are using typeinference to build compile time simple template functions using lambda and the type inferred parameters. Then type inference is pretty handy and leads to easy to read code.
It’s a tool, when you feel it’s getting in your way at writing code, you remove the tool/feature from your code.
> The issues described is inherent in the very notion of letting the compiler infer the type for you, which leads to this ambiguity.
It's not the same thing. Types and type qualifiers are different things, and few languages have type qualifiers in the same way as C++. In fact, auto, unlike type inference in any other language, does NOT match the full type of the variable - that's why things like `volatile auto &x = y` exist.
> But the thing is, the point of type inference is you want to abstract away the type
That's the point in other languages. In C++ it's much more just shorthand for the horribly long type names you end up with in templates.
Template parameter inference, which mostly uses the same rules, is probably required in some SFINAE constructs, but is also not essential in other places.
Also, I think it's a bit ludicrous to say "just use a subset" because there's no definitive guide to "sane" or safe subset.
Also, regarding boost: I'm extremely conflicted about it... On one hand, it's made my life easier, but on the other it feels like once you add it to the codebase it metastases everywhere; it's not a C++ codebase anymote, but a boost codebase. Also, it ill-composes with most things that aren't boost (and sometimes even within other parts of boost, because boost is an amalgamation of libraries)