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.
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.
I've encountered each of these myths "in the wild," and I dare say you'll see them thrown up repeatedly here on HN in various contexts.
The third item on that list especially is something you can almost certainly see every day in a random HN thread about programming languages (along with counterpoints).
In fact, 'safety', of which GC is a subset, is a huge objection, and one of the first, most frequently raised in my experience. People are afraid of pointers, some rightly (e.g. because they've personally experienced bad memory management code, or they've never worked outside of a dynamic language, etc.), but most not.
> "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.
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.
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?
A package manager is generally not part of the language per se and should not be part of the language, but rather be part of the tooling ecosystem around it. Don't get me wrong. A de facto package manager is extremely important for any major language - and it's high time someone in the C++ community builds and promotes one. It just doesn't belong in the spec.
I think that and the previous issue go hand in hand, contributing to each other:
> Unfortunately, C++ Libraries are often not designed for interoperability with other libraries
And I think it's not just that the libraries don't work well with each other, but they also only work with a subset of C++ projects since any given group of collaborating C++ programmers seems to settle on their own subset of the language to allow in their coding standards. Perhaps I am falling into the trap of thinking about old C++ now -- modern C++ does seem to have more of a broadly understood idiomatic style.
> what's stopping a package manager from being added? ...
> 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.
As far as the standard committee: "creating tools" is outside the scope of "defining a language and its standard library." As far as the "millions of work-hours that have gone into C++ projects," it's probably a combination of nobody's come up with a package manager that satisfies enough programmers and nobody's been willing to spend the extra time to create such a tool. It's hard enough to ship code on time.
> There is a complete lack of consensus. In trying to
> accommodate everything and anything, C++ has in my
> experience overshot the mark.
It's certainly true that projects that try to take full advantage of C++'s flexibility end up collapsing. Projects generally shouldn't allow "everything and anything" in the code base. And many of the design principles that the committee follows should probably not be applied to software projects in general.
But the language has to satisfy more than your project, or more than the average project that programmers believe exists but can't agree on what it is. I've been writing C++ code professionally for years, and while I know how to, I haven't shipped any GUI code. I did write a gtkmm-based stopwatch to help my son with an elementary school science project (because I thought it was more fun to do that than to buy a stopwatch at the local sporting goods store). But professionally I've only written code for back end web services. I know I'm not the average C++ programmer people imagine, but I'm not sure if the average C++ programmer is writing desktop GUI software, or iPhone software, or libraries that will be called from Java, C# or some other language via SWIG. I know they aren't the average C++ programmers, but I do know some people write C++ to run on supercomputers (I used to work with one of them).
Regarding a package manager specifically: I personally have been happy to use RPM on my personal Linux system to manage packages. I wouldn't expect people to use RPM on a BSD or Apple system. I'm not sure that we need a special package manager just for C++ libraries. I miss anything like RPM when developing on Windows (edit: another comment mentions NuGet: I'll try it, thanks!). If you write something for Windows, I'll buy a copy.
My web services interact with efficient number crunching libraries written in C++. In my case, I don't need things to be as efficient as possible, but others do. I know Dan Bernstein believes the way to get super-efficient libraries is to use different implementations to take advantage of CPU-specific features ( http://www.tedunangst.com/flak/post/some-gripes-about-nacl ), but this makes package management much harder (at least without function multiversioning -- https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Function-Multiv... -- which isn't required by the standard). Should the committee tell Bernstein he's wrong? Or encourage compiler writers to ship with tools that Bernstein and others have no use for? How should the package manager handle a case where a library could work on my platform, but nobody's compiled it for me yet? What about platforms where the ABI isn't completely nailed down yet?
You have identified a real shortcoming in C++ development. There isn't an easy answer. But, seriously, if you write one I'll be sure to send you some money.
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.
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.
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.
[+] [-] jamesaguilar|11 years ago|reply
[+] [-] vardump|11 years ago|reply
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.
[+] [-] Iftheshoefits|11 years ago|reply
The third item on that list especially is something you can almost certainly see every day in a random HN thread about programming languages (along with counterpoints).
In fact, 'safety', of which GC is a subset, is a huge objection, and one of the first, most frequently raised in my experience. People are afraid of pointers, some rightly (e.g. because they've personally experienced bad memory management code, or they've never worked outside of a dynamic language, etc.), but most not.
[+] [-] detrino|11 years ago|reply
[+] [-] wues|11 years ago|reply
[+] [-] kartikkumar|11 years ago|reply
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.
[+] [-] revelation|11 years ago|reply
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.
[+] [-] frankzinger|11 years ago|reply
[+] [-] enry_straker|11 years ago|reply
[+] [-] furyofantares|11 years ago|reply
> Unfortunately, C++ Libraries are often not designed for interoperability with other libraries
And I think it's not just that the libraries don't work well with each other, but they also only work with a subset of C++ projects since any given group of collaborating C++ programmers seems to settle on their own subset of the language to allow in their coding standards. Perhaps I am falling into the trap of thinking about old C++ now -- modern C++ does seem to have more of a broadly understood idiomatic style.
[+] [-] maxlybbert|11 years ago|reply
> 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.
As far as the standard committee: "creating tools" is outside the scope of "defining a language and its standard library." As far as the "millions of work-hours that have gone into C++ projects," it's probably a combination of nobody's come up with a package manager that satisfies enough programmers and nobody's been willing to spend the extra time to create such a tool. It's hard enough to ship code on time.
> There is a complete lack of consensus. In trying to
> accommodate everything and anything, C++ has in my
> experience overshot the mark.
It's certainly true that projects that try to take full advantage of C++'s flexibility end up collapsing. Projects generally shouldn't allow "everything and anything" in the code base. And many of the design principles that the committee follows should probably not be applied to software projects in general.
But the language has to satisfy more than your project, or more than the average project that programmers believe exists but can't agree on what it is. I've been writing C++ code professionally for years, and while I know how to, I haven't shipped any GUI code. I did write a gtkmm-based stopwatch to help my son with an elementary school science project (because I thought it was more fun to do that than to buy a stopwatch at the local sporting goods store). But professionally I've only written code for back end web services. I know I'm not the average C++ programmer people imagine, but I'm not sure if the average C++ programmer is writing desktop GUI software, or iPhone software, or libraries that will be called from Java, C# or some other language via SWIG. I know they aren't the average C++ programmers, but I do know some people write C++ to run on supercomputers (I used to work with one of them).
Regarding a package manager specifically: I personally have been happy to use RPM on my personal Linux system to manage packages. I wouldn't expect people to use RPM on a BSD or Apple system. I'm not sure that we need a special package manager just for C++ libraries. I miss anything like RPM when developing on Windows (edit: another comment mentions NuGet: I'll try it, thanks!). If you write something for Windows, I'll buy a copy.
My web services interact with efficient number crunching libraries written in C++. In my case, I don't need things to be as efficient as possible, but others do. I know Dan Bernstein believes the way to get super-efficient libraries is to use different implementations to take advantage of CPU-specific features ( http://www.tedunangst.com/flak/post/some-gripes-about-nacl ), but this makes package management much harder (at least without function multiversioning -- https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Function-Multiv... -- which isn't required by the standard). Should the committee tell Bernstein he's wrong? Or encourage compiler writers to ship with tools that Bernstein and others have no use for? How should the package manager handle a case where a library could work on my platform, but nobody's compiled it for me yet? What about platforms where the ABI isn't completely nailed down yet?
You have identified a real shortcoming in C++ development. There isn't an easy answer. But, seriously, if you write one I'll be sure to send you some money.
[+] [-] jokoon|11 years ago|reply
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|11 years ago|reply
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|11 years ago|reply
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...
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?