Comment by Rexxar
7 years ago
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.
7 years ago
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.
I kind of see it differently, that the 98 and 03 standards had a lot of mileage and as necessary as the more recent changes may have been, people felt the old standard pretty usable for a long time.
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.
I think it's worth noting that up until 2010 C++11 was known as C++0x. Everyone knew it was coming. You could get a good idea of what it was going to contain by looking at things like Boost. C++03 wasn't some abnormally stable version, it just took a longer than expected time to write the standard for C++11.
Yes I remember. Also, by the time c++0x seemed "right around the corner" for several years, a lot of the library features like smart pointers were already common practice, the standard just, well, standardized them.
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.
1 reply →
> Sometimes I read about the rapidly evolving modern C++ and I wonder if they are moving too fast
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.
This was also the timeframe in which boost::shared_ptr, boost::filesystem, boost::variant, and boost::thread have matured to the point where they could be imported into the standard, and when people discovered all these dark corners like SFINAE. The C++ language was frozen, but the C++ ecosystem never really stopped moving.
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.
Maybe this is my old skool C++ bias, but every time I’ve inherited a project using CocoaPods I’ve found the code to be of poor quality and the Pods to be either corporate libraries (third-party analytics, crash logs, etc.) or wrapper code of questionable quality that hasn’t really provided any benefits over a couple of hours of writing some simpler code yourself.
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.
Boost is awful even if you don't instantiate any templates. Just adding #include <boost/filesystem.hpp> will add 1 second to compile that compilation unit and we haven't even done anything with it.
Swift had the same ABI issues as C++, but when most packages ship as source code, it's not that big of an problem. This is precisely the thing that a standardized package manager can establish.
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.
3 replies →
I would say that the primary driver for growing the niche Objective-C community was iOS, not CocoaPods. And Objective-C is dying again with the introduction of Swift.
Also, I see cool C++ open-source projects being released fairly frequently.
My graduation project was to port a the particle visualisation framework of my supervisor from Objective-C/Renderman into Visual C++/Window/OpenGL, because he saw no future in it, little did he know what would happen 10 years later.
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.
49 replies →
Those are all C++11 features, right? So they aren't much of an argument in favor of 14, 17, 20.
3 replies →
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.
> The 1998-2011 gap has made a lot of damage to c++ in term of "market share".
Not really... Rust 1.0 is from mid-2015, well past 2011.
Not saying Rust is bad by any means, but it has about 20 times smaller market share than C++ according https://www.tiobe.com/tiobe-index/ and 11 times smaller according to http://pypl.github.io/PYPL.html.
Tiobe and PYPL are not market share indices, they're googling indices. I'd be very surprised if Rust really has 1/20 of C++'s market share as in number of companies and programmers that use it.
2 replies →