Hacker News Reader

Comment by gurkendoktor | Hacker News Reader

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.

View on HN

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.

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.

> Swift had the same ABI issues as C++, but when most packages ship as source code, it's not that big of an problem

... and when there's essentially a single build system for Swift code. While for C++ there are several.

Having a single master, instead of having to please every compiler vendor, helps.

Over-edited my comment, should have been:

> C++ projects are so rare and monolithic that reinventing the wheel every now and then...

...does not hurt much.

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.

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.

Reply on news.ycombinator.com