Comment by bogwog
7 years ago
Alternatively, releasing new features every 3 years to an already-bloated language could cause even worse damage.
7 years ago
Alternatively, releasing new features every 3 years to an already-bloated language could cause even worse damage.
This suggests you aren't aware of the many huge benefits that have come from introducing modern features that other languages have. C++ since 2011 is quite a different language to what it was before, and this is hardly a bad thing. So many of the challenges of writing C++ were significantly simplified with the introduction of lambdas, smart pointers, and threading primitives.
The issue isn't that it gets new features it's that they're half-assed because you can't impose new restrictions on old code. The power of these features in modern languages comes from their ability to protect you from yourself. That has more to do with what you can't do than what you can. Bolting more legs onto C++ doesn't protect you from anything, it just increases the surface area of the language.
They haven't introduced the features other language have, they've introduced poor rip-offs that fail to work as one might expect having worked in any of the other languages they're derived from.
The problem is it's not different than it used to be, the cracked foundations are exactly the same as they've always been always been but there's a bigger and more complicated house on them. C++ is starting to feel like the Winchester mystery house.
The C++ philosophy is not about protecting you from yourself. Its about allowing you to express your idea in as low or high level terms as you require. This lets you write a highly optimized tight loop and then abstractly describe less performance sensitive parts.
In the past it was thought that people would use safer high level languages and then drop down to C for performance. That vision just doesn’t seem to work out in practice - except at the cross process level.
The trade off to this is language complexity. If you want a simple language C++ isn’t for you - and that’s OK.
39 replies →
> they've introduced poor rip-offs that fail to work
This sounds like hyperbole to me. I've worked in other functional languages professionally for many years, but when I write C++ with consistent use of std::function and lambdas, I get many of the same benefits and a very enjoyable workflow. Is it the same as Haskell or Clojure? No, because they are totally different languages. But within the C++ world, they offer a great productivity benefit that I don't think satisifies the definition of "rip off".
7 replies →
The fact that you can't make old code use the new features in no way makes the new features "half-assed". It may make the old code that, but not the features.
Or did you want them to deprecate large swathes of the previous standard?
As for the rest of your rant... it's mostly just a rant, with very little substance.
Those are all C++11 features, right? So they aren't much of an argument in favor of 14, 17, 20.
We also got Class Template Argument Deduction, structured bindings, various syntactic sugar (if (auto var = initializer) {}, if constexpr, fold expressions...), std::variant, std::optional, and a whole POSIX-style filesystem library, to name a few. And that's just C++17 alone.
It's nothing earth-shattering (that stuff is coming in C++20) but these are all features that improve the language and allow you to write better code. Consider e.g. if constexpr which can eliminate so much SFINAE cruft. Or CTAD to reduce the need for makeXYZ() functions.
14, 17 and 20 are full of small and big improvements: coroutines, contracts, modules, concepts, huge improvements for compile-time computation with constexpr, etc.
As an example, yes. Other versions offered similar benefits (C++14 in particular was a "bug fix" version for C++11, which I think most would be happy came quickly).
This. They keep adding half-finished features apparently for the sake of releasing every 3 years. Move types that may not move (std::move is just a cast / suggestion that if taken leaves the receiver in an indeterminate, useable state), pattern matching that isn't (std::variant). Frankly, I wish they'd stop.