Slashdot Mirror
C++ 2011 and the Return of Native Code
snydeq writes with an editorial in InfoWorld about the resurgence of native code. From the article: "Modern programmers have increasingly turned away from native compilation in favor of managed-code environments such as Java and .Net, which shield them from some of the drudgery of memory management and input validation. Others are willing to sacrifice some performance for the syntactic comforts of dynamic languages such as Python, Ruby, and JavaScript. But C++11 arrives at an interesting time. There's a growing sentiment that the pendulum may have swung too far away from native code, and it might be time for it to swing back in the other direction. Thus, C++ may have found itself some unlikely allies."
Native was never away. It always has its place. It is just that performance/efficiency is not always top priority.
This keeps getting brought up, but I've written commercial C++ code for years and I've not had memory management issues. There have been problems with legacy 3rd party libraries, but if you religiously apply the RAII ( https://secure.wikimedia.org/wikipedia/en/wiki/RAII ) idiom you will usually be fine. I can't remember the last time I worked with a raw pointer and had to new/delete my own memory.
The larger picture is fucking use the right tool for the job already.
Java has its purposes. Write-once, Run-Almost-Anywhere is a good concept. Likewise, some of the other tools in other managed frameworks make certain things really simple.
And when you need power and speed at the expense of having to do things a lot more exact yourself, then go to a language that'll work that way.
The problem is not that one or the other is "bad." The problem is that too many programmers are golden-hammer morons who think their favorite tool is the only correct way to do everything on the goddamn planet, which is why you get Java applications running a chip on little mini kids games to do something that could have been done with a 5-cent microchip.
Yes, because managed code has no memory leaks. Please. I work on a mixed C++/Java Android codebase. I haven't found a memory leak on the C++ side in months. The Android framework decides to hold onto random references every new version.
Quite frankly, memory management is not hard. If you don't understand the simple idea of allocate, use, release, then you are a complete incompetent and should not be programming professionally. I'll go so far as to say it's better for a language NOT to automatically manage your memory- in general the first sign of a bad or failing architecture is that object life cycles and memory allocation start to be non-trivial. Managing your own memory catches those architecture bugs and leads to cleaner, easier to understand code. And the cost is absolutely minimal, I doubt I've spent 10 minutes in the past 2 or 3 years actually debugging memory problems in C++.
I still have more fans than freaks. WTF is wrong with you people?
...choose the tool that's best for the job, don't choose the job that's best for the tools you know already.
Game developers, for instance, are among the guys who write the most performance sensitive code out there, and they use a mix of C, C++, C#, Lua/Python for the various parts of the game. Usually the inner, tight loop is written in C/C++, higher level modules are written in C# and designer/modder scripts are written in a very high level language such as Lua. There is no best language in general, and whoever says otherwise is often an idiot.
My book: Friendly F#, fun with game development and XNA; my game: Galaxy Wars by VSTeam; my gamedev language: Casanova.
Managed C++ combines the streamlined elegance of native C++ with the high performance, execution stack transparency and platform/vendor flexibility of .NET.
I think there was a hope that computing power would catch up and make VMs a competitive alternative to native code.
While you're right there's a computing power issue here, the issue is battery life not lack of CPU cycles. VMs add overhead, as you add overhead you'll run longer and burn more power on the CPU. If you want to squeeze all you can out of a limited battery you need to optimize your code and in the end that's going to mean native code with very explicit memory management. VMs just don't play well in embedded environments.
Managed code has been the single biggest disaster at least where I work, stalls, huge memory consumption, unpredictable.. the dreaded 'garbage collection', I am glad we are out of it.. and if you fear crashes then you could use C++ exceptions, then you can divide by zero or do other bad stuff and never experience a hard crash... or even better, use the complete threaded sandbox (see Chromium sandbox). that means C++ is totally safe and the fastest at the same time - best of both worlds; that is why C++ is used internally by Google, Ebay, Oracle.. etc.
I can speak for vb.net ( may be true in c#.net, not sure ), but you can leak memory as well as other resources.
I bought into the "garbage collection handles it" mindset, until it was rudely pushed into my face that some UI elements have to have dispose called, or they stay in memory ( IIRC, forms will not collect, so incompetent programmers that put properties on their forms can come later and get those properties from the form after it is closed, other things like that ).
emt 377 emt 4
Now the program when written the correct way as:
void testMemory() {
std::string s();
s.append("sample");
}
void testLoop() {
for (int x = 0; x 100000; x++) {
testMemory();
}
}
int main(int argc, char *argv[])
{
testLoop();
getchar();
}
Will not leak memory. Imagine that. If I don't write the program in a stupid way it won't actually behave stupidly! AMAZING!
People tend to lump lots of things as if they were all the same thing, but they're really completely independent:
Does the language run in a virtual machine, or is compiled down to native assembly in advance?
Is memory management done explicitly, or is there a garbage collector?
Does it allow direct access to memory (necessary for some parts of system programming)?
Does it check for common errors, such as going past the ends of arrays?
There are garbage collectors for C++. C# runs in a virtual machine, but still permits direct access to memory. STL collections in C++ check for out of bounds indices. So here is how I would categorize different languages, roughly ordered from "most native" to "most managed":
C++: Incredibly complex, lots of bug opportunities, very verbose, very fast, suitable for system programming
D: Some complex, some bug opportunities, some verbose, very fast, suitable for system programming
Objective C: Some complex, some bug opportunities, some verbose, fast, suitable for system programming
C#: Some complex, some bug opportunities, some verbose, fast, suitable for system programming
Java: Some complex, some bug opportunities, some verbose, fast, not suitable for system programming
Scala: Very complex, few bug opportunities, not at all verbose, fast, not suitable for system programming
Python: Fairly simple, some bug opportunities, not at all verbose, slow, not suitable for system programming
"I'm too busy to research this and form an educated opinion, but I do have time to tell everyone my uninformed opinion."