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.
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.
So if you wanted to be shielded from the drudgery of memory management in C++ why weren't you using the features of the language that provide you automatic memory management to make this less of a pain? It's not as if you don't still have to do memory management in say .NET especially since the IDisposable pattern is needed all over the place in user-written code to clean up non-memory resources like file handles, GDI handles, etc held within your objects.
Last I checked you could use .NET in C++. So use .NET for the gui and networking frameworks and use C++ to do hardcore number crunching. Also there are native data structures in .NET and Java you can use in your program if you need performance. Most amature programmers never look in the math or collections libraries.
http://saveie6.com/
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.
Look at Objective C or Vala -- just as easy as C# or Java, but none of the headaches of a virtual machine runtime.
There's no -1 for "I don't get it."
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.
The corollary of this is that you *need* super hardware to run the latest applications because they are so inefficient.
Instead of dumbing-down programming (which is a false economy anyway as poor devs write poor apps regardless of the ease-of-use of their programming environment), we should be increasing the skills of the developers. That means stopping from making things so easy that my manager can do it, still making a hash of it, only now thinking that any outsourced cheap developer can do my job!
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.
Yes, because managed code has no memory leaks.
Yes, and managed code never has need for manual memory management. Oh wait...
The article perpetuates the myth that native code has to be "unsafe". That's an artifact of C and C++. It's not true of Pascal, Ada, Modula, Delphi, Eiffel, Erlang, or Go.
Nor does subscript and pointer checking have to be expensive. Usually, it can be hoisted out of loops and checked once. Or, for many FOR loops, zero times, if the upper bound is derived from the array size.
One of the sad facts of programming is that there should have been a replacement for C/C++ by now. But nothing ever overcame the legacy code base of the UNIX/Linux world. Every day, millions of programs crash and millions of compromised machines have security breaches because of this.
Gimme an algorithm or any other job and I'll implement it in 'C' - I don't need no pussy language that makes parsing text easier (Perl) or web back ends easier (Python) or worry about the mythical write once run everywhere languages like Java.
And back in the day of the old PS2, every goddamn game development house started out their dev cycle by reimplementing mip-maps because it wasn't supported directly by the hardware. Fucking insanity. If there's a tool that has been developed for text parsing, and 99% of your program's functionality is text parsing, then use something that was DESIGNED FOR TEXT PARSING instead of having to reinvent the goddamn wheel.
Tools are made because they make life, or at least a specific task, easier. They should be used for that purpose. They should not be used for things they are not designed for. C++ was designed for low-level access to the hardware, which is fine if your program needs low-level access to the hardware, but it shouldn't be used for every task just as Java, or Perl, or Python, or any other tool shouldn't be used for things they weren't designed for.
Java has its purposes. Write-once, Run-Almost-Anywhere is a good concept.
It is a good concept. Unfortunately, several studies (at least one was covered here on slashdot) indicate the vast majority of Java development runs on the same platform on which it was written. Furthermore, the vast majority of this Java software can not run anywhere without additional code changes because of programmer short sightedness or just simple mistakes.
So while its a nice "have", pragmatically speaking, it doesn't apply to most Java software.
Which means, at the end of the day, your development cycle of something like Java vs C++ isn't all too entirely different for code which actually is, "Write-one, Run-Almost-Anywhere."
Yep, I don't recall having memory management issues with C++ in the last ten years or so. Smart pointers take care of freeing RAM and the std::vector I use has bounds checking and extensive iterator checking turned on by default (even on operator[]).
Done properly C++ is as safe as Java, i.e. the only memory error is null pointer.
Java, OTOH has no stack unwinding for timely release of resources. Garbage collection is useless for anything other than RAM. Want a file or a network connection closed? You have to wrap it in a try...finally block and close it manually. Every single time, no way to automate it.
Then there's Java's brain-dead inheritance model. Get ready to do multiple inheritance manually by copying/pasting code from all the base classes. Cross your fingers that the interface never changes and you have to go and hunt down every last copy of it.
Want some "drudge"? Use Java.
No sig today...
Meanwhile, other people will actually ship on time and within their budget by not being a moron who thinks the only thing important in development is computational efficiency.
If I can just reach out with my words and touch a butthole, just one, it will all be worth it.
I disagree about C being easier to get into. The stuff you do in toy programs, playing with strings and arrays and such, is difficult and alien in C if you've never seen pointers, or manual memory management. In C++ you can start with string and vector, and get toy programs working with just STL stuff, worry about pointers and memory leaks later on.
Socialism: a lie told by totalitarians and believed by fools.
I doubt I've spent 10 minutes in the past 2 or 3 years actually debugging memory problems in C++.
For a laugh I just searched for the word 'delete' in my current C++ project. There was a grand total of nine of them in 250,000 lines of code (and they were to define some new container classes).
There's no manual memory management anywhere in the rest of the code. Memory management in C++ is a myth perpetuated by C hackers who can't be bothered to educate themselves.
No sig today...
Yes, and then forget all about OOP, and learn Java.
You're both right.
I tried to teach Java to my son. It quickly got stuck because of OO concepts. We went to Python. Life was good. And as you rightly point out, the OO taught by Java is crappy at best. If you really want OOP, Java isn't a good choice for that either.
Nintendo dropped the ball big time when they used a string comparison function for evaluating the digital signature hash. String functions terminate early (with success!) for strings where the first byte is null. All an attacker had to do to fakesign a Wii application is brute force change some random unused byte until it caused the first byte of the hash to be 00.
:(){
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.
I'd see C extended with supple string handling and regexes, for example. On top of a class model, obviously.
You mean like C++ with Boost?
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!
You're simplifying things. Most importantly Java has actually all the tools necessary to communicate with the operating system while C/C++ have almost none of them (for instance networking, graphics are missing). Plain C/C++ is not usable as a cross development platform _unless_ you restrict yourself to only use portable (3rd party) libraries. On the other hand, 99% of the Java libraries out there are already completely portable, so every Java program in Java can be made portable with a minimum of changes even if it wasn't designed for that initially, or in simple cases will just work out of the box.
So I wouldn't say it is as easy in C/C++ as in Java. This has obviously more to do with the standard libraries than the language itself.
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."
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.
Electronic engineering students. While C++ is taking over the world, I know of at least one course where understanding microprocessor design (let alone assembly language) is a requirement. Unless the course has changes in the short 2 years since I took it...
I have determined that my sig is indeterminate.
It's not only about being easier, but also proven. I would rather use a lockless thread-safe multi-reader/writer queue than implement it myself only to have a possible race-condition. It would be fun to learn it some day when I have free time, but enterprise code? No Way. I'll let engineers with PHDs and tons of testing figure out the hard stuff.
C++.
Yes, you get a little bruised when it comes to pointers, but that is very much worth it in the long run.
Students that don't learn about pointers and such early on (e.g. got Java first) tend to have a harder time in the upper classes where lower level languages are required. So, you can either "man up" and get the hard stuff learned early when it won't interfere with the classwork, or have your upper level classes being diverted in order to teach the stuff they should have learned earlier on and then not get to learn as much of the upper level material as they should have.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
or reference counted smart pointers
Why is it so hard to understand that Java, a language DESIGNED for portabilty, is more suitable for cross platform development than C++? You can throw any number of well designed cross platform C++ libraries at C++, it is still NOT part of the language, not part of the standard development platform and therefore it is harder to do cross platform C++ development than in Java. I can not comprehend why you think otherwise. Yes, the disparity in cross platform developement ease between the two may slowly fade in time, especially in the light of the new C++ release which makes a lot of features that you need from an API standard (threads for instance), but to say they are on par is simply an outrageous claim and definitely not a "simple fact".
Allow me to demonstrate some practical problems with C/C++ cross development between Windows & Unix) .dll/.lib)
- Non standard build system (make / vc++), different systems used for different libraries.
- Different linking process (.so vs
- Wildly differing implementations of the standard C library (stdio in VC++ is severely broken).
- No network API, so we will have to deal with either manual compatibily shims (more work) or 3rd party library (more work)
- No GUI API, same as above
The uniformity in Java is what makes cross platform development such an easy task: .JAR, build tools the same for all platforms (granted, you still need a Make equivalent, say ant, but the result of the build process is portable)
- Everything is
- Linking is just throwing a bunch of JARs together
- There is only one implementation of the standard library that everyone uses.
- Network API is standard
- GUI API is standard.
Now please enlighten me how exactly C++ crossplatform development is just as easy as in Java.
Why not just make a new user account that has access only to those resources that a given program may access, and then run the program as that user? That's what iOS for iPhone and IOS for Wii do, I've read.
I use Python for most things, c/c++ when I feel the need for speed/power.
And today PyPy released version 1.6 of their python interpreter :) More python speed!
It's The Golden Rule: "He who has the gold makes the rules."
Yes, because managed code has no memory leaks.
Of course this is true.
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.
Then the android platform is a piece a crap. Or your developers suck. Neither of which is very relevant when discussing whether managed code is or isn't a good thing, as there are plenty of good platforms.
Quite frankly, memory management is not hard.
Not much in programming is hard. But anything you have to think about is bug prone. Including manual memory management.
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 agree.
I think you are just being stubborn or displaying false bravado.
Yes, I agree with you, and I too use Qt and boost to ease porting. It's still not as easy as Java though :P
What's wrong with VC++ stdio?
_snprintf() and _vsnprintf() do not conform to the C99 standard: they do not guarantee NUL termination of the buffer while they should and return the wrong value if the buffer was too small. The former was a mistake of epic proportions if you ask me.
Microsoft tried to fix that with the non-standard _snprintf_s() and _vsnprintf_s() but these still return the wrong value in case of a buffer overrun.
I guess they prefix everything with _ because they are unable to implement conforming procedures.