
Five Popular Myths about C++: Postscript - ingve
http://isocpp.org/blog/2014/12/five-popular-myths-about-c-bjarne-stroustrup
======
jamesaguilar
There are a lot of objections to C++, but I've never seen any of the five he
mentions. They sound more like strawmen to knock down than real objections by
actual users or commentators critical of the language.

~~~
vardump
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.

~~~
sjolsen
> 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.

~~~
vardump
I guess you don't maintain [legacy] C++ code. Occasionally I have to.

~~~
sjolsen
I have maintained C++ code that was poorly written, if that's what you're
getting at, but I have yet to find myself maintaining C++ code that has been
poorly written as a result of the design of the language.

~~~
vardump
That's unfortunately something you can say about any language.

------
kartikkumar
> "Unfortunately, there is not a single place to go to look for C++
> Libraries."

I don't understand this. I code in C++ everyday at the moment (that's a story
for another day) so I know the ecosystem, at least for scientific computing,
pretty well. With all the changes and improvements being introduced, what's
stopping a package manager from being added? The bane of my existence at the
moment is the fact that I have this HUGE Boost dependency in my code, even if
I'm only using a few packages. I know the Boost project has now finally
migrated to Github and provides individual repositories for libraries. It just
startles me that there isn't a single, consolidated package manager to have
rolled out of the millions of work-hours that have gone into C++ projects.

It's possibly the single biggest criticism of the language that I felt wasn't
tackled at all. There is a complete lack of consensus. In trying to
accommodate everything and anything, C++ has in my experience overshot the
mark.

~~~
frankzinger

      The bane of my existence at the moment is the fact that I 
      have this HUGE Boost dependency in my code, even if I'm      
      only using a few packages...  It just startles me that 
      there isn't a single, consolidated package manager...
    

Sincerely, I have never understood this common complaint about C++ (applies to
C as well, actually). My OS comes with a _huge_ repo of C++ libraries. For
example, there is a separate package for each of the Boost libraries you used
as your example. Why do I need a C++-specific package manager? What's the use
case? Windows?

~~~
JonathonW
Windows. OSX (to some degree; Homebrew and MacPorts mitigate this). Linux if
you want library versions newer than those supplied by the distro, if you want
something that's _not_ supplied by the distro, or if you want to be able to
handle your build in a distro-independent manner (those "separate packages for
each of the Boost libraries" you reference are provided by your distribution;
Boost themselves only distribute one monolithic package from which you can,
with some massaging, pull out individual parts if you really need to).

The language-specific package managers used with (for example) Python, Ruby,
or Node give developers an OS-agnostic way to pull in dependencies, and, since
dependencies are being packaged uniformly, avoids the conflicts between build
systems that can make it hard for C++ libraries to coexist (this thing needs
CMake, this other guy used Autoconf/Automake, and I've got Boost which built
with Bjam, and _now_ I need to make it all work on Windows and they're all
providing binaries built with different MSVC versions).

~~~
frankzinger
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.

------
jokoon
Sometimes I just wish there would be less ISO standardization process and more
new features added to the language. I guess it's not happening because
language extension are evil and because maintaining compiler is hard.

But still, I think it would be great to be able to have module right now as an
unofficial clang or GCC extension, even if it breaks later. I guess it has
more chance happening in the open source realm.

------
diarg
Manual memory in C++ is so cumbersome that is efectively imposible to develop
programs with no memory leak bugs in real life.

Anyway, the more important fact about C++ is that it is a language complicated
to no end, with an insanely bad design on purpose, so a couple of guys can
sell consulting services, write books, and the like.

The year 2015 is about to come, let's just stop filling the world with such
primitive and ugly ugly code. We have saner alternatives to C++ since ever.

~~~
dragontamer
shared_ptr<int> a = make_shared<int>(10);

What's so hard about managing that? shared_ptr is basically equivalent to
Python garbage collection.

Shared_ptr were standardized in 2003, and Microsoft implemented CComPtr<> way
back in the 90s for this easy to use reference-counted smart-pointer concept.

[http://msdn.microsoft.com/en-
us/library/aa266806%28v=vs.60%2...](http://msdn.microsoft.com/en-
us/library/aa266806%28v=vs.60%29.aspx)

So... yeah. Stop doing manual memory management in C++. Something better has
existed... since the 90s.

So how about you criticize something in C++ that wasn't solved at least 16
years ago?

~~~
StephanTLavavej
Correction: shared_ptr wasn't in C++98/03\. It was originally developed in
Boost, then added to TR1 (in 2005), and finally incorporated into C++11.

One of the major differences between shared_ptr and CComPtr is that shared_ptr
is non-intrusive - it can manage anything, even things like ints that don't
know anything about strong/weak refcounts.

~~~
dragontamer
My history was off, thanks for the clarification.

Nonetheless, the concepts revolving around CComPtr and all that good stuff can
be easily seen in C++98 / STL. STL Strings for instance automatically clean
themselves up under the principles of RAII.

Auto_ptr<>, the first smart pointer, also was standardized in C++98. While
crude and primitive by today's standards (especially compared to
unique_ptr<>'s explicit RValue semantics), auto_ptr<> shows me that even in
the mid 90s, people understood the principles of RAII.

At least, if you were a learned C++ programmer.

