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."
One thing I've found with automated QA products is that usually they have critical faults that prevent them from being realistically useful (for instance many of them grind to a halt or give false positives in multithreaded apps). How's this product for real world use? (And no this isn't a "Read the Article!" question...the article is like a press release and hence doesn't answer my question).
Beware of gratiutious hype.
And, btw, Purify (never used it under Linux so maybe it is different there) can also work on executables (and DLLs/SOs, etc) without a relinking. When's the last time the person who posted used Purify? 1996?
Are you trolling? Or stupid? Or have you never used Purify? I've yet to meet a developer who used Purify (or in some cases BoundsChecker or similar tools, though IMO Purify is hands down the best if you can afford it) that decided it wasn't really helpful and then stopped using it.
These tools give you SO MUCH more than just simple stack tracing after a crash. Foolish is the developer who ignores their benefits.
The bad thing about Purify is that there ain't no Linux version.
I have used Purify ever since it was first put onto the market by Pure Software about a decade ago. But nowadays, Linux is becoming our real development platform, so if Rational ain't careful: exit Purify. Yes, it's sad, but I've told them often enough that Linux support is what they should bring me, not yet another rewrite of their licensing scheme.
Linux user since early January 1992.
Valgrind really is an amazing bit of software. Working on large application which use many different libraries it becomes harder and harder to work out where those bugs are, and all the free tools I have tried so far have done a very poor job of finding them. I have now been using valgrind for several months, and got 1.0 straight from the author by mail having reported a few bugs in earlier versions. It speeds up finding those hard to reproduce bugs, and often shows up memory errors which you didn't even know were there. It is also excellent for detecting memory leaks as it knows the difference between memory that has been genuinly leaked, and memory which is not freed, but still has a reference to it stored when the program exits. All the software I work on is now much more robust than it was a few months ago, and much of this I can put down to valgrind being available. This is the only free tool that comes close to the commercial tools like Purify, and in many ways it is superior to some of the expensive high end tools. The author is extremely responsive and helpful, and has been developing valgrind full time self funded.
I've been waiting for this. I've seen the malloc debuggers and the like (electric-fence, gccchecker, etc), but they're all incomplete, have problems with C++ code, or are just for allocated memory ('new'-ed objects, malloc()-ed data, etc), not for regular vairables: statics, local variables, etc.
But valgrind seems to be just right I gave it a quick tryout and it is looking good!
Wow.
apt-get install valgrind.
And all we need now is a gvalgrind, and/or a kvalgrind gui interface just like purify has and I'm all happy.
--- Hindsight is 20/20, but walking backwards is not the answer.
"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.
One of the many great things about purify is that (IME) it only slows down your code by 10-20%, which is small enough that you can always leave it in your code. Leaving it in for unit testing, integration testing, system testing, beta testing, etc., can make your life much easier.
Valgrind, however, runs your code 20-50 times slower, which means you can't have it on all the time. This is unfortunately, for it looks like a great tool, otherwise.
Hum,
:)
[chicken]~> vagrind valgrind
seems to work ok. But valgrinding a valgrinded valgrind causes some ugly errors and asks for a bug report. Well, I know this isn't fair.
Anyways, this looks like a really sweet tool.
I Had to debug GDB and Valgrind helped me find memory leaks in this and gdbTK
GDB is pretty icky so thats a ugly program for you it also managed to debug my ARM/MIPS sim which is small
overall I give it 5 stars
regards
john jones
Especially since purify doesn't run on linux...
Please don't feed the trolls. All the posts claiming a backdoor in Valgrind and supposedly responding to each other ("Hey, I found it too!" "Me too!" "Here's what I got!") were all posted by the same person.
I do hope that the moderator whom is labeling these posts as "trolls" has done his/her homework regarding the accuracy of this and following posts...
I was just reading this thread and everything was +2/+3 informative. Suddenly everything has been knocked to 0/-1. Did we discover some relevant piece of information about the posting ACs that made that a wise decision? This sounds like it's at least kind of important. What's going on?
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_s
And contrary to what you may think, it's qiute easy to use:
Or even easier: make your classes derived from gc.
In C, you just replace malloc.
And I have found that there is no slowdown wen using a garbage collector. It's nice, and keeps the code clean. Try it someday.
Hi. KDE developer here. We've checked developer.kde.org (the machine hosting Valgrind) and the md5sums. So far this looks like a hoax, so please move on. We will stay on the alert and continue investigating, but to quote one of my favourite authors: don't panic.
(18:14:38)(~/src/valgrind-1.0.0): grep open vg_scheduler.c
(18:14:45)(~/src/valgrind-1.0.0): grep 11 vg_scheduler.c
02111-1307, USA.
(18:14:52)(~/src/valgrind-1.0.0):
I am neither trolling nor stupid, and I don't find Purify that useful. I am also not as insulting to people who don't agree with me.
In the 60's, we programmed in Fortran, and debugged with PRINT statements.
In the 70's, we programmed in Pascal, and debugged with WRITE statements.
In the 80's, we programmed in C, and debugged with printf statements.
In the 90's, we programmed in C++, and debugged with >>.
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.
And, btw, Purify (never used it under Linux so maybe it is different there) can also work on executables (and DLLs/SOs, etc) without a relinking.
You wanna know why you've never used Purify under Linux? Cuz it's not available. AFAIK, no Rational tools are available for Linux. When I was looking for Linux tools at my previous job, the only memory checker available for Linux was insure++. I also found that there were no commercial profilers available for Linux. gprof just doesn't cut the mustard, especially in multithreaded apps, and Rational's Quantify wasn't available for Linux. When I called Rational to ask if they planned on supporting Linux, they said "Maybe sometime in the future", but when I continued questioning them, they said they had no immediate plans to start working on Linux versions of any of their software.
So, while Valgrind may not be as complete as Purify (I don't know if it is or not), it's a helluva lot cheaper than insure++ (~$4K license -- well worth it if it's not your money), and better than any other Free software I've seen.
Hi,
. bz2. md5sum
I have just verified that we have no evidence of
a backdoor in valgrind.
This is the correct md5sum
76c59f7f9c57ca78d733bd956b4d94ae valgrind-1.0.0.tar.bz2
I will put this information also online on
http://www.kde.org/md5sums/valgrind-1.0.0.tar
So you can check this information via a second channel.
Yours,
-- martin
P.S.: The AC claims incorrectly that exact the above md5sum indicates a compromised archive which is plain wrong!
oh please... SGI had fix and continue plus debuggers way better than VS7 8 years ago. Proper interactive debugging (type call blabla::XX(5,8) to step into member function etc and purify hasn't improved since rational bought it.
http://rareformnewmedia.com/
There is no "GNU version of Java".
GCJ supports everything in Java 1.2 except for AWT (most people aren't using Java for GUIs anyways), almost all of the 1.3 stuff, and a large portion of the 1.4 stuff.
Most Java software out there today (Tomcat, etc) is designed for Java 1.2. Not much changed in 1.3/1.4.
In a pinch, you can actually take the .jar's from Sun's Java distro, run them through GCJ, and get native code binaries. You can't redistribute these, but it's handy if you're writing server code rather than shrinkwrapped software.
Could some kind of merge be possible, adapting Bochs to use Valgrind's simulator without the malloc-checking stuff? Also, I wonder if Valgrind could be adapted to simulate other CPU's besides the x86.
Trolls are busy at work today I see.
I actually wasted about 15 minutes looking into this.
They only apply to USSA citizens and other backward nations. I would not be suprised if Valgrind had US patent issues, but then so does just about anything but breathing
I've just grepped through vg_scheduler.c looking for `bind', `sock', `11', `RAW', `raw', and several others. I've come up with absolutely nothing. Admittedly, I haven't checked out the entire source--at 3500 lines, it'd take me several days to do a proper audit--but so far I haven't found any references to socket calls anywhere.
:)
Still, I would appreciate it if the maintainer could check out vg_scheduler.c and see if there's something amiss there. Thanks.
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.
Excellent point. It's also another reason why I've found Parasoft's Insure++ to be superior to Purify.
I'm sincerely looking forward to checking out Valgrind. Can someone post a feature comparison of these three?
1.0 is available in unstable.
Cool.
So you *are* stupid after all!
Franckly, I have the impression that Rational regard Purify and Quantify as cash cows that should not be touched unless absolutely required. All they ever did since they bought them was:
Other than the gcc 2.95 thing, I have seen no real improvements in years (I don't use Windows). Over the years, we forked over a lot of money for "support", though.
It's a great tool, but I'm not impressed with the company behind it.
Linux user since early January 1992.
Today BitWagon offers a profiling product tsprof which requires no recompile and no relink, and handles main programs, shared libraries, dynamic modules, pthreads, and SMP; does direct time and event measurement based on hardware counters (no sampling) and provides highly effective interactive graphic output in addition to tabular text. So far, response again lags. Maybe Rational is onto something.
So, basically, you are saying that you work in the most inefficent way possible because it makes you more manly. I tire of people who will try new tools and techniques because it isn't the way our forefathers did it. Bottom line: I can find and fix defects faster with a debuggers and such than with prinln/>>/printf etc. Hence, the reason we call it a "Poor Man's Debugger." As an engineer, you should always be looking to improve the efficency with which you work. End of discussion.
Whether or not you like Purify and its ilk are inconsequential, but your refusal to open your mind to new methods and techniques are what repulses people. Attitudes like yours create COBOL and FORTRAN system maintainers -- not true software engineers.
Read the core dump? Ha! Good programmers know what's wrong from when the segfault occured.
But if you're going to use tools, having a tool that tells you when a value gets written somewhere wrong is far better than one that tells you what was going on when the program actually crashed.
This is actually vital for bugs where an uninitialized value is assumed to be zero, and it always is zero in your tests, but...
Here's some suggestions :
1) don't charge such an absurdly large price
for software mostly built on free software
(Mikael's perfctr)
2) accept that when you have competition that
is free software, it's gonna beat you.
[Disclaimer: I am indeed the lead developer for
your competition]
-- Remove the trailing '\0' to email me.
That's why they are holding on to their pile of cash. There is talk of them forming "Microsoft Capital" which would provide financial services like GE Capital does.
So, the Linux crowd might get their wish and find that one day MSFT is a bit player in OS software, or perhaps even discontinues their OS someday. In fact, I wouldn't be a bit surprised if Bill Gates actually dreams of discontinuing Windows so that he can just own shares in a nice reliable big banking and financial services conglomerate during his golden years.
This will leave a bitter taste in the mouths of those who are truly vengeful and hate "M$". Like most people who have the winning way, BG and company will go on about enjoying their lives scarcely even conscious of those who hate. Meanwhile, the hateful will continue eating ramen and lamenting what they see as the injustice of the world. Those who simply wanted a better OS will probably eat ramen too. The difference is that they will do it with contentment, because they too have the winning way.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Still, why not do it that way? Machine resources are cheap.
Moderation privs should not be used to suppress opinions with which you disagree.
... but I try not to dream in and/or about C/C++. It hurts. :)
On the other hand, dreaming in perl is probably pretty close to the programmers version of an acid trip. The colors!
For most applications, it just makes better sense to avoid these errors altogether by using a good garbage collector.
An excellent implementation is the Boehm-Demers-Weiser (commonly referred to as just "Boehm gc") conservative gc. It can be used for C/C++, and is highly portable. It's a real-time, non-compacting (so you still get heap fragmentation like managing memory by hand, but the collection time is shorter and it's more portable), and uses a conservative mark-sweep algorithm (briefly, treats anything that looks like a pointer as a pointer, to avoid costly checks or increase portability in the case of C/C++.)
For a moderately large amount of garbage, the incremental collection pauses take less than about 5-10 milliseconds (hence why it's a real-time collector) on a PIII-500, the algorithm scales fairly well, and it's suitable for all but the most time-critical (anything video related) or memory-thrashing (I really don't know of any app that needs to be) programs. GC will speed up development time tremendously, and can eliminate segmentation faults and memory leaks for most programs. I really don't understand why more projects don't use it.
That being said, Valgrind does seem extremely useful for projects that do need to allocate memory manually. It looks very convenient to use, and the thoroughness of the checks is impressive. The implementation does seem a little uncomfortable to me - it's certainly a lot of effort to write a whole virtual machine just for the task! The portability prospects aren't appealing either.
In the great CONS chain of life, you can either be the CAR or be in the CDR.
There are two important features of Purify that are most notably absent in valgrind:
- the ability to specify user's memory allocators/deallocators (it is mentioned in the documentation, though)
- the ability to detect array bound violations (Purify's ABR/ABW).
You decide which of the two is more important for you.
(let ((I (get '*lisp* 'programmer))) ,no-worry-about-GC)
:memory-management
:optimization
:ease-of-use t))))
`(been I
(setf (get 'I 'skill) '(good programming techniques))
(with-carelessness
(learnt (have I) 'to-code
(with-no-worry-about
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
you obviously have no idea what you're talking about
$ grep Megacz /usr/src/gcc-3.1/MAINTAINERS
Adam Megacz adam@xwt.org
Yeah, I probably know absolutely nothing about gcj...
A lot of people seem to be saying, "Just use a good GC".
But from reading the Valgrind docs, it's more than just a GC. It checks for accessing memory through uninitalized variables, too... Very cool.
Disclaimer: I have not used valgrind yet, just read the online docs
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
And wouldn't you really rather be told when the dynamic linker has added or removed modules? The current interface to DT_DEBUG, _r_debug.r_brk, _dl_debug_state might be suitable for a controlling process, but it's painful for a same-process debugger. For instance, on x86 there might be only one byte of code at _dl_debug_state(), so you cannot easily overwrite it with an arbitrary transfer of control. And if you use an int3 and SIGTRAP handler, then you cannot run gdb at the same time.
What about libraries that are doing all kinds of memory allocation behind the scenes? I'll be jiggered if I know what the hell XAlloc-this and XFree-that are doing.
Using valgrind, I've found several memory leaks in my code using the libX11 and the FreeType libraries that strictly were my fault, but were counterintuitive and I never would have found them solely reading the documentation and using print statements.
I'm thrilled to have a tool like valgrind on linux, finally. Thanks Julian!
No we haven't. MSRT bundles a fairly normal bounds checker. From reading the documentation it seems valgrind is a CPU emulator with memory read/writes logged and analysed.
And you deserved it.
Perhaps, but until we have finished moving there will be a need for tools like this.
the ability to detect array bound violations (Purify's ABR/ABW)
Practically speaking, I think that it frequently does. It allocates memory blocks in such a way that writing beyond the end of an array (or before the start) is detected as a bad-memory access, so it will catch array-bounds problems for dynamically-allocated 1D arrays and frequently n-D arrays.
Valgrind, alas, does nothing much to help.
Um, Valgrind apparently can more or less replace PurifyPlus, which is not available on Linux. PP was one of 3 dev components you mentioned. Thus, one third of the problem solved (or alleviated).
So how is not doing much to help?!?! You think it's ok to have have 3 (somewhat) separate tools on Windows, but in Linux one tool needs to do it all? What am I missing herE?
I like paying taxes. With them I buy civilization -- Oliver Wendell Holmes
Developers workstations are *supposed* to be bigger better faster more than those of the plebes, and don't you forget it!
Don't laugh, but I think the opposite is true. I do all of my development on a 600Mhz Pentium II, because if I can get my code to perform well on that box, it'll be that much faster on most machines in the "real world".
I've used Purify for nearly a decade, and have been banging on valgrind for several months as well. I think that two of your three criticisms of valgrind are off base.
valgrind copes with static libraries. The only requirement is that the executable be linked to at least one dynamic library, and glibc will do. This is needed to allow valgrind to get control. Since for Purify you need to have the .o files so you can link, in the analogous situation with valgrind you can always link dynamically with the C library.
Valgrind has a suppression file that is much like that of Purify.
The only point you raise that is completely valid is that valgrind is x86-only. Those who really care might want to work on a port to other architectures, though it's a big job: you need a complete virtual processor.
Purify's GUI can be quite useful, but it would be preferable, if someone wants to do the same for valgrind, to implement any GUI as a completely separate program. That way the KDE and Gnome people can assure that there are at least two of them. :-)
Finally, to be fair I suspect that a Purify'd executable is faster. But then, you don't have to do a special, expensive link step, so the compile-debug-recompile flow feels faster with valgrind.
I've never heard of tsprof until I read your post here. Maybe that's part of your problem. When I searched Google for 'Linux profiler', It didn't show up in the first fifty results or so. This means I wouldn't have found it had I been looking for a profiler right now. Maybe the text on your web page should include the word "profiler"? I would assume that most people looking for a profiler would search for it by that name.
You could try getting more people to link to your web page, or find other ways to get the word out. Unfortunately, you have pretty tough competition, and you can't beat their price. I don't know what you've done to market tsprof, but it was probably not enough, or it was done the wrong way.
Your Flat profile window looks awsome, by the way. Would have been cool if you colored it using only 4 colors, though...
Good luck!
yea, a clever reply! :)
I'll just start by saying that I'm not just a Java programmer. I have about 5 years of experience in C++. I did mainly server side programming and no real GUI, just moving around data.
C/C++ do not give you complete control over execution. You can't tell me you don't link to libraries. If you don't, then you are throwing away hours of time that your competition is adding features. At some level, you have to deal with an OS that may or may not work the way you expact as well.
Java does manage to do garbage collection for about 20% penalty, and LISP isn't bad at all itself. If other people can do it right, then why not C/C++? It really doesn't have to be as bad as people make it out to be. Think about the logistics of it sometime. It wouldn't be difficult or too taxing to keep a hierarchy of pointers in a central class/table and call a cleanup function every 10 seconds or so to check where pointers have changed and which memory addresses allocated are no longer being referenced. I would like for it to be done at the language level because frankly, the people who would care enough to do such a thing to begin with would probable not have memory leaks anyhow. Those that do debug their software should be writting more good software and features instead of debugging something that is unneccisary. Not that GC should be forced, but it should at least be an option!
Just because there is an ISO/ANSI standard for C/C++ doesn't mean that people follow it, yet they still call it C or C++. At least with Java, if it has the cup, you know it passed the certification. Don't get me wrong though, it's not that I don't think it should be open to the public, I just don't think it should be called C or C++ when it isn't really. Honestly, do you think that GCC is perfectly ANSI compliant? I don't see how since v3 caused everyone to fix some of their non-ANSI code. It still supports multi-line string literals despite the ANSI standard. There's as much of an ANSI standard for C/C++ as there is for SQL. It's very difficult to write SQL or C/C++ code that works on multiple compilers in the way you intend. ISO/ANSI has been a complete failure in ensuring that the standard is followed.
I think that even for the user's sake there needs to be some consistancy between GUI's. Native GUI's are a terrible thing in most cases. Just because it looks like the host operating system doesn't make it a good thing. Really, the most successful programs are skinnable and look nothing like the host OS. Winamp and Trillian are good examples on the windows side where massive amounts of people have adopted programs that don't look like windows. Also, I would say, gkrellm is a great example for Linux. Native GUI's aren't really all that good of a thing.
Don't be so afraid of Java. ISO/ANSI are independant companies for profit themselves. I fail to see the difference between them and the JCP. Java applets that I wrote as a student 6 years ago still work today, can you say the same for all of your C++ programs? Do they still compile? Do they still run in binary form? Yes to both on the Java side of things. The world is going to GC whether C/C++ wants to go or not. Micrsoft, IBM, SUN, Apple, and even Oracle know it.
Karma Clown
IIRC purify also doesn't guarantee to catch all oob accesses, so they probably use a similar technique.
--- Hindsight is 20/20, but walking backwards is not the answer.
OK, first, what we seem to agree on...
However:
The latter, IMO, is the more serious of the two. If an object holds a resource, then until it is destroyed, the resource is held. Even the best general-purpose garbage collectors you can find today do not guarantee a maximum time between an object becoming unreferenced and being cleaned up. This goes double for conservative GC, where the resource might not be freed until everything which looks like a pointer to the resource-holding object disappears.
So in summary: I'm a big fan of GC, but it doesn't solve all my problems, and that's especially true in C++.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Of course I'm not sure if there is any chance of this happening because it will break all the tools everybody is using now...
No offence, but if you need a 3rd party tool to check if the output of the compiler, which was produced after the compiler found that the input (your code) was correct, is correct, perhaps it's time to take a step back and think about a better solution that will fix what I call the 'weak spot' of C++: you have too many stuff to take care of, it backfires on you.
.NET and the Java platform, you'll see that there isn't a necessity for the overhead you have to program with C++, so there's also no need for tools like purify or valgrind.
Today, the software that's used to develop software should be there to help developers write solid code from the start without overhead, without the necessity to program the plumbing code which makes your program logic run in the first place.
Some people here have suggested that GC is a better solution than just feed your compiled binary to another tool in the chain of tools and I agree. When you look at
For solutions where C++ is the only way to go, it's probably a welcome addition to the set of tools to work with, but for C++ in general it isn't IMHO, it only shows where C++ should be improved, or better: where the RTE of C++ should be improved so these tools are obsolete in the future.
Never underestimate the relief of true separation of Religion and State.
Implementations are NOT good. Take the top compilers used today, (Intel's, MS VC++, GCC, Borland) and see how many programs compile on all of them! This is precisely why it's a failure. ISO/ANSI itself is a failure because there are relatively no standards that they have produced that have been followed such that code is portable.
/ 20 01/index.html :) At least it seems to be the only one that stuck. Besides, if the ANSI standard was so hard to implement, one could argue that the tools used to implement it where inferior. Just think about that one for a moment.
GC that isn't at least a compile time option (preferably a run-time option), is useless to those who actually need it. One spec implementation is worth a hundred good other implementations. Reasons: 1) Not tied to different licences. 2) All compilers will support it on all platforms. 3) It would actually be used where needed.
In the example that you site as a good place for native GUI's is the most ignorant arguement I've seen on slashdot to date. Not even Java promised that you wouldn't have to rewrite the GUI for PDA's. (Don't quote hype, find a trusted source where SUN claimed you could run the same code on a PDA) The GUI's are fundamentally different in that case. The look AND the feel of the program should be customizable by the user. That is the promise of Java's LNF. You can choose native if you want, but the LNF is seperate from the code, therefore, you don't have to rewrite the GUI to make it look or feel different. The user ultimately should decide how the program behaves. Any arguement to the contrary is ridiculous.
http://www.iso.ch/iso/en/aboutiso/annualreports
excuse me but I think the fact that they have a financial statement is enough proof that they are a for profit entity. Though ANSI is nonprofit, the only real spec they are known for is the one that causes my ls to be colorful
This loss of control as you would call it is what ensures that my program will run on ANY Java runtime environment. Can you say that your C/C++ code will compile on ANY C/C++ compiler??? Don't be so ignorant to ask SUN to destroy something good. They have a JCP that decides the fate of Java, and SUN makes sure that it is implemented properly or not at all. If SUN wasn't in control, C# would have been J++ and not a single thing SUN or the JCP would have done could have mattered. SUN has and is making it possible for open source implementations of Java to be certified. Have you not been reading the Apache-Sun conversations? Soon there will be free test suites for nonprofit and open source implementations of the Java specs. Not that you can't implement the spec all you want, you just can't say it's certified if it isn't. You can create uncertified open source java all day, Apache and JBoss has been doing it for years. You can derive it to be whatever you want. You just can't call it certified until it passes the tests. I only wished C/C++ was like that. That alone would be enough that I would still be using it. There's the difference that SUN sees between ISO/ANSI and the JCP.
C++ was a great technology and may be again someday and still has it's place, but that doesn't excuse your ignorance about the JCP/SUN.
Karma Clown
0wn3d!
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
It's an attempt by those who understand the languages to stop the propagation of the myth that they are somehow inherently related such that a comment about one necessarily applies to the other. The two languages look superficially similar, and indeed for some time C++ was almost a superset of C. However, idiomatically, they are used quite differently, and there are now significant features in each language that are absent in the other.
The vast majority of comments I see where someone writes "C/C++", they really mean one of "C" or "C++", and they are trying to arbitrarily extend an argument inappropriately using proof by hand-waving. It has been noted by many pedants who object to this use that writing "C/C++" is almost surely a sign that you don't know one or other, and so far, I have yet to see many people breaking that rule.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Valgrind is a program I run if I suspect a memory error, and maybe every half year just to feel safe. It is used a lot less than the debugger, as memory errors are far less common than logical errors, at least for me. But when I need valgrind, it is godsend.
And of course, the really cool thing about valgrind is that it takes no human time to use. You just type
in some terminal window, and go back to working on something else. No special compile or build options, or any manual intervention needed. When it is finished, maybe next day, you read the problem repport.Debugging problems that you're aware of is one thing, and yes I just print status messages to find that kind of problem most of the time too. Memory checkers are more useful for finding the kinds of bugs that you don't know are there. It's a sanity check, if you will. If you run one, and it doesn't find anything, all the better!
True, but searching freshmeat for "profiler" doesn't bring up your project. OProfile does show up, though, so I guess most people don't go any further.
If you're worried about threading/memory bugs, you rather want to compile ML or HASKELL to a blazingly fast 100% native-code binary, without ever using non-free software.
Java's type system still allows wrong type casts, which can only be checked at runtime, and this gives essentially memory bugs. I wish Java had a better type system with proper polymorphism (like Generic Java) instead of these ugly casts to Object and back...
I said nothing of the sort. I have tried many debuggers, and the reason that I debug with print statements is that it works. I do a lot of parallel and distributed programming; I don't make a lot of elementary mistakes when I program.
Please stop jumping to conclusions so quickly.
Yes, it was. And do you know how long ago that was, and how much the languages have both changed since then?
Those who are familiar with one often think they're familiar with the other, and draw false conclusions based on assumptions of similarity. This is exactly the reason why people who are genuinely familiar with both languages often dislike the use of "C/C++".
Sorry, but I don't think the term "C/C++" is useful in any of those situations. If you have skills in C and/or C++, say so. Writing "C/C++" suggests that you've learned some hybrid out of a Schildt book and don't actually know the difference. As for making arguments comparing "C/C++" with Java, I'm afraid that's just silly. C, C++ and Java have syntactic similarities, but C and C++ are no more similar than C and Java or C++ and Java.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I agree. Perhaps let developers perform compiles on a very fast remote box, but make them use and test the system on a computer that is the "minimum recommended". If they can't do it, the stated minimums are wrong.
The good PHBs don't. In fact, I judge (with considerable accuracy so far, I might add) the competence of those who interview me for jobs based on precisely this sort of detail. If I come across a company where the staff conducting a technical interview or running the projects don't know the difference (or -- another favourite -- think JavaScript and Java are somehow the same thing), I run away as fast as I can.
And in response to your other reply...
No, I'm an experienced programmer with knowledge of all three and a different opinion. Calling me names won't change that.
C is fundamentally a procedural language. While it can host OO and generic programming approaches, it provides no particular support for them. OTOH, for the low-level bit-twiddling approach, there's nothing to beat it. It is very much characterised by the use of compact, precise code.
Java is the equivalent but for OO: it can do procedural and (when the generics finally arrive in routine use) generic, but OO is its only real forte. The emphasis in typical Java programming -- though this is probably more to do with what it's used for than any inherent limitation in the language -- is much more in stringing together bits of the vast standard library it ships with than in low-level bit-twiddling.
C++ can surely do procedural or OO, but at its best it is characterised by the use of complementary procedural and OO approaches, with generics allowing some very helpful techniques in supporting that mix.
To me, these languages have obvious parallels in syntax, but in style, they are all worlds apart. What is it that you think is more similar in C and C++ than the links between C and Java or C++ and Java?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I guess the thing is that you're looking at the programming and run-time environment, where clearly Java is very different to any completely compiled language, whereas I'm looking at the programming style, where C, C++ and Java are all quite different.
To me as a developer, the former might sway my decision about which language to use, but is otherwise irrelevant; I could take a C++ guy familiar with classes and OO design, teach him Java's minor syntactic differences and let him go, and he'd be producing results. Of course, the difference between that guy and a skilled Java programmer is (mostly) the latter's knowledge of a few Java idioms and its standard library.
In contrast, you cannot take a good C programmer, show him a couple of minor syntactic changes and a command-line switch, and turn him into a good C++ programmer. The difference in programming idioms -- whole paradigms, even -- is much greater. OTOH, of course, C++ inherits much of C's standard library, and he could continue to use that until he was up to speed with the C++ equivalents, and when to use each.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.