If you want proper C++ schlaging, here it is, done right:

C++ Frequently Questioned Answers: http://yosefk.com/c++fqa/

We now returned to your regularly scheduled uninformed language rants.

Most plain C projects are reinventing the wheel many times. Linked lists, hashtables, reference counting, OO with function pointers. I'm sure those projects shrink at least 33% in size when they would be using STL or Boost. I've certainly seen that in my own code.

I suspect most of the distaste for C++ is a hang-over from another era. People had some exposure to MFC programming or old compilers with horrible STL support and that formed the popular impression of C++. Modern C++, especially with boost, is a very good language.

http://yosefk.com/c++fqa/defective.html#defect-2

(Note: I use and like C++ for a lot of things, but there is a lot of valid criticism of it and the FQL rants are at least well-informed.)

However, it's still generally my language of choice, and not only because it's the language I know most. It has the flexibility of C while providing some OO capabilities and the STL. And there is the widespread availability too (although that's not really C++'s honour but GCC's).

One could also argue that C++ software is easier to deploy, as it needs no VMs or interpreters, but it's quite a moot point because every moderately sized application will have 3rd party dependencies to provide everything the STL is lacking.

Also, the RAII idiom is perhaps my favorite pattern, and I'm yet to see a language that has RAII support as strong as C++ has. (Although I do plan to have further investigations about Python 3k/2.5's 'with' statement, it seems to be a good contender) I rely heavily on RAII while coding/desinging, this makes coding in Java very sour for me. And Ruby's block idiom, while it's really lovely and comes very handy in many cases, it ain't no RAII.

Like it or not, while it's slowly fading away, C++ will still be around for a while. I don't really see KDE rewritten in any other language any time soon.

Yes, there are other resources to manage. Python's with and Common Lisp's unwind-protect are both good for open file handles and the like. unwind-protect is better than with and with is better than constructor/destructor because constructor/destructor and to a lesser extent with require too many contortions to use.

For every complex problem there is a simple solution... and it is wrong.

---> "So, to answer your question about how many wizards C++ has ruined, I can argue that I never bothered to go further in programming due to feeling utterly lost with C++ and Perl." ;-))

However, one comment is worth discussion: "There is no reason to use C++ for new projects."

Do you agree with this? What is a better choice then for developing standalone apps or libraries where speed is critical? It's funny to watch how some people bash c++, and then, when we need to develop some critical app, like javascript engine, suddenly the choice is again C++. ;-)

There's a strange disease among modern application programmers where they seem not to be able to "see C" even when it's driving the very engines of their success. If you just look a tiny bit more deeply, you'll discover that it's not nearly as hard as you think it is.

Mostly ignorance of the rant authors :) In fact, one way to view C++ is as a beefed up C. Specifically a moderate use of the following simplifies life quite a bit and retains almost all benefits of C -

* templates instead of macros

* pure classes for the callbacks instead of function pointers with void pointer contexts

* standard inline functions

* STL containers (not perfect from memory utilization and perspective, but typically are ok)

Exceptions can also come handy, but these require a lot of moderation if used in a fastpath code.

Everything you've mentioned has crashed on me from time to time due to memory allocation errors. C is not a great langauge. It is assembly langauge with sugary syntax for loops, and a preprocessor that whines if you try to add a double and an integer.

The advantage is speed. The disadvantage is that programs written in C are only correct due to luck.

Oh, and the reason all of the above are written in C is because there is a common misconception that you have to write "system software" in C. You don't but people think you do. So they do.

And I'll be frank: the hubris in your discounting the programming skills and choices of all of those working, mature, robust and very successful projects is just absolutely stunning. Have you ever delivered anything of comparable quality? Until you have, please don't condescend to tell Guido or Linus or Larry how to write their code. I'll submit that these projects are written in C because their rather talented authors see something in that environment that you don't. And that the fact that you don't see value in an environment that is undeniably producing valuable software says more about you than it does about them.

Seriously dude, you gotta check that attitude.

You were the one who brought up C. But basically, all languages that require manual memory management fall into the category of "you probably shouldn't use them". Memory management is too hard for people to get right. Computers are much better at that tedious task. (As an aside, it is interesting that it's easier to write a generic memory manager than to remember to do it right every time yourself. Programming is an interesting art.)

Until you have, please don't condescend to tell Guido or Linus or Larry how to write their code.

Honestly, this is a bad example. When Python and Perl were started, there was no other option for writing a language that would run on UNIX. UNIX software was written in either C or shell. Now that Perl and Python exist, they are much better choices than C for almost any class of problem. That's why they were written. If Guido and Larry actually wanted to use C for everything, they wouldn't have needed to write their own languages.

BTW, the Perl6 implementation written with Haskell came together in about a weekend, while the C implementation is about as complete after 5-or-so years. C is a pain.

Finally, I find it condescending that you want to throw away the last 40 years of programming language research because UNIX is written in C. Remember the Lisp machines? It's a shame that UNIX lost out to them, because it was much easier to write software (and libraries) in Lisp than in C. Oh well, at least we have emacs.

C has its purpose, but its purpose is not for writing programming languages, web servers, or desktop applications.

OCaml might be better in academic sense as the language itself, but now I talk about commercial product...so you would need to take all factors of software development into consideration - like how you will find future developers if you expand, what the support will be, etc. etc.

"What if your manager is paid by Sun to only advocate Java?" There's no way to argue that, but it doesn't matter, because it's irrelevant.

Pick the langauge you want to use.

I can't, because I am just one worker and the language is choosen by the top product manager. That's not a complaint, my point was that you usually can not choose a language you want to use in professional setting. You can do so for your hobby project.

The hard part is writing and compiling it. The syntax is bad, the language features are easy to misuse, and the compilers are slow and don't give good error messages.

But the main reason to hate C++ is because allocating your own memory and figuring out what type variables have is a job for the computer, not for the programmer.