No respect due here. This guy truly doesn't know what he's talking about. "C++ is slow". LOL.

http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...

http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...

Reading the article, it sounded like he was comparing the speed of some unspecified ORM library in each language. If so, I suspect he may have been comparing a naive hand-rolled implementation in C++ to something like Hibernate/NHibernate which has many years of development and optimisation behind it.

The lessons to draw from this, if any, are that C++ code isn't automatically faster than Java or C# code: you have to make it so; and that Java/C# have some useful high-quality libraries which save you the need to roll your own solution.

Actually, object creation on the heap can be quite slower in C++ than in Java, at least if you are not using a custom allocator. The standard allocator in C++(using malloc) is SLOW.

The original article was terrible, so normally I wouldn't comment but I'll attempt to improve the discussion..

Do applications in C++ get modeled the same way as they would in Java or C#? Allocation speed doesn't quite seem like an apples to apples comparison.

If by being modeled you are asking whether objects are used in C++ as in Java/C#, then I would say yes, maybe even more so. Of course in C++ there is a possibility to use it as a "C with some more stuff" language, and unfortunately it is used as such regularly. But well designed C++ code involves object usage quite similar to Java/C#. Also in C++, RAII is used for managing transient resources, and this probably introduce extra objects which in Java would not be created.

For example: Creating a temporary file and after some work deleting it would be done using try & finally sections in idiomatic Java, but in C++ an object would be used where the constructor contains the file creation and the destructor contains the deletion. This way the file lifetime is tied strictly to the object lifetime, which would be destroyed automatically when the code block is left.

However, the fact that object allocation on the heap is slow is mitigated by having the ability to create objects on the stack, which is probably even faster than Java or C#. And they are also managed automatically, so stack objects are always preferred if they are suitable.

While I think it is an apple-to-apple comparison, it is a microbenchmark, and as such probably irrelevant in most of the real-world cases.

C++ actually used to be pretty slow back in the day, but that's more the fault of compilers that didn't optimize properly. That was about 15 years ago. (In other words, this guy missed the "C++ is slow!" bandwagon by a decade and a half.)

In what way? As far as I can tell point 1 is true memory allocation in C# is faster than in C++. Point 2 not so much unless you are starting out fresh and have no libraries beyond the standard library, and really how often is memory allocation really such a bottle neck that you write your own allocator? Point 3 true of pretty much every language that isn't C. Sure there are bridges to specific languages like boost.python but nothing general. Point 4 is pretty much true C++ doesn't have a strong module system. So outside of not knowing the technical term for ABI, what is really so poor about the article? I would have thought most of what he brought up was obvious and not worth the submission.

There's no way that real memory allocation is faster in C# than in C++. I don't know much about the CLR, but if it appears to allocate memory faster, it is probably because it is taking the memory from a pool which it has already allocated from the OS. You can do that in C++ if you want, using e.g. boost::pool.

As with most compacting collecting languages memory allocation is a space check and a pointer increment. In C++ new has to do quite a bit more. It is about Java but C# is capable of the same. http://www.ibm.com/developerworks/java/library/j-jtp09275.ht...

Also note that C++'s memory model is "single threaded" new must grab a global lock where as C#'s memory allocator is designed with threads in mind so no locking overhead.