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."

Carmack

[bonch]

Carmack remarked about this on his Twitter account today: "iOS did a lot to 'save' native code on mobile platforms. Prior, there was a sense that only Neanderthals didn’t want a VM."

Apple is even backing down on Cocoa garbage collection with their new Automatic Reference Counting feature, in which the compiler determines object lifetimes and inserts the needed memory management calls. ARC will be the default for new Xcode projects. I think there was a hope that computing power would catch up and make VMs a competitive alternative to native code.

Re:Yikes

[CadentOrange]

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 [wikimedia.org] ) 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.

Re:Then learn the language better, stupid

[Duhavid]

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 ).

Re:False dichotomy

[Palshife]

Yes. CIL is JIT compiled by the CLR. Just like the JVM does with Java bytecode.

The CLR is a VM. You can't ask the machine to load CIL. It has to be interpreted by the CLR first.

Re:Yikes

[Desler]

This just in: If I create a program specifically to leak memory it will... LEAK MEMORY!!! Seriously, who is actually writing code like that? And why the fuck would you be creating the string with "new" anyway? Your code makes absolutely no fucking sense and appears to have been written intentionally to be crappy.

Re:Yikes

[Desler]

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!

Re:Yikes

[Xtifr]

One could argue that the less deletes you have, more are the chances you have that there is a memory leak...

<grammar_nazi> fewer </grammar_nazi>

One could argue that, it's true, but it would most likely be evidence that the person arguing was utterly ignorant of anything that's happened in C++ since the early nineties. Between the container classes of the STL and Boost, and the RAII model, having very few deletes is generally a very good sign, since it shows you're not resorting to too much error prone manual memory management. If the few deletes you have are all in destructors, that only makes it more clear. (And even there, using autoptr or sharedptr is generally vastly superior to trying to figure out when you can issue a manual delete.)

In modern C++, you can manage vast amounts of memory properly without ever once using delete. In fact, you're more likely to be managing your memory properly if you don't.

Re:Why is C++ unmanaged?

[Desler]

You should look at the coding guidelines Google uses for C++.

I don't recommend that. Anyone reading the Google coding guidelines will get a very wrong picture of how C++ is supposed to be done. Hell, their guidelines specifically disallow the use of RAII which is one of the dumbest things ever.