Slashdot Mirror
Valgrind 1.0.0 Released
Anonymous Lazy Boy writes "Yesterday saw the official release of Valgrind 1.0.0. Valgrind is a C/C++ programmer's dream come true: effortless memory allocation checking, uninitialized memory access, leaks etc. Purify for Linux has arrived, only better: contrary to its commercial (non-Linux) sibling, checking is performed directly on the executable, no re-linking necessary.
The technology behind Valgrind is highly fascinating and explained down to the very gory details in the documentation."
"but there's a long long list of ways in which it is vastly inferior to Purify right now"
How about showing us that list?
--- Hindsight is 20/20, but walking backwards is not the answer.
Good programmers will not depend on something like this to get their code working, but it will still be a great tool for them to make sure they didnt mess up somewhere in the last 9hours of solid coding. Its probably kind of like wearing seatbelts, you dont need them to be able to drive but if something goes wrong they come in quite handy.
valgrind is freely downloadable *with* the source. Here we have someone that has put toghether a very impressive tool which, you admit yourself, does things that require 3rd party tools to do on Windows, and all you find to say "I don't care because stuff on Windows sorta maybe does it anyways".
Instead of commending somebody on their very talented effort and for making it all Free, all you do is make loud claims that memory management isn't the way of the future for "us l33t modern day programmers"-- followed by the amazing claim that C memory allocation is somehow sub-optimal.
The fact is that for all that vaunted "10 years" advance you claim the Microsoft C runtime has, memory management has been the bane of every product Microsoft ever produced.... I still get company wide emails twice/thrice weekly of this or that exchange server needing to be rebooted again.
If I had mod points, I most certainly would have modded you a troll.
Do not spread "09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0" over the internet, thank you.
I think this is a bit misleading, it's actually a Linux/x86 virtual machine. valgrind is an environment, not just a library you link to. You don't "enable" it on your binary, you need to specifically run something under this VM. It's more akin to running something through the debugger "hey, lets do our daily/weekly valgrind run" than something you could run all the time. Or maybe do it when you have specific errors and wnat to smoke them out. It's a totally different type of tool.
I think the VM concept is quite clever. It would be interesting to see debates about it. On the good side, it cheks EVERYTHING, not just stuff you turned the switch on for. Even bad system libraries (it has switches to turn these off so you don't get deluged by them). On the bad side, it's obviously Linux/x86 only. I guess it pays to keep your code portable. I'm in a SPARC/Solaris only shop, but I could see myself keeping things portable to linux enough to run this, say once a week to ferret out bugs.
C-style memory allocation is the basis for any garbage collection system. It may not be the right tool for every job -- certainly it is smart to build a more powerful system atop it -- but it is not obsolete, and never will be as long as programming remains in an environment similar to what we have today. And it is optimal for what it does. That's why you build a GC on top of it, and not the other way around.
And of course, you have to be careful with claims that garbage collection is some sort of panacea. I almost never use new and delete in C++, for example, because I have automatic local variables, implicit temporaries, and deterministic destruction at the point where either go out of scope. People somehow think that it's clever that you can write
in Java, and that if you write
in C++ it's inferior because you have to delete it afterwards. They ignore the fact that the vasty majority of the time, you're actually going to write simply
instead, and have no worries about releasing memory, or failing that, you're going to use a suitable smart pointer class and similarly have no worries. And in languages with "low level" allocation like C++, you get deterministic destruction in the picture as well, which is a massive advantage over the GC approach as evidenced in languages such as Java (and many others, too).
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Moderation privs should not be used to suppress opinions with which you disagree.
You mean just like real programmers don't use, editors
but write the code directly to the compiler input stream. They don't need debugging tools either.
God is REAL! Unless explicitly declared INTEGER
Many of these high level languages have problems of their own. Languages like Python, Perl, and TCL lack any sort of compile time checking, which makes them error prone, and less scalable. This is why you don't see many applications that are millions of lines long developed in these languages. Simply put, memory management is not the only issue that programmers deal with maintainability is very important, and robust compile time checks, and the clarity that comes from having to explicitly declare interfaces and having the compiler check types is a maintenance benefit.
And indeed this is happening within the Unix world, though outside it most applications shops still seem stuck with the archaic Unix strategy of coding in C (or C++).
Another fallacy -- that C++ is somehow "equivalent" to C. C++ does not make memory management as simple as java, but it is certainly simpler than C, and arguably, for nontrivial applications, it is at least as good as languages that force a reference counted system on the user (python, perl) as reference counting is often not an appropriate memory management model.