I'm currently implementing a complicated algorithm in C++. I don't have to use many language features for that, so I don't have a strong oppinion about them.
But what I can say is that, compared to Java, the tools for C++ coding suck. Hard. In Eclipse you can write some gibberish and it automatically turns it into valid Java that mostly does what you want. The Java debugger is excellent and works without hickups. The experience you have with Eclipse and CDT just isn't the same. No automatic inclusion of header files, autocompletion doesn't always do what you want, no documentation included, even for the STL. Working with gdb is painful, most of the time it is not possible to properly inspect datastructures in memory and it is generally just easier to litter the code with print statements.
Part of the tools issue arises because C++ insanely hard to parse (the preprocessor makes it even harder); recovering programmer intention from something that is "almost" C++ is an exercise in futility. This is, I think, a genuine problem with the language. There are of course good arguments in the "Java wouldn't need such good tools if it was a better language" camp; best of both worlds would be a language that's easy to write tools for but doesn't really need them.
With regard to debugging, I think you're being unrealistic. You're comparing debugging on a fully introspective and managed virtual machine to debugging annotated assembly language. Apples & oranges. If a fully managed VM meets your needs, then use it. If it doesn't, well, welcome to low level programming.
You also make it sound worse than it is; JVM debuggers aren't perfect either: they debug Java-the-language fine, but other JVM languages are more problematic. Good luck with JNI, too. Likewise, there are C++ debuggers which are STL-aware, and even those that aren't can usually be coaxed into displaying pointers as arrays or as supertype pointers. Using gdb directly is rarely necessary; there are perfectly decent frontends. If you're having problems because you're trying to debug compiler-optimised C++, then you're simply running into the limits of the platform. Debugging post-JIT Java is no fun either.
Can you name some "better than gdb" debuggers. I'm pretty frustrated with gdb, but all the alternatives I tried in the past have sucked as hard or more than gdb.
On Unix systems, you usually still want to use gdb, just with a Frontend. On Mac OS X, this will usually be XCode, on KDE I like to use kdbg. There is ddd, too, which is ugly as hell but works well.
On Windows you probably can't beat Visual Studio.
I'm currently having to use pure gdb to debug some Mac OS X kernel code, and I feel your pain. Using a frontend is much nicer.
In Eclipse you can write some gibberish and it automatically turns
it into valid Java that mostly does what you want.
Isn't this the reason that many treat java programmers as suspect ? I think IDEs are fine once you have mastered the language and the syntax, but it often masks the gaps and deficiencies in one's own knowledge. I find that a bit scary.
I understand that mine would be a minority view. Guess work at the IDE together with TDD has significant fan following. Apparently it gets the job done, if that be so, who am I to complain.
No, I don't think this is a valid reason - in fact, I think it's a prejudice which disguises an ignorance of why languages with productive IDEs are so good.
An IDE with code completion means you can get more done without having to waste time studying API docs; in fact, the IDE's editor can itself become the most efficient doc lookup tool. This gives you more time and attention space to point at your problem domain, rather than mere incidental details.
Object orientation with static typing is a big contributor to this, because you start out with what you want to act on - the noun, which is usually a local variable or field - and get completion on the actions available on that noun. The contrast with functional and procedural styles is stark: there, you need to know the symbolic name of what you want to do to something you already have in hand, but editor completion is almost powerless to help you, because of the order of tokens in the syntax.
Statically typed "pure" functional languages have somewhat different tradeoffs when it comes to looking up functions; the style of code completion common in OO languages doesn't work, but because the type of a function encodes so much more meaning about what the function does, you are often able to find the function you are looking for just by giving its type to a tool like Haskell's Hoogle. This is less automatic, but it enables you to search a large array of libraries simultaneously, which is very helpful when you don't know what library contains the function in question!
I think C# really exhibits this. Almost everyone starts (and stays with) Visual Studio, which has extensive auto-completion, meaning if you ever use a plain text editor, it's startling how little of the library you have in your fingertips.
I don't know about the connection with Java coders being suspect - I would have suspicions of anyone who's never stepped off a VM into an actual machine.
I don't care for IDEs either: the farthest I get is my emacs textual expansion.
Eclipse and CDT for C++ coding sucks. However this doesn't mean there aren't any good tools. Both Visual Studio and XCode are very good for working with C++.
The best IDE i was able to find for C++ on linux is Qt Creator. Its only drawback is that it's quite Qt integrated, but with very few tweaks you can make regular C++ projects with no Qt dependencies.
Everything from the debugger to the code completion does work well, which is more you can say about most C++ IDE on linux.
The current Qt Creator (or I think its beta version) really has the best available C++ syntax support (which has direct impact on stuff like auto completion) I have ever seen so far.
The second best I have seen was in KDevelop (when configured correctly -- I remember it only worked correctly when you pre parsed the STL library).
I am also very excited about the clang development. It was developed in a way that it should be very easy to integrate it (or parts of it) in an IDE. Xcode4 will do that. And others probably will follow at some point.
I recently came back to C++ after many years. I spent days trying to set up a good environment with vim, then I tried with jedit http://humbertook.blogspot.com/2010/11/personal-preferences-...
, Finally I started using Qt Creator. It is not as good as Eclipse, but it is a big improvement over vim; specially, if you are already using QT.
Try KDevelop 4. Its semantic highlighting is really awesome. And most importantly it doesn't get in your way. Unlike Eclipse or even Qt Creator which I find frustrating to work with.
Whilst I couldn't find a way to automatically include header files, once they're added NetBeans automagically switches on autocomplete and finds documentation where available. I've used it for my own C++ projects (using headers and libraries from others as well as my own) and had no problem. I'm by no means an expert (used C++ for only a few months, coming from a PHP background) but I managed to get a few CGI applications working using Xerces-c
(I'm gonna get reamed for this, but...) Visual Studio is great and with the proper setup can do all of that and more. Obviously it's Windows only, so that may be a problem.
Frankly, I think much of people's hatred against C++ is the relative lack of good tools on non-Windows platforms.
But what I can say is that, compared to Java, the tools for C++ coding suck. Hard. In Eclipse you can write some gibberish and it automatically turns it into valid Java that mostly does what you want. The Java debugger is excellent and works without hickups. The experience you have with Eclipse and CDT just isn't the same. No automatic inclusion of header files, autocompletion doesn't always do what you want, no documentation included, even for the STL. Working with gdb is painful, most of the time it is not possible to properly inspect datastructures in memory and it is generally just easier to litter the code with print statements.