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.
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.
Some say that Jake 2 ( http://en.wikipedia.org/wiki/Jake2 ) actually ran faster than Quake 2. Of course there are a number of points to consider here, like the oldness of the Quake 2 code (thus a lack of optimization for modern computers).
C++ and Delphi are almost the last of few ones left to generate proper Windows exe files. DotNET is great for business applications but when you think about creating mass products, you have to keep returning to C++ and friends.
That's just utter BS, nearly all major programming languages are capable of generating "proper" non-dotnet win32 binaries. Everyday I build our Win32 app from Mingw using plain C.
I have experience programming in large teams in both C++ (~10 years) and C# (~3 years), and my feeling is that the overall development is really quicker in C#. It's a large windows-only standalone app where speed is very important.
But if my team have to build such app with cross-platform requirement, I still think C++ would be the choice. [with the similar arguments the author uses at the end of his rant]
Or if you need to use any other libraries.
C# is great assuming everything you need is in .Net. As soon as you need a decent maths library or a screengraph or some image processing it involves a lot more work.
Obviously the author has not heard of boost::python -- it provides an extremely easy way to interface Python and C++, including classes in one language that inherit from classes in the other.
Often done--a list of what is important in language choice, followed by the choice we wanted to make anyway: "Nethertheless, we choosed C++ as our language." C++ is slow, but in time to learn or write, but not necessarily in execution.
There might be a case to be made to eliminate C++, but it's best made by somebody who knows more than this guy.
This is really a terrible submission.