C++ 2011 and the Return of Native Code 616
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."
For learning (Score:2)
For learning purposes, I find C++ to be a very good language.
Its confusing enough that most people not up to it will leave once you cover the basics of pointers, yet not so difficult or complicated that it would take too long to learn.
For instance, Java takes forever to understand as compared to C++, and no playing around with pointers either
Re:For learning (Score:2)
For instance, Java takes forever to understand as compared to C++
I can only find this to be true for people coming from certain backgrounds. I don't think anyone without previous programming experience would agree that C++ is easier to understand. :-)
Well, maybe it's easier to reach the point where one thinks he understand, then definitely easier to realize that nothing is actually understood even if somehow things worked
Re:For learning (Score:2)
To get into java you need a good understanding of OOP concepts and alteast basics of exception handling
You can dive into C/C++ knowing maybe just the absolute basics of OOP, and learn as you progress
Similarly, C++ gives you the opportunity to learn about memory management, overflows, errors you can encounter when not careful with types. Java handles all that for you
Re:For learning (Score:2)
To get into java you need a good understanding of OOP concepts ...
Yes, and then forget all about OOP, and learn Java.
Re:For learning (Score:3)
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.
Re:For learning (Score:2)
Re:For learning (Score:4, Insightful)
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.
Re:For learning (Score:2)
Depends if you're coming from native x86 assembly language or not...
I did, and all those objects were a pain until I learned how to use them properly....
Re:For learning (Score:3)
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...
Re:For learning (Score:5, Insightful)
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 [xkcd.com].
Re:For learning (Score:4, Interesting)
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."
Re:For learning (Score:2)
Re:For learning (Score:2)
Your contradicting several studies on the subject. I trust the studies. In your case, the studies clearly showed what you're depicting (at least at that time), is a by far a minority.
This may come as a shock to you, but believe it or not, there are large deployments of Windows servers with developers developing on Windows. Shocking - I know.
Re:This isn't auto mechanics! (Score:3)
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.
Re:This isn't auto mechanics! (Score:4, Insightful)
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.
Re:This isn't auto mechanics! (Score:3)
Re:But for learning programming, what's recommende (Score:4, Insightful)
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.
Never went away (Score:5, Insightful)
Native was never away. It always has its place. It is just that performance/efficiency is not always top priority.
Then learn the language better, stupid (Score:2)
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.
Re:Then learn the language better, stupid (Score:2)
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?
Because it doesn't provide full automatic memory management (smart pointers don't handle cycles), and because you have to write reams and reams of angle brackets to use them.
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.
I can't speak for .net, but in Java you have very little need for it. It's better to close your files and connections, but they'll be garbage-collected for you if you don't.
Re:Then learn the language better, stupid (Score:5, Informative)
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:Then learn the language better, stupid (Score:3)
Because it doesn't provide full automatic memory management (smart pointers don't handle cycles), and because you have to write reams and reams of angle brackets to use them.
If you're creating cycles then you didn't understand RAII. The objects in your cycle don't 'own' each other.
If you're typing lots of angle brackets then maybe you need to learn about typedef.
It's better to close your files and connections, but they'll be garbage-collected for you if you don't.
You seem to be saying that after I save a file I have to wait for the garbage collector to run before I can open the file in another application or move it somewhere else on the disk. How will I know when the garbage collector has run (assuming it runs at all...)? Am I supposed to quit your application to force it to close the file before I can safely email it to somebody?
Re:Then learn the language better, stupid (Score:4, Insightful)
But if you don't want to care about it then you don't have to - you can leave it to the garbage collector and it'll take care of it.
...this is the level of programmer who thinks he's able to criticize another programming language?
Re:Then learn the language better, stupid (Score:3)
and in java 7 with the try-with-resources it is handled for you.
Re:Then learn the language better, stupid (Score:3)
Not according to the Java documentation [oracle.com]:
Some applications interact with garbage collection by using finalization and weak/soft/phantom references. These features can create performance artifacts at the Java programming language level. An example of this is relying on finalization to close file descriptors, which makes an external resource (descriptors) dependent on garbage collection promptness. Relying on garbage collection to manage resources other than memory is almost always a bad idea.
Also, for the fun of it, look at:
http://stackoverflow.com/questions/6470651/creating-a-memory-leak-with-java [stackoverflow.com]
Re:Then learn the language better, stupid (Score:2)
Because it doesn't provide full automatic memory management (smart pointers don't handle cycles), and because you have to write reams and reams of angle brackets to use them.
Then maybe you need to look at shared_ptr from boost and the equivalent introduced in C++0x? The very classes designed for the situation you are talking about? Oh right, it's more fun to make ignorant comments!
You don't have that right, and you're probably writing code with memory leaks. From the Boost documentation: "Because the implementation uses reference counting, cycles of shared_ptr instances will not be reclaimed." You need to specially craft your cycle with a weak_ptr.
Why is C++ unmanaged? (Score:2)
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.
Re:Why is C++ unmanaged? (Score:2)
No. You can use .NET only in MSVC++.
Re:Why is C++ unmanaged? (Score:4, Funny)
Managed C++ combines the streamlined elegance of native C++ with the high performance, execution stack transparency and platform/vendor flexibility of .NET.
Re:Why is C++ unmanaged? (Score:5, Interesting)
Re:Why is C++ unmanaged? (Score:2)
You should look at the coding guidelines Google uses for C++. They only use a subset of C++. For them a of their guidelines make sense where they don't for 99% of the programming world. There is literally only a handful of companies which have the issues of scale Google must contend. As such, Google is rarely a good example to look at anything for general purpose computing.
Re:Why is C++ unmanaged? (Score:3, Informative)
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.
Re:Why is C++ unmanaged? (Score:3)
I don't recommend that.
That was my point. I completely agree with you.
I just had a falling out with another developer because he told me I was doing things dumbly because it didn't comply with Google's coding guidelines or Linus' irrational hatred of C++; amongst many other insanely stupid and completely irrational justifications. Of course, the falling out was caused by me politely explaining to him that coding standards have significantly progressed in the last several decades, followed by inviting him to join me. in at least this decade, accompanied with references to modern methodologies and development guidelines. He thought very poorly of me and the corrections. This isn't an exaguration.
Re:Why is C++ unmanaged? (Score:3)
I still printf in c++... Come at me bro
Re:Why is C++ unmanaged? (Score:3)
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.
Managed C++ in MSVC is simply C#.
.NET and Java - you incur performance penalties when you want to use them directly as you have to thunk back and forth between the managed and unmanaged portions of the system. I think Java is better about it than .NET, but its a pain nonetheless. It's easier, and more performance, to just stay in either unmanaged or managed code all the time.
Unmanaged C++ in MSVC is actual C++.
As to the native data structures in
Carmack (Score:3, Informative)
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.
ARC (Score:2)
With ARC, there really isn't a need for a garbage collector. I've used both, and the only things that happen in ARC that bite you are things that happen in Java, et al. I.e. you can still use a null pointer and such and get an error.
The only place I have been truly surprised is that some of the Foundation stuff can perform weird or unexpectedly. That's more that ARC is fully Cocoa ready and that you need to tread carefully when using toll-free stuff. But then ARC warns you, and then you need to just follow some simple rules of thumb about giving ARC a hint about how you plan to use the Foundation object. I suspect that might get resolved later.
All in all, I am *very* impressed with ARC. It makes life so much easier, and it gets you almost all the advantages of GC--or at least all the ones that matter or people really use.
Re:Carmack (Score:5, Insightful)
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.
Re:Carmack (Score:2)
VMs just don't play well in embedded environments.
Yet, Android seems to be doing just fine.
Re:Carmack (Score:2)
Re:Carmack (Score:2)
Re:Carmack (Score:2)
Re:Carmack (Score:2)
Re:Carmack (Score:3)
Garbage collectors have some problems which can't be fixed:
a) Garbage collection only works for RAM, it doesn't release resources like files, network connections, etc. in a timely fashion.
b) When RAM is low and you start swapping to disk a garbage collector which scans/compacts the entire heap every few seconds will cause massive disk thrashing.
Given that freeing resources is mostly a non-issue in C++, why would anybody want a garbage collector?
Re:Carmack (Score:3)
I've never understood this position. It always reads as, "Since we have more power we can be inefficient with it."
False dichotomy (Score:4, Interesting)
Look at Objective C or Vala -- just as easy as C# or Java, but none of the headaches of a virtual machine runtime.
Re:False dichotomy (Score:2)
Re:False dichotomy (Score:4, Insightful)
Um, because it runs on the CLR in a fashion almost identical to Java on the JVM?
Re:False dichotomy (Score:3)
The CLR is a VM. You can't ask the machine to load CIL. It has to be interpreted by the CLR first.
CIL is never interpreted. It is always JIT compiled.
Re:False dichotomy (Score:2)
I always quit learning Objective C because I think the syntax is ugly as hell. Smalltalk was also disgusting (especially those If constructs), and Erlang is one yucky language too (Erlangers acknowledge this and even tell you to suck it up on the homepage). One of the best thing C and C++ had is a somewhat aesthetical syntax (although there are messups like "=" and "=="). Pascal is really pleasant to read, and so is ALGOL (I've never programmed in it and I can understand it, although the "OD" is awkward). Python is pure bliss.
I expect a lot of bashing because of this "form over function" stuff I'm saying (in Slashdot, no less!), but I think that programming languages are languages nonetheless, and therefore can be beautiful or ugly. We have moved from "anything goes" into "if I don't like reading it, I don't like using it". Why should we use a language that causes eye bleeding?
Re:False dichotomy (Score:3)
Look at Objective C or Vala -- just as easy as C# or Java, but none of the headaches of a virtual machine runtime.
Objective C doesn't have a runtime? I wonder why Apple decided to write a manual for it [apple.com].
For me. (Score:2)
Using native code was never something which contradicted using scripting languages (in my case: python, perl, matlab, tcl) or java. Mixing them in the right way does the trick.
My approach was: use whatever tool is suitable. Write native what needs to be done native (and preferably use ANSI C for it), write guis in (preferably java or tcl).
Re:For me. (Score:2)
Re:For me. (Score:2)
I coded for AWT and Swing in the 90s. The app you use to demonstrate looks a lot nicer than anything I recall seing use those toolkits back then.
Also, honestly, the app you link too looks like it has a reasonable UI for the role it performs. I would love to see current apps that work well for power users*, but which have "sleek" UIs. 90% of "good UI design" is moving 90% of advanced features and behaviors away from the first impression.
* read: "People who don't stop learning how to do the thing better"
Re:For me. (Score:2)
I agree. But tcl is even worse ;)
If you want GUIs and portability, there is no competition to Qt. It's Free, too.
Smart people know already... (Score:5, Insightful)
...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.
Looks like I was right (Score:2)
>>Modern programmers have increasingly turned away from native compilation
Uh, not me.
I never saw the benefit, only the pain.
The so-called "managed" environments solved a problem I didn't have while adding complexity I didn't need.
Doubt (Score:2)
I very much doubt that C++11 heralds any kind of new interest in native code. Rather, native code in general has been getting more attention recently and C++11 just happened to be finalized around the same time. (Disclaimer: C++ is my second-favorite language. I want it to be liked and used, but I'm realistic.)
Nearly off-topic in the article is this gem of a paragraph:
This is most certainly not news, but I find it refreshing to see the blindingly obvious repeated again. IT shops that "standardize" on one language (or framework, even) are simply zapping themselves with low-voltage-yet-eventually-lethal tasers. Managers, take note. Again.
Re:Doubt (Score:2)
(Disclaimer: C++ is my second-favorite language. I want it to be liked and used, but I'm realistic.)
I'm curious. What's your favorite?
Slightly OT... I apologize... (Score:2)
But does anyone know if or when there's going to be a book (you know, one of those paper things that you physically hold in your hands and actually have to turn pages to read instead of looking glaze-eyed into the glow of a computer monitor) that covers C++11 fairly exhuastively, such as how, for comparison, Stroustrup's "C++ Programming Language" covered the previous standardized version relatively thoroughly?
Thanks.
Re:Slightly OT... I apologize... (Score:2)
There probably will be a dead tree book--but I seriously doubt that you will be able to physically hold it in your hands for a significant interval unless you're a world-class bodybuilder. Note that the special edition of The C++ Programming Language is over 1,000 pages, and it's over a decade old!
Return of the script kiddies. (Score:2)
C++ got a very bad reputation, Do to the helpless little script kiddies, That thinks memory management is something a real programmer is concerned about. And now you tell me that; these dime a' dozen script kiddies are coming back! ARGH! :(
Re:Return of the script kiddies. (Score:2)
Want a scare? Do an "emerge -e world" on Gentoo, and run a script on the output to count how many "result unused on function declared with 'warn on unused result'" messages you see.
Doesn't have to be unsafe if native (Score:4, Insightful)
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.
Re:Doesn't have to be unsafe if native (Score:3)
The crashes are solely due to using C++ as C, i.e. manual memory management, C casts, pointer arithmetic and C arrays. If none of the C features are used, then C++ is as safe as the languages you mention.
Re:Doesn't have to be unsafe if native (Score:3)
How dare you want that functionality. May you work with Javascript forever as a suitable punishment.
They're both called iOS (Score:3)
Re:Doesn't have to be unsafe if native (Score:3)
Well it's certainly not for lack of options
Ok name a language that
1: allows both RAII and close to bare metal coding to coexist as appropriate for each peice of the code in question without having to resort to the mess of mixing languages
2: Has a high quality FOSS implementation
3: Is widely ported
Exclusive to one language? D2 (Score:2)
Is there anyone these days writing applications in one language in exclusion to any other? I'm feeling old. I wrote applications in ASM because it was exclusive. Then I wrote applications in Fortran because it was easy. Then basica because it was way easer. Then Pascal because it was the shiznit. But then applications became more complex because of these GUI things and stuff. That is when the OO languages like C++ kicked ass. Now days it is so "normal" to write something that communicates with the actual interface (ie. HTTPD and the browser. SMTP and the reader...). It doesn't matter what you write it in as long as it is fast and works in conjunction with some dynamic language. I like the additions 11 has brought to C++, regex, threads, pretty much anything boost has added. I'm using C++ today, despite not learning OO programing until I was in my 40's. As someone who has watched people fall in and out of love with languages I have to wonder why so little attention is payed to D2. Most of the additions to 11 are in D2. er I think. Did I mention I'm old?
"Modern programmers" who have any clue... (Score:2)
... never distinguished between "native" and "managed" code.
Write the damn code according to the rules and idioms of the language in use, let the language implementation deal with the rest. If you're an application developer and care about *how* your code is being run, you're doing it wrong.
Confusing lots of issues (Score:5, Interesting)
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
Re:Yikes (Score:5, Informative)
Re:Yikes (Score:3)
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.
Re:Yikes (Score:2)
I maintain professional (though ancient) C++ code, and actually, the whole new/delete and raw pointers seems rather elegant to me... Or perhaps (horror of horrors), I am being slowly transformed into an ancient Unix nerd...
But I have to admit there is one bug that I am struggling with. Somewhere someone is deleting an object during shutdown too quickly and causing a crash(and visual C 6.0 doesn't help me trace this easily).... So your way is possibly better...
Re:Yikes (Score:2)
Re:Yikes (Score:3)
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!
Re:Yikes (Score:5, Insightful)
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++.
Re:Yikes (Score:2)
Yes, because managed code has no memory leaks.
Yes, and managed code never has need for manual memory management [microsoft.com]. Oh wait...
Re:Yikes (Score:3)
or reference counted smart pointers [microsoft.com]
Re:Yikes (Score:3)
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.
Re:Yikes (Score:4, Informative)
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 (Score:4, Informative)
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:Yikes (Score:3)
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.
Re:Yikes (Score:3)
I use Python for most things, c/c++ when I feel the need for speed/power.
And today PyPy [blogspot.com] released version 1.6 of their python interpreter :) More python speed!
Re:Yikes (Score:2)
Thing I've found with memory management is, that while it "just works" and you don't have to think of it for relatively straight forward stuff.. when you start getting into more complex OO designs, memory management actually becomes more of a pain in some situation!
Memory leaks in a managed language _are_ possible! When you start having references flying left and right.. you get into situations where two objects you are finished with are referencing each other (or themselves) and thus trick the garbage collector into keeping them around. Throw swing into the mix and the fun really starts. As a design gets more and more complicated.. you have to be very diligent (and practice good design) to ensure everything has a clean route to being dereferenced.
Compared to un-managed languages where you clean the memory yourself.. which is a pain in the ass for small, straight forward stuff.. but I've found takes a lot of the headache out of complex stuff (as backwards as that may seem).
Re:Yikes (Score:2)
>>Thing I've found with memory management is, that while it "just works" and you don't have to think of it for relatively straight forward stuff.. when you start getting into more complex OO designs, memory management actually becomes more of a pain in some situation!
Absolutely. When I tested some Java code, it ran correctly on all platforms except one obscure one (WinNT on SGI). On that platform, which was unfortunately something I had to support, it wouldn't unallocate memory correctly, it'd leak out of memory very quickly, and then run as slow as a dog as it swapped frantically.
I had to rewrite my damn code (which had nothing wrong with it) because Java's "write once run anywhere" motto is more or less a myth - when virtual machines are implemented differently, you *don't* have the guarantee of reliability and portability they promised.
Re:Yikes (Score:2)
New hardware has bought us the ability to use managed code for most (not all) software. Isn't this much better than expecting every programmer to perfectly manage his memory every time?
So all that .net stuff is about garbage collection? Why not just have a standard way of letting the operating system take care of it in the background?
All this "managed code" seems to have resulted in is machines with a stack of complete ".net framework" versions numbered 1.0, 1.1, 2, 3, 3.5, and 4.
It would be nice to get rid of this multi-gigabye pile of bytecode, if it's all just to save a few K of ram here and there.
Re:Yikes (Score:2)
Ok,
So it's half-assed garbage collection, 5 or so different metric tons of libraries (all incompatible), and an IDE?
What does the IDE have to do with the language?
Re:Yikes (Score:2)
Re:Yikes (Score:2)
New hardware has bought us the ability to use managed code for most (not all) software. Isn't this much better than expecting every programmer to perfectly manage his memory every time? Just wait a couple more years and we won't be feeling the hardware pinch even on phones.
Personally I hope new machines start learning from the past [wikipedia.org] and implementing processor instructions to make GC easier and support things like runtime type checking. ARM has ThumbEE [arm.com] which is definitely a step in the right direction. Basically, I see the proliferation of "Managed" run time environments as a consequence of computer architectures remaining dangerous to write code for — we can pack a lot of transistors onto a die nowadays so why not use some of that space for features people have been implementing in software for decades?
Re:Yikes (Score:2)
Memory management is a red herring; even managed application require it. Garbage collection will just hide poor application design and the inefficiencies that make it difficult. You can still crash on null pointers, leak references and most certainly leak external resources quite easily.
C++ just actually makes you actually have to think about these things. You actually have to pay attention to your allocations, scratch space, ownership, etc, and quite frankly applications are often better for it. Well.... were. These days you have devs that never learned how to actually design an app for a computer (basically read 'C') shoehorning their ill-advised classes and designs that worked so OK in Java, etc. into C++ and find that it doesn't work. I just love stuff like "new int[10]"...
Re:Yikes (Score:2)
Just wait a couple more years and we won't be feeling the hardware pinch even on phones.
You will always feel the hardware pinch, because every level of abstraction gets people thinking about how to make new levels of abstraction over it. So something even more bloaty will surely come along to soak up your "faster CPU" or occupy your "more memory."
Phones will always only be as fast as the market will bear. As soon as Joe sixpack, who has no idea that it should not take ten seconds to save a calander entry to his personal organizer app, is happy, the phone will ship.
Re:Yikes (Score:2)
Again as a counterpoint, just look how much code written in .NET has to implement IDisposable which if not done means that programmers will leak all sorts of non-memory resources such as file handles, etc
Your counterpoint misses the point.
Pretending the problem doesn't exist doesn't make it go away.
Nobody is pretending the problem of resource management doesn't exist.
Car analogy:
Your argument comes across as saying drivers shouldn't use automatic transmissions to reduce the effort they need to spend to maintain proper control of a car because they still have to steer and work the gas.
Programmers still need to be focused on resource management, just as drivers still need to be focused on controlling the vehicle. Garbage collection, like automatic transmissions just reduces the effort required.
Re:Umm - mod article down (Score:2)
c/c++ have always been perfectly useable for doing both system and application programming. And with the inevitable increased emphasis on energy efficiency, we're going to ask "how much energy can we save by converting [insert application of your choice] from a managed or interpreted language to a program compiled in c or c++?
For some large-scale applications, not only is it the best option, but the only option if you want to ever finish before the next [load of data/batch of requests] comes in.
Re:Umm - mod article down (Score:2)
I presume you're referring to this:
Not that C++ really ever went away. With its older cousin C, it remains one of the most popular languages for systems programming and for applications that call for performance-intensive native code, such as 3D game engines.
I fail to see any problem with this statement, except perhaps that it implies that C++ was designed only for performance applications, when really it was designed to handle anything you throw at it (of course, other languages are better at certain things, meaning people will pick that language because of their needs, but no language is as good as C++ at absolutely everything) and handle it efficiently.
Re:I'm sticking with mono (Score:2)
Re:Native code for enterprises is stupid (Score:2)
If your code is to be maintained by junior programmers, then choose a managed code environment.
With that one criterion, you may have completely struck those languages from candidacy for any project whatsoever.
All C and C++ programmers are "junior programmers" while they become proficient with the language, and nobody becomes a "senior programmer" without having learned from their own mistakes. You can't jump to C (or even C++) from languages like Python or PHP without undergoing a set of major paradigm shifts, and I'm not just talking about memory management.
One does not "simply walk into C++."
Re:exploits (Score:2)
Even almost perfect native code can expose massive security holes.
Indeed. Just look at all the security holes in the JVM.
Managed code is an improvement security-wise, but you're still exposed to the hazards of bad native coding.
.
Case in point: the Nintendo Wii (Score:3)
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.
Re:Oo isn't all there is (Score:3)
You mean like C++ with Boost?