Five Popular Myths about C++: Postscript

Because a package manager for C++ is infinitely more complex than one for a bytecode language like Java or .NET, where theres either a well defined spec (.NET) or a reference implementation (Java, Python) that everyone measures compatibility for?

The first obvious problem is that there is no ABI for the C++ standard library. This makes sharing any kind of binaries plain impossible because exchange of C++ standard library objects between your project and a binary from the package manager will very likely just blow up. So the package manager, right from the bat, has to build every library and every (recursive) dependency of that library on demand on your computer using your C++ development environment. That alone is a herculean task if you consider the number of compilers (GCC (MinGW), Clang, VC, ICC), their respective versions and possible C++ standard library implementations used. And remember: you can't mix and match!

There is a reason even a C++ library such as ZMQ exposes only a C interface, and it's because things become extremely messy very quickly when you are juggling around native code.

Do you really believe that a C++-specific package manager (PM) repo would somehow be much more up to date than an OS one? Why?

Any PM repo will eventually be missing something you need, and then you will have to compile it yourself, and if you've done that a few times you should have an idea of the difficulty involved in providing a set of compiled dependencies for one system, nevermind multiple versions of multiple systems.

I don't doubt the usefulness of the Python, Ruby, and Node PMs, but those libraries mostly depend only on the interpreter and other interpreted code. It's just so much simpler. The fact that it's all going through an interpreter (compiled specifically for that system by the system PM in most cases!) solves so many of the problems.

This is exactly why 'stable' or 'long-term-support' versions of OSes exist. They go out of their way not to break binary compatibility (by not upgrading libraries all the time) so that user code need not be recompiled.

Objections from the article.

1. “To understand C++, you must first learn C”

2. “C++ is an Object-Oriented Language”

3. “For reliable software, you need Garbage Collection”

4. “For efficiency, you must write low-level code”

5. “C++ is for large, complicated, programs only”

1. Not a myth. To write your own C++ code, no. To do anything with C++ other people wrote... Yes, you must first learn C.

2. Weird one, I don't remember hearing this one ever. But it'd be a myth on many levels. C++ has some object-oriented features, but it's indeed not an object-oriented language in the original sense of the concept from Smalltalk. But if you see the effort, it can be used as one. It can also be used as a procedural language. Or even as a functional one to some extent.

3. Real myth detected! GC doesn't affect reliability. Manual memory management reduces reliability. In C++, you can do manual or RIAA-type memory management.

4. This one is not a myth. To get best possible efficiency, you do need to use assembler or compiler intrinsics. The difference you can gain is up to 40x (in my personal experience, this case was about vectorization and branch elimination), typically 2-3x, so it's not insignificant either.

5. Myth. You can use C++ for any size complicated program. You can write simple C++ programs, but the language tries very hard to make sure you can't understand a piece of code out of context. You can't even know what your arithmetic operators do without knowing the includes and other context.

> the language tries very hard to make sure you can't understand a piece of code out of context

The language goes out of its way to make it possible to write code that is understandable with as little context as possible; type deduction, lambdas, range-based for loops— all of these are tools for reducing the amount of context or number of contexts necessary to understand a portion of code.

The language also allows you to write code that requires an inordinate amount of context to understand, yes. So does C. Hell, so does every other programming language worth using. It's practically impossible to prevent such code from being written without totally crippling the language.

> You can't even know what your arithmetic operators do without knowing the includes and other context.

If you can see that the arguments to your arithmetic operators are numeric (and you should be able to tell without looking outside of function scope), you need no more context. If the arguments are of user-defined types, you need no more context than if a function named "plus" had been used instead of the function named "operator+." If that is not enough context to understand the code, you have a problem with someone choosing poor names for functions, which goes far beyond operator overloading. For example, sure, operator overloading allows for code like

    auto operator+ (string_t a, string_t b) {
        return a.length () - b.length ();
    }

but so what? User-defined functions allow for code like

    void uppercaseify (char* str) {
        unlink (str);
    }

but it would be patently absurd to blame the language for code like that.