The 1998-2011 gap has made a lot of damage to c++ in term of "market share". I think it's necessary to avoid something similar happen again.
C++11 was a really big shakeup. In contrast, C11 isn't a major difference over C99. Sometimes I read about the rapidly evolving modern C++ and I wonder if they are moving too fast, as large chunks of the community have not even caught up with what is already there.
It was possible and common to have pretty "modern" styles in c++03, you'd just have to do without lamdbas etc. and be using less of the 'std' namespace.
The nonsense needed for "variadic" templates in C++03 isn't "just do without lambdas". You basically have to walk on eggshells to get the equivalent of unique_ptr. Not having to type std::vector<SomeTypeName, WhateverBuffer>::const_iterator changes the way you write code, too.
The stronger guarantees on copy elision lets you skip return by reference nonsense more aggressively.
Sure there are a lot of small accumulating changes, but they can easily be caught up on by reading the documentation when you actually need those features.
On the other hand, I've been waiting for modules, concepts and networking literally since 2012 - and I only started using C++ in 2011, with around 2 years of experience in C. I don't think anyone is moving too fast in that direction.
Edit: I still remember the graphic from the committee/Herb, which showed 2014 for the networking TS, and 2017 for concepts/modules. The "networking TS" then ended up being like one .pdf file with functions for LE/BE conversion, and well obviously concepts and modules aren't in C++17. (Neither is any actual networking.) And while concepts look to be on a fairly good path for C++20, I'm going to be very surprised (and happy) if they'd manage to get modules in, too.
I actually think that the lack of a popular cross-platform package manager is much more harmful. It's amazing what GitHub and CocoaPods did to the niche Objective-C community in such a short time, while C++ still isn't a language where people celebrate cool open source libraries.
And you yourself mentioned Boost, which is kind a code ecosystem of its own, all open source. But I think C++ has problems with libraries because it’s such a pain to add a library to C++. If the library is C++, you can’t ship a binary and header file like with a C library because the ABI needs to match, so you have to compile the thing. And then people like Boost do template wizardry that consumes compile time to produce magic, but some developers value the compilation speed over magic, so they don’t use anything heavily templated. But if it isn’t templated, it likely could be written in C if it isn’t a big UI framework, and be available for everyone. So, no C++ library ecosystem.
I think it's a bit of a catch-22. C++ projects are so rare and monolithic that reinventing the wheel every now and then. But maybe more (smaller) projects would happen in C++ if there were polished libraries for reasonably common requirements like sending a SOAP request.
... and when there's essentially a single build system for Swift code. While for C++ there are several.
> C++ projects are so rare and monolithic that reinventing the wheel every now and then...
...does not hurt much.
Also, I see cool C++ open-source projects being released fairly frequently.
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.
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.
Well, about half of the Python ecosystem seems to disagree.
I really don't understand the animosity non-C++ developers have towards the language. You can still use Python, Rust, etc if you want. Nobody wants to force you to use C++.
Until then I work in it because my goal (and my job) is to deliver amazing products and experiences to my customers and if I had to do that in COBOL, I’d do that too. My job is not about the language for me, it’s about what I’m doing with it.
Pre-11 C++ was a bad language. The gains of leaving it to something like Java (that isn't even good by today's standards) were huge. The new standards are making it possible to create better code on the language, but it is still far from a modern language and the added features can not remove complexity, they can just add to it.
There are countless examples of the so-called modern C++ features reducing complexity in code.
For example, it is now considered a code smell to ever write "new" or "delete" in your code. Imagine that, never using these words to manually allocate and delete memory in C++! But it's true, unique_ptr in particular makes so much simpler and safer.
Type inference with auto doesn't just save typing, it improves performance in many cases and reduces a lot of complexity, while also avoiding uninitialized variables.
These are just a few of at least a dozen examples that come to mind about reducing code complexity with more modern C++ features.
auto p = unique_ptr<Foo>(new Foo());
Totally works, and may be easier to remember if you dont like the "magic" parameter forwarding.
e.g. foo(unique_ptr<X>(new X), unique_ptr<Y>(new Y)) is a leak waiting to happen.
https://stackoverflow.com/questions/37514509/advantages-of-u...
They're glaringly inconsistent because they behave differently with regards to ownership, and the fact that you can't copy them or pass them around in certain cases is because they're designed to stop you from doing this as it would undermine the reason you're using the class.
Like I said, if you look at all the logic, there's a good reason why everything is the way it is. The problem is I can't use the things without looking them up. Usability of my language is a big deal for me, which is why I hate unique_ptr.
no it's not, it never has been. The point of modern C++ is to get rid of owning pointers.
C++ programmers still need to know what "new" and "delete" do, so they can work with older code that uses them. They also need to learn what "auto" does, so they can work with newer code that uses it. (The behavior of "auto" isn't trivial; how many C++ programmers understand the difference between "auto v = <expr>;" and "decltype(<expr>) v = <expr>;"?)
...instead you'd use "decltype(auto) v = <expr>", which is equivalent. And people certainly use decltype(auto), or else it wouldn't have been added to the language, 3 years after regular auto.
Plus it usually makes the code cleaner by focusing on structure not types. As any construct, it can of course be abused.
Every big project is almost entirely different. They use different sets of features - some overlap more, some less. Many developers like to use C libraries, because they are easy to wrap in their version of C++. When you shop for libraries you often have to think if their version of C++ will work with yours. There is some consensus around STL and Boost, so at least that is relatively straightforward.
E.g. in the C->C++ transition most malloc's were left alone. If you wanted to add a ctor/dtor then you would go refactor them as necessary. It also encouraged you to encapsulate your work moreso than you would have otherwise.
But it is also true that forcing all the code in a project to use a single dialect is expensive. Developers need to decide what that dialect is --- not just once, but constantly as C++ evolves. ("Is it time to use Ranges yet? Concepts?" etc.) You need to do expensive refactors every time you update the dialect. You need to enforce the dialect at code review time (harder as it changes). Every time you import third-party code into the project you need to update its dialect.
A constantly evolving language that regularly deprecates commonly-used features in favour of "better" alternatives, like C++ does, is problematic. The faster pace of C++ evolution is making this problem worse.
Aside from exceptions (Can't use them safely if RAII is not universal) and shared pointers, most new language features are pretty localized in effect. E.g. using a lambda in a function originally written in C++98 does not make the existing code less safe. Only your sense of aesthetics would force you to update the rest of it.
You may not be able to if the lambda captures state and you need to convert it to a function pointer.
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.
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".
std::move doesn't move anything, it casts an object as a movable reference (equivalent to static_cast<T&&>). The compiler doesn't preclude you from accessing the old object (or say anything at all) and there's no guarantee it actually did get moved, it's just a hint. That's not real move semantics, it's a shoddy knock-off.
You also have to manage a new constructor, new reference type and the opt-in because the default remains not using move semantics. Worse yet, there's varying agreement on what you can or should do with the source of a moved value, the STL containers will all continue to let you use the old value, it's just empty now. That's not standard behavior because there is none, and it's de facto now because it's in the STL. What a nightmare. [1]
std::variant is supposed to be associated values on enums, but of course, it doesn't do that either. You don't match, you create a new struct with a bunch of operator() methods on it [or overload a lambda?!] and throw it at std::visit. You can only have one variant of each type. Then it throws exceptions if you start mucking about in ways you shouldn't. There's no context. It's dreadful. [2]
[1] http://yacoder.guru/blog/2015/03/14/cpp-curiosities-std-move...
In any kind of correct code, the difference between a move and a copy is only performance. If a copy were to happen where a move was requested then the code is just as correct, so I find it strange to get so hung up on it not being “real”.
Also, if move is the only available option, and move cant happen, you get a compiler error. If performance is correctness for a type that is expensive to copy, make copy not an option.
Also, there is a move constructor by default so it’s not opt-in, you opt out only if you start screwing around with copy / assignment / destructors which you usually shouldn’t need in modern code anyway.
Sure, the state of moving on the moved from object is unspecified, but really, I can’t think of a time when I’ve written code that would care. It’s kind of a non-problem.
If you really want to reuse an object after a move I question your motives, but you should just reinitilaise it by assigning a freshly constructed value and the result of that is of course standard.
That's just not true when you take smart pointers into account. unique_ptr is pretty obvious, since it can't be copied. But shared_ptr is more devious, as there is a clear semantic difference between giving someone a copy of your shared_ptr vs moving your copy to them. And, given that destructors are often used for more than simple resource cleanup (e.g. they are sometimes used for releasing locks), the difference between a move and a copy can have a huge impact on program behavior.
Whether this matters really depends on the code you're trying to write of course.
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.
Not really... Rust 1.0 is from mid-2015, well past 2011.