Item — HN Reader

Of course, I didn't mean this specific document, just a guidelines document similar to this, but for older versions of the language. I'm sorry for comparing to Python again, but it's a much younger language and it has had an official document equivalent to this one since 2001. Remember, the Core Guidelines project was announced in 2015, after C++14 was already in production systems all over the world.

C++11 has existed for more than a decade, it has already been superseded by 3 newer versions of the language that add a lot of new features (some of them incompatible with each other), yet for most of its existence there was no official guideline from the creators that explains how it should (and shouldn't) be used. And as far as I know, nothing like it existed for C++98. It's too little, too late. They clearly have some priorities regarding documentation that, as a user, I strongly disagree with.

Big organizations (EA, Unreal, Google, etc) can live with this -- they can afford to have their own, very restrictive standards on how to use the language. Most small organizations (in my experience) don't, either through lack of expertise, money, time, or will (or a combination of all), and their code is usually ugly, hacky, unstable, and hard to work on. This document only solves this problem insofar it exists as a very strong recommendation to buy ReSharper and just do whatever it says.

1 comments

Yeah, there probably should have been more efforts to get something online early. But consider that the Bjarne, the original creator of the language, has published several books, that is where a lot of the guidance is from. Some of the books were out in the 90s and others wrote books too, I have one from Angelika Langer about IOStreams that is nearly 20 years old now, Scott Meyer a Microsoft compiler dev publishes stuff, Chandler Carruth a Google compiler dev publishes in depth talks. There is a lot of C++ material, just not much from a central source and not compiled into a single list. This makes it easier to go from a novice to an expert, and harder to become a novice in the first place

Before I got to your last paragraph, I was like "but big companies manage it fine" and you are right that it isn't readily approachable for non-expert small teams. There are things like Jason Turner's starter repos for C++ but he makes assumptions and even he went the book route, and is non-official.

I think a lot of this comes down to age and size. C++ is astronomically large. I don't want these to be excuses, you raise legitimate questions that need to be addressed, but I do think every language will deal with this when getting this large.

C++ just formed differently than a lot of languages. Most languages have 1 canonical source or at least had 1 source before the modern era of package managers and docs bundled with the language. C++ existed a good 25 years before package managers for languages became popular, so even getting libraries is hard. But it does mean that there are many package managing system for C++. Many sources of docs, and many implementations. You have freedom to pick your own at the cost of needing to know how to make such choice.

Compare to Ruby; Yukihiro Mastumoto (Matz) made a Ruby interpreter, CRuby the community sometimes calls it. Then someone remade it on the JVM, JRuby. Then they, some nebulous they that were invested in Ruby, made a standard for the core language. Then Twitter, Rubinius, some C# dudes, all made their own, but the CRuby implementation was the reference so deviations were bugs. The stand exists, but at 1500 pages (language and core library) or something like that the language is underspecified so everyone looks to Matz for answers, and maybe the Spec is updated with his blessing. At some point he blessed RubyGems as the de facto package manager and even though other exist they are generally ignored.

In C++ everyone follows the standard, even Bjarne Stroustrop the creator doesn't have his own compiler anymore. When there are deviations from the Standard everyone knows the standard is official and can read up enough from a variety of public sources. There is no single source of truth like Matz for Ruby, but there is no bottleneck on technical details either. The C++ standard is also much more detailed, coming in at two 3k page docs, 1 for the language and another for std lib even though both are much smaller than Ruby. Because there have been so many technical arguments there is much greater specificity and thought put into details. All of this openness comes with vagaries and difficulty getting into it.

C++ isn't a turnkey solution for a specific domain, it is a very general purpose tool for experts. Nothing is stopping someone from packaging as a turnkey solution and some the big companies you mentioned do exactly that for their internal development.