Please don't believe people that say C++ is bad. Often those people compare C++ to languages that aim to solve different problems than C++.

C++ follows the don't pay for things you don't need philosophy. It's therefore inappropriate to compare C++ to Java or C# which target simplicity and flexibility (think about reflection, for instance).

The point of C++ over C is that C++ allows you to take the advantages of object orientation and the power of generic programming to build cleaner and more concise code than you would do in C (In my opinion. Of course many C programmer think otherwise. But that's life). But it won't protect you from shooting yourself in the foot. Maybe that is what the aforementioned people don't like. One doesn't know.

In trying to do what it does, C++ has become quite confusing in some areas and intricate. So it still makes sense for programmers to just stick to plain C, if they don't feel like learning C++ while they are quite comfortable with C.

Believing there is a reason for the majority of undefined behavior cases, let's look at some others answers undefined behavior cases, and try to explain reasons.

// information about size lost, because we care about the lost size and performance
int* p = new int[10];  
int* p0 = p + 11; // undefined behavior, because information of size is lost, 
                  // we can't test.
int* p1 = p - 1; // Undefined behavior, again for the same reason.
int i = 0;
// undefined behavior. I don't know why they haven't forced the implementation to 
// give a diagnostic. Beyond me. Recent gcc versions warn (at least) anyway.
cout << i++ << " is less than " << ++i << endl;
// not undefined behavior, but the result of the cast is unspecified. This is
// so that if one knows the behavior of an implementation, one can provide optimized
// code running faster by doing that pointer conversion. The Standard say for a
// similar reinterpret_cast case: "It is intended to be unsurprising to those 
// who know the addressing structure of the underlying machine."
cout << reinterpret_cast<float*>(p); // undefined behavior
const int c = 42;
const int& r = c;
// just casting away const is not undefined. but writing to an const
// object is undefined behavior. still, no space and performance is lost by
// storing information about the constness of the object somewhere 
// (which would require runtime type information)
const_cast<int&>(c) = 43; // undefined behavior
// same argument: we don't want to do a check for overlapping region, and
// we want to keep being compatible with C. Maximal performance, minimal safety.
memcpy(p, p+1, 9); // undefined behavior, overlap

C++ is a systems programming language. That is, it is especially suited to writing operating systems (sometimes even drivers, with certain constraints) and anything that has similar requirements to an operating system - very direct control over performance-sensitive characteristics, absolute parsimony in use of memory or CPU cycles.

For that purpose, C++ is the best thing there is. There are people who claim C is better because it's simpler - the Linux kernel folks for example. Looking at how you allocate a dynamic array of structs in C vs the equivalent std::vector declaration in C++ makes me doubt that claim. C++ provides some complex tools which can be used by library designers to make life simpler for systems programmers.

But... so much for systems programming. C++ is, today, an inappropriate tool for general purpose application programming. I used it for that purpose for over a decade. I never want to go back to it. It just doesn't make any sense. In general purpose development, the number one rule is do not optimise prematurely. The whole philosophy of C++ is based on microscopic optimisation at every opportunity, before you have any evidence that its worthwhile. It's a recipe for painful, difficult labour with no actual economic benefit.

The irony is that it frequently ends up being slower than Java or C# as a result of these basic assumptions.

The std::string class was originally intended to support copy-on-write semantics. This means that when one string is assigned to another, the two objects share the same buffer, until one of them modifies it, at which point they stop sharing. This all happens behind the scenes to speed up your program. Then vendors realised that they needed to make it thread-safe, a subject the C++ standard was silent on at the time. So they put locking into the string class. This made it perform appallingly on multi-core machines, so they took out the copy-on-write optimisation. Back to slow copying! Meanwhile the need for copy-on-write doesn't even arise in Java and the CLR because they use immutable string objects directly accessed by references, providing inherent thread safety.

A similar situation exists now with boost's shared_ptr, now part of the language standard. It has to use interlocked operations to increment and decrement reference counts. This has a high cost on multi-core machines, and the world is going multi-core in a big way. It's a half-hearted attempt to provide something akin to GC, but it will never be able to compete with the real thing, and it's only going to get worse as multi-core scaling becomes vital.

For widely-used rich client applications, you need to write Windows applications. The ideal platform is the CLR, which provides a vast ecosystem of libraries, plus the language of your choice, the two major choices today being C# and VB. Both are fine, with C# appealing the most to people like me because yield return is the Awesomest Thing Ever. Or you can use Java - it has suffered over the years from horrible support for GUIs and a language enhancement process that is slower than molasses, and yet it is still better for developing desktop applications than C++.

For server-side apps, you are typically not writing "system" code. The most popular websites in the world are hardly ever written in C++, although the bare-metal HTTP server may have been. They are often written in dynamic languages like PHP, although Java has made some headway and ASP.NET isn't unheard of (this site, for instance).

There was a brave attempt by the chair of the C++ standards committee Herb Sutter to develop a huge set of extensions to C++ known as C++/CLI, designed to ensure that C++ was a true CLR-enabled language. But the extensions were so rich and complex that the result was really a completely new language that inherited all the complexity of C++ as well. And it is only used in practice to help with interfacing between old C++ code and new CLR code, not for general development; consequently it is a tad over-engineered.

So there you have it. If you're writing an OS or something that routes packets on a network, the raw plumbing, as it were, C++ is the best thing there is.

But let's face it, you're probably not doing that.

Your question is difficult to answer because for most programmers, the problem with C++ is the whole of the language, not individual pitfalls. Bjarne Stroustrup is on record as saying that he started "C with classes" because of a bad experience using Simula-67 and not being able to control the costs of memory management. So minor pitfall #1:

• Many programmers think that with today's hardware and today's garbage collectors, the potential gain from explicit memory management is not worth the potential for introducing bugs. Please note that explicit memory management is not always faster; years ago Ben Zorn did a great study on the costs of conservative garbage collection in C and C++ programs. (I don't know why memory management engenders such passion, but it does.)

Another reason programmers dislike C++ is its complexity. Poster child for complexity: templates. When templates were first introduced, some compilers got them wrong, and almost all compilers had wildly inefficient implementations. I worked with people from Stanford who had "templatized" their code and an application that used to build in an hour would not build in a day. When this happens to programmers, they stay angry for a long time.

Another poster child for complexity: the language spec was always changing and the compilers were always behind. It's really infuriating to plan on using an alleged feature and then find out it's not supported, or that it appears to be supported but does not perform well enough to be useful. In the early days of C++, this happened a lot. Eventually the community stabilized on just two implementations: free software uses GNU C++ and commercial software uses the excellent front end ^[1] developed by the Edison Design Group.

When almost nobody can implement a language successfully, that's a sign of a bad design. Programmers who have been burned remember, and in this case they rightly blame the language, not the compiler writers.

Another big reason that some programmers dislike C++ is that its design lacks intellectual coherence. C++ is a collection of features that were tacked on to C with only two criteria: somebody thought it was useful and if you don't use it you don't pay for it. This procedure is a recipe for a language in which the parts do not work together to form a harmonious whole. This is one reason people find the language difficult to learn. To learn more about the process by which C++ came about, check out Jim Waldo's excellent book on the evolution of C++ ^[2]. Waldo's book will give you a more balanced view than any of Stroustrup's apologia.

To sum up, the major problems people have with C++ are largely not individual pitfalls but rather

• Early implementations didn't do what they said on the tin, and some programmers are still angry.

• The language features don't fit together and the totality of the result is so very complicated that nobody can master it all. (Some C++ shops have fights over what subset to use.)

DISCLAIMER: litb has made some very good points in the comments to this answer. C++ should not be compared to python or C#. They're targeted at different areas of work. C++ is very well suited for the things it is used for. C# is very well suited for the things that is used for. Neither language can be considered "obsolete" or "inefficient" at the things they're meant to do. However, people who make statements like "C++ is obsolete and inefficient" usually try to make this comparison, to prove that C++ is not suitable for modern applications development. As litb said, this isn't a very meaningful comparison, but people still try to make it. So this post will do the same, to look at how C++ compares to languages like Java, C# or Python. Modern high-level RAD-like languages on their own home turf. In other areas (systems programming, low-level stuff on embedded devices and so on), C++ stands practically unrivalled (well, C and C++ does), there can be no doubt of that. But for high level business programming, C++ lacks a lot of niceties that other languages provide.

The problem is that nearly everything is a pitfall. It's a very versatile and powerful language, but it also lets you shoot yourself in the foot in hundreds of subtle ways that more "modern" languages don't allow.

About being outdated, the language lacks a ton of modern facilities. Look at the .NET class library, or Python's standard library. Both offer a huge set of functionality for pretty much anything you'd ever need. C++ has.... A few streams and a few container classes. (Yes, that's a bit of an exaggeration) Other languages have garbage collection to free the developer from worrying about memory management, C++ doesn't. So in many ways, C++ is outdated. It's missing a lot of tools that more modern languages have. But of course not in every way, and there are areas where C++ is the best tool we have.

C++ being stupid? Most definitely. There are a couple of notable blunders in the standard, such as std::vector<bool> doesn't behave as a vector, the export template keyword that virtually no compiler supports and a few others. The syntax is so complicated as to be almost impossible for a compiler to parse. Compile-times can grow to be huge because of this. The compilation model is nothing short of archaic (header files? Come on, we don't live in the 70's)But more importantly, writing correct C++ code is just ridiculously hard, because many instances of things that look harmless and compile without a warning actually rely on undefined behavior. The following are all examples of undefined behavior. They compile just fine, and they might usually work, but they may also format your harddrive, set fire to your computer, print all your porn to the office printer, or crash the program:

int* p = new int[10];
int* p0 
int* p0 = p + 11; // undefined behavior, pointer out of range
int* p1 = p - 1; // Undefined behavior, as above
int i = 0;
cout << i++ << ++i << endl; // undefined behavior, may not modify variable multiple times between the same sequence points
cout << reinterpret_cast<float*>(p); // The result of the cast is unspecified *except* tht if you cast it back to int*, you get the original value
const int c = 42;
const int& r = c;
const_cast<int&>(c) = 43; // undefined behavior // casting away constness from a variable that was initially const is undefined.
memcpy(p, p+1, 9); // undefined behavior, memcpy between overlapping memory

And of course many many more (and much more subtle) issues exist.

As for being inefficient, people often say that C++ is extremely efficient. And it is. I can't think of a better language for high-performance code. It beats C in many cases, and while Fortran may be a bit faster for purely numerical tasks, that gap has almost been eliminated by clever use of template metaprogramming and expression templates. C++ is damn fast. But again, only if you use it correctly. It is very easy to write inefficient C++ code, whereas something like C# is reasonably efficient no matter what you throw at it. To illustrate, check out this series of blog posts: http://blogs.msdn.com/ricom/archive/2005/05/10/performance-quiz-6-chinese-english-dictionary-reader.aspx

Two high-profile Microsoft bloggers competing to write the fastest version of a simple program, in C++ and C# respectively. The C++ version ultimately wins, but only after a huge amount of extra work, and a few extra bug creeping in. In almost every iteration until then, C# keeps pace easily. Apart from that, it's an enlightening and entertaining read. Check it out.

Anyway, by asking what the pitfalls of C++ are, you're really looking at it the wrong way. By default, assume everything in C++ is a pitfall. Only trust code that has been verified against the standard. And of course, that makes it virtually impossible to trust your code if you're not already a C++ expert. ;) The best advice I can give to avoid the pitfalls is to really try to learn the language. Read the C++ questions here on SE, get a copy of the standard (and get some practice in looking things up in it. It's not an easy read), buy a book like the annotated reference and so on.

And no, if anything, being a (good) C++ programmer might make you look impressive in the eyes of others, simply because getting good at C++ is a huge undertaking.

Overall, there are good reasons why C++ can be considered all these things you mentioned. But not in every case, and overall, the language has some unique strengths that no other language has so far duplicated.

Edit Oops, looks like I angered the One-True-Language Brigade. Perhaps you should actually read my answer before saying that "virtually nothing in it is correct". All I do is list a bunch of facts. The C++ standard library is missing many everyday features that .NET provides. Where's my threading library? Sockets? Regex? And the things I listed are undefined behavior. Rico Mariani and Raymond Chen are high profile MS bloggers, and Mariani in particular is one of MS's performance gurus. And they did make a series of blog posts demonstrating the relative performance of C++ and C#, and the outcome was what I said. Those things are simple facts. And if you don't think vector<bool> is stupid, I'd really like to hear your reasoning.

I'm sorry if I angered anyone who only knows one language, and feels that therefore it must be perfect. But C++ is not perfect. I like the language, but I don't have any illusions that it's perfect, or that it doesn't lack a lot of modern conveniences.

What's wrong with C++ is its syntax. Very, very wrong. For some good and other not so good reasons the syntax is completely contorted, complicated, unreadable and in a few cases downright ambiguous. Of course the standard clears these ambiguities but the rules are (seemingly) arbitrary and these cases should have been prevented in the first place.

I'll give two examples which I find classical and which illustrate the core issue.

First, templates. (Unintentionally) introducing a Turing complete language that executes at compile-time was both a stroke of genius and madness, since it allows very complex expressions. Consider:

/* 1 */ a <  (b) > (c)  > (d);
/* 2 */ a < ((b) > (c)) > (d);

What does this do ^[1]? Notice that both are well-defined C++ with two definite meanings (for matching types/variables a…d).

More generally, I've got a bone to pick with the C++ committee for their design of declarations and definitions. A bumbling band of baboons couldn't have done worse. (And with all due respect, I stand by this statement!)

Consider the following list. Try to know/guess for each line what it does.

1. a b;
2. a (b);
3. (a) b;
4. (a) (b);
5. (a b);
6. (a (b));
7. a b(0);
8. a b();
9. a b[];
10. a b = a();
11. (a *) (b);
12. (a) * (b);
13. (a) (* b);
14. a (* b)();
15. a b(c);
16. a b((c));

This is madness!? No, this is C++!

Note that these codes have got different meanings depending on whether a is a type or a variable! Let's take a look … I've replaced a with the type int for clarification.

1. int b: Declares the variable b to be of type int.
2. Two possibilities:
   1. int (b): Performs a function-style cast from b to type int.
   2. var (b): Calls operator () on object a and passes argument b.
3. (int) b: Performs a C-style cast from b to int. This is equivalent in all but name to the function-style cast. Notice that this is true even for non-POD when the constructor is called.
4. (a) (b): Two possibilities; like 2.2 and 3, respectively.
5. (a b): Syntax error.
6. (var (b)): Like 2.2.
7. int b(0): Defines the variable b of type int with the value 0.
8. int b(): Declares the function b of prototype int (void).
9. int b[]: Declares the variable b of type int[] (i.e. array of int).
10. int b = int(): Defines the variable b of type int and assigns it the value 0. For a that are POD, this call emulates the default constructor syntax.
11. (int *) b: Performs a C-style cast from b to int*.
12. Two possibilities:
    1. (a) * (b): Multiplies a with b. Duh.
    2. (int) * (b): Performs a C-style cast from *b to int.
13. (int) (* b): Ditto.
14. int (* b)(): Declares the variable b of type “pointer to function with prototype int (*)(void)”.
15. int b(c): Declares the function b of prototype int (c) (and here, c is interpreted as a type, never as a variable, even if there is no such type).
16. int b((c)): Defines the variable b of type int and assigns it the value of c. More generally, this calls the constructor passing one argument (c).

Notice in particular how sometimes parentheses have got a meaning while being optional at other times. In case 16, the inner parentheses look completely redundant even for professional C++ programmers: in order to disambiguate between types and variables, variables may always be wrapped redundant parentheses, while types may not. This is the reason for the completely different semantics of statements 15 and 16.

And this doesn't even touch on arcane matters like macros, trigraphs or templates. These are all plain vanilla statements/expressions that might be found in any old code.

By the way, the above also gives ammunition why C-style casts should, always, ever be avoided in favour of the more verbose new style C++ casts.

As others have said, C++ IS REALLY HARD TO LEARN. More than that, it's a two-stage learning. First, you have to learn all the language features. Second, you have to learn how to use them wisely. Most people never get to the second stage, and hate the language forever.

But in many cases, though, it's "religious" hatred. This is particularly common between some Java programmers I know, which believe Java came to replace all the other languages, is better than them, and C++ in particular (for some reason) is the major evil. They don't state this directly, of course, but it's not hard to get it.

I love C++ and do most of my job in it, but also feel having to mention that C++ does have many flaws in its design, though, so much that there's a book about it, Imperfect C++ ^[1]:

None of them, of course, should be reason to thrash it (therefore the book). But also none of its strengths should be the reason to use it when another language is a better choice. I, for instance, would always consider Java, Ruby, PHP, etc. as a better choice for a website backend than C++. To automate simple tasks, I'd go for scripting languages... and so on.

According to Linus Torvalds, " C++ is a horrible language ^[1]".

Yet again, Steven Dewhurst ^[2]'s response ^[3] to his critisicm.

I think it's only fair to point out that Linus' diatribe is more than a year old, and he has spoken in more measured and printable tones elsewhere about the same subject. Less excusable, however, is that he makes the claim that C++ cannot be used in resource-constrained areas with nothing but anecdotal evidence to support his claim. Linus has done good work and has earned his soap box, but he also has a professional obligation to make sense while he’s holding forth. (For those who follow such things, this is an instance of Gotcha Chapter 12, “Adolescent Behavior,” from C++ Gotchas.)

The argument that abstraction and efficiency are mutually-exclusive or that they're mutually exclusive in the context of C++ is demonstrably false. Lately, much of my work involves writing embedded code in C++ with heavy use of inheritance and templates, and the results have been more than promising. The resultant code is typically smaller and faster than the equivalent (well-written) C code provided by the board's manufacturer, and has the significant advantage of being usable by a developer who is not expert in the minutia of the board's design. Unlike Linus, I haven't written a commercial OS, but I have written a policy-based, pre-emptive tasker in C++. It occupies just 3k of RAM and is pretty zippy in addition to being easy to understand, customize, and maintain. Just to annoy people like Linus, I've also used typelist meta-algorithms to generate exception handlers with identical efficiency to hand-coded C. In a number of recent talks given at the Embedded Systems conferences, I've shown that commonly-criticized C++ language features can significantly outperform the C analogs. As an old-school, Bell Labs C hacker I've nothing against C. But C++ provides tools and capabilities that are hard to come by in C, and often make it easier for a competent C++ programmer to produce cleaner and typically smaller and faster code than the C equivalent.

Regarding competence, Linus’s implied argument that C++ attracts bad programmers the way other things attract flies is, in spite of the effective metaphor, both unfair and a little over the top. Inexperienced or incompetent programmers have been lured into writing bad code in other languages as well; I've inherited my share of poorly designed and rendered C. There's no question that C++ is a significantly larger and more complex language than C, and a competent C++ programmer should be familiar with many more design styles (including, among others, that "idiotic 'object model' crap") than a competent C programmer. Wider experience with different design approaches and coding idioms is an advantage if the programmer actually has more than a passing understanding of the techniques. Problems typically arise when teams of competent C programmers are thrown onto a C++ project without adequate preparation simply because C++ syntax looks something like C syntax. The results are usually about the same as you’d get by throwing the same team into a COBOL project. But you’re not going to catch me criticizing COBOL. That’s Linus’s job.

I use C++, instead of C, because I like having classes as first class objects.

I like C++ because I can call anything I want written in Fortran, C, and C++.

I love static typing.

I appreciate it's undefined behavior, because it allows optimization opportunities for the compiler.

Resource Acquisition is Initialization (RAII) is your friend.

You are listening to the wrong people. C++ is optimized for certain applications, but is not so good for others. Use the right tool for the right job.

I don't think you should take anyone that says C/C++ is "outdated/stupid/inefficient/whatever" too seriously.

It's true that a lot of people may be using higher level languages for certain tasks these days, but it really depends on what you are doing. In many situations C is the best and right tool for the job.

I'd also suggest that learning lower-level languages like C is a great foundation for becoming a better programmer. You're working closer to the CPU, and understanding more about how processes evolve on a machine. This kind of knowledge will improve your understanding and give you an advantage when it comes to designing systems and architectures, even in higher-level languages.

C++ is hard to learn and that's why some people hate it. I like it because it lets me do my job and does not hold my hand. If I screw something up, there is only one person to blame for it - me.

I could write an long rant, but it amazes me this question comes up so much as it does.

There is nothing wrong with C++, it's only in the programmers head :).

As for it being outdated... If you're using Firefox or Google's Chrome to view this page, you using an app written in C++.

The main pitfall of C++ is it makes you read and understand before you go and start to hack together a program. There are many ways to learn C++ and to implement C++, that perhaps, is one confusing aspect of C++. Once you have the language semantics down, the rest is just following them to complete your task.

Pitfall: It doesn't have a very fashionable garbage collector!

Cause: RAII

Alternatives: manually call dispose() or close() methods through your code, or scatter every scope block with the using() equivalent. Alternatively force a GC collection regularly, or wait paitently for the GC to kick in and finalise your object.

:-)

I find C++ FQA Lite ^[1] to be a good compilation of problems with C++.

Speaking as a C++ fan, here's what I see as problems.

First, the language is complicated. There's a lot to learn, and implementors are often slow to add new standard features. The cause is that the language evolved rather than was planned out, and languages like Java were more planned.

Second, there's no central big library. This is probably due to the Unix philosophy of offering a lot of choices, so there's plenty of different libraries here and there. This contrasts to Java's huge standard library, and Perl's CPAN.

Third, people tend to learn the wrong things first. In this list, and the Frequently Questioned Answers rant, people complain about things that can be easily managed with standard strings, smart pointers, container templates, namespaces, etc. This is partly due to the size of the language, which makes it hard to learn everything fast, and the history which makes people usually learn the more C-like parts first. Other languages (Perl excepted) tend to have more standard ways of doing things.

Fourth, programming well with C++ requires more skill and knowledge than other languages. Stroustrup designed it to be usable for almost anything, and its evolving nature means that you have to know more to use C++ safely than most other languages. There are more recent languages that cut off the complications (pointer arithmetic, multiple inheritance), and concentrate more on making the language safer to use at the expense of some expressiveness the designers don't like.

Best description of C++ I have ever read was from Steve Yegge's Tour de Babel ^[1]. I also really love his description of Perl from the same article

C++ C++ is the dumbest language on earth, in the very real sense of being the least sentient. It doesn't know about itself. It is not introspective. Neither is C, but C isn't "Object-Oriented", and object orientation is in no small measure about making your programs know about themselves. Objects are actors. So OO languages need to have runtime reflection and typing. C++ doesn't, not really, not that you'd ever use.

As for C: it's so easy to write a C compiler that you can build tools on top of C that act like introspection. C++, on the other hand, is essentially un-parseable, so if you want to write smart tools that can, for example, tell you the signatures of your virtual functions, or refactor your code for you, you're stuck using someone else's toolset, since you sure as heck aren't gonna parse it. And all the toolsets for parsing C++ out there just plain suck.

C++ is dumb, and you can't write smart systems in a dumb language. Languages shape the world. Dumb languages make for dumb worlds.

All of computing is based on abstractions. You build higher-level things on lower-level ones. You don't try to build a city out of molecules. Trying to use too low-level an abstraction gets you into trouble.

We are in trouble.

The biggest thing you can reasonably write in C is an operating system, and they're not very big, not really. They look big because of all their apps, but kernels are small.

The biggest thing you can write in C++ is... also an operating system. Well, maybe a little bigger. Let's say three times bigger. Or even ten times. But operating system kernels are at most, what, maybe a million lines of code? So I'd argue the biggest system you can reasonably write in C++ is maybe 10 million lines, and then it starts to break down and become this emergent thing that you have no hope of controlling, like the plant in Little Shop of Horrors. Feeeeeed meeeeeee...

If you can get it to compile by then, that is.

We have 50 million lines of C++ code. No, it's more than that now. I don't know what it is anymore. It was 50 million last Christmas, nine months ago, and was expanding at 8 million lines a quarter. The expansion rate was increasing as well. Ouch.

Stuff takes forever to do around here. An Amazon engineer once described our code base as "a huge mountain of poop, the biggest mountain you've ever seen, and your job is to crawl into the very center of it, every time you need to fix something."

That was four years ago, folks. That engineer has moved on to greener pastures. Too bad; he was really good.

It's all C++'s fault. Don't argue. It is. We're using the dumbest language in the world. That's kind of meta-dumb, don't you think?

With that said, it is obviously possible to write nice C++ code, by which I mean, code that's mostly C, with some C++ features mixed in tastefully and minimally. But it almost never happens. C++ is a vast playground, and makes you feel smart when you know all of it, so you're always tempted to use all of it. But that's really, really hard to do well, because it's such a crap language to begin with. In the end, you just make a mess, even if you're good.

I know, this is Heresy, with a capital-'H'. Whatever. I loved C++ in college, because it's all I knew. When I heard that my languages prof, Craig Chambers, absolutely detested C++, I thought: "Why? I like it just fine." And when I heard that the inventor of STL was on record as saying he hated OOP, I thought he was cracked. How could anyone hate OOP, especially the inventor of STL?

Familiarity breeds contempt in most cases, but not with computer languages. You have to become an expert with a better language before you can start to have contempt for the one you're most familiar with.

So if you don't like what I'm saying about about C++, go become an expert at a better language (I recommend Lisp), and then you'll be armed to disagree with me. You won't, though. I'll have tricked you. You won't like C++ anymore, and you might be irked that I tricked you into disliking your ex-favorite language. So maybe you'd better just forget about all this. C++ is great. Really. It's just ducky. Forget what I said about it. It's fine.

C++ allows you to construct all sorts of abstractions with minimal performance penalty. No other languages come close in this regard. There're problems/defects with it, as it's a complex language and the specs and implementations can have bugs/defects, just like most other languages (even python, ruby, php etc. have many bugs you have to work around.)

Other than that, the main problem is complexity, as it's a multi-paradigm language that allows you to do all kinds of things in sometimes verbose and somewhat non-intuitive ways (which gets better after you understand/practice a little more.)

However for applications where bottle necks are else where (external services/db etc.), the performance advantage of the language is negligible and doesn't worth the extra effort.

OTOH, I personally find my productivity in C++ (with the help of the excellent boost libraries) is on par with that in other languages (including Java, Python, Ruby, Perl etc.) for large performance sensitive applications, because you end up pulling your hairs out if they are too slow and you have to rewrite parts of it in C/C++, which is usually a PITA to deal with (all foreign languages interfaces I have used have been a PITA (mostly due the maintenance need of upgrades these other languages), including simpler ones like those in Tcl, Lua and Ocaml, compared with using the same language). For short one liners, my favorite is still Perl, as it's ubiquitous and more consistent than shells.

To me C++'s complexity is actually justified to some degree by the fact that it's a multi-paradigm, performance-oriented language. I think its biggest downfall is that it's engineered only for performance and flexibility, and is missing a ton of little convenience/syntactic sugar features. In other words, it just makes very little effort to make simple things simple, leading to death by a thousand cuts. Examples:

1. A good, but trivial, example is the ridiculous amount of boilerplate necessary just to iterate over an STL container.
2. A really, really basic standard library. Yes, you can go find third-party libraries, and this is fine when you have some large monolithic need. However, when you need a bunch of small, miscellaneous pieces of functionality, the overhead of finding libraries and keeping track of all these dependencies is hell.
3. An antiquated module system that requires you to violate DRY by including prototypes in headers, thus telling the compiler the same thing a zillion times.
4. No delegates, closures, etc. Sure, you can simulate these with other language features, but it's a lot more of a PITA to use than if they were first-class concepts.
5. This is only a problem because the nature of C++ is to rely so heavily on metaprogramming where less performance-oriented languages would use something like runtime reflection or duck typing, but the template system is a Turing tarpit. Variadic templates, static_if, etc. would make C++ metaprogramming much more useable.
6. Lack of GC. Yes, GC isn't appropriate for everything, but it's appropriate for most things. If C++ GC was opt-out, not opt-in, I think it would simplify things greatly, while still allowing real-time programs, embedded code, etc. to be written in C++. Admittedly, though, with RAII and smart pointers, lack of GC isn't as bad as it sounds at first glance.

I'm sure I could think of more, but these are just my biggest, most obvious complaints.

C++ will not spoon-feed you. If that is a problem, then yeah, it sucks. :)

C++ is big and complicated.

But that's not the problem.

Because it's big and complicated, many companies/departments hire a C++ guru. The job title is often "Application Framework Architect" or something similar. This job, unfortunately, attracts people who are not easy to work with. They usually don't write low-level code but do write high-level, excessively-generic templates that don't really do anything. They also write coding standards. And since they haven't written any low-level code in years, they easily forget that they making other developers jump through hoops (or maybe they enjoy doing so.) So you end up with silly rules like "switch statements are banned" and "all database access must go through my (broken) ORM template library." And it's politically unwise to argue with them because they are assumed by management to always be right on any C++ issue.

This is less of a problem with simpler languages, because there are fewer subtleties that the guru could claim to be the only one to understand.

Speaking as someone who does a lot of maintenance work:

Other peoples C++ can be very hard to parse. There is a lot more scope for self expression and that can be quite dangerous!

Memory management is certainly an issue, a good C++ programmer can produce amazingly fast and efficent programs in C++ maybe more so than any other language.

In my experience there aren't that many of those guys around and the casual C++ programmer can cause a lot of damage in fewer lines than in (say) Java or C#.

Unless you have a high degree of technical competence it can be much harder to produce cross platform code: libraries, word sizes etc will trip you up.

Maybe someone else has already said this but...

Language only matters to a point. The best programmers can create great systems in crappy languages and the worst programmers can create crap systems in the greatest languages. I've seen it time and time again... and it's the most annoying thing in the world.

C++'s drawbacks are mainly that it is quite complex. A lot of that complexity extends to syntax (especially in the area of declarations, initialization/construction, and in particular templates). A lot of the syntactic complexity is in the language because the designers were committed to keeping the syntax as backwards compatible with C (and early, pre-standard C++). Quite simply, there are an awful lot of rules to using C++ properly, and a lot of those rules are 'special cases'.

There is also a lot of complexity in terms of resource management -it's entirely the programmer's responsibility. RAII helps a lot with that, but until Boost-style smart pointers and other RAII management classes become universal and/or standard, RAII techniques will be done differently in different projects making them painful to adopt (everyone seems to roll their own).

The advantage of C++ is that the programmer is largely in complete control. And as far as potential performance goes, there are few things that would require dropping down to assembly to get performance that can't be done in C/C++.

The single biggest problems with C++ is the separation of "platform" and language. That is, when you get a C++ compiler and the standard libaries, there is not a lot of standard utilities and frameworks that the developer can just jump in and use. This makes it hard for C++ to be marketed.

If you look through the marketing crap and compare language to language, not platform to platform, you will find that C++ is one of the best languages around, suited to many, many types of applications.

I personally dislike the way that C# and Java are tied to their respective platforms.

Here is mine ..

Pitfall: Lack of Intellisense support compared to C#, VB.NET

Cause: Without Reflection mechanism as in C#, VB.NET, it's hard for an Visual Studio to provide great insellisense/autocompletion of the same quality.

Alternatives: C# and VB.NET :)

Pitfall: It is hard to create GUI program with Win32 or MFC. Even third-party tools such as Qt or wxWidget is hard for a n00b to setup and understand.

Cause: Maybe because creating a GUI and handling events in VB 6.0, C#, VB.NET is so easy. So I see doing this in Win32, .., is hard.

Alternatives: We can actually create GUI in C# and have some background works done in C++ with C++/CLI. But this also adds dependency to .NET Framework :)

However, I always praise C++ programmers for their algorithmic expertise. But I don't see many C++ programmers who do software engineering practices or OOP concepts, in my life.

To name one pitfall - (arguable) lack of a proper module system. And solving the problem by preprocessor usage made things only worse IMHO.

Despite the popularity of C++ I must admit I have yet to see a proficient C++ developer in my not-very-long career personally. Knowing C++ will make you a more valuable player in the field for sure, let alone make you stupid in others eyes.

To give a broader explanation on "the lack of a module system", consider this example:

include <someheader.h>
...
...
x = afunction(...);
...

Now, there is no way to determine which module the symbol "afunction" comes from unless one goes and searches the declaration through the "someheader.h" and all the headers "someheader.h" includes and the headers those include and so on...

Of course, this is not much of a problem for your C++ compiler as it is given all the source code in a big junk of file(*) that is nicely prepared by the preprocessor, all the include directives expanding to actual sources they do point.

Now, it's debatable whether this is a better way to handle modules of source files compared to how other languages does and sure has its advocates for its usage but as far as I can see, this is one reason why C++ tools, let it be the intellisense feature in your IDE or any refactoring tool, are not up to par with say.. C# or Java tools. (Another reason would be the templates.)

(*) Citation needed. It would be nice if somebody enlightens us about C++ compilation cycle more intimately than this post does :).

EDIT: some funny quote supporting my experience.. ^[1]

C++ is like teenage sex:

* It's on everyone's mind all the time.
* Everyone talks about it all the time.
* Everyone thinks everyone else is doing it.
* Almost no one is really doing it.
* The few who are doing it are
      o doing it poorly;
      o sure it will be better next time;
      o not practicing it safely.

ps. You may also want to look at the D language ^[2] which addresses the problems C++ faces in a more elegant and organised way. Reading through D documentation you may find comparisons to C/C++, explaining the pitfalls and alternative solution(s) D provides. Much recommended.

This is a great question for me, because C++ was the first language I ever learned. It was a challenge to program in C++ in college. Then I learned LISP, that was totally different and still very challenging!!! Then I learned Python and Java. All I can say is WOW! The difference is in two areas, ease of coding and ease of use. You can't really see just how difficult it is to do simple things in C++ until you have used other languages that are so much more natural and ease-ful (not easy, but "full of ease", that natural flowing feeling)

I think of programming in C++ like lifting weights: once you can lift 200 lbs, then a push-up will be a heck of a lot easier. Or if you lived your life with weights on all the time (C++) then when you take those weights off, you're going to feel a whole lot lighter, and wonder what the heck you were thinking.

Pitfall #1: No Ease of Programming. Bugs happen much more often because you are dealing with lower level features such as pointers and *char a lot.

Cause #1: Directly accessing memory is something you can't avoid. Pointers used all over the place.

Alternatives #1: C#, Java, Python, Ruby, etc

Pitfall #2: No Ease of Use. Many common everyday things you might want to do, you will either have to code yourself or find some source online, whereas other languages have many more features built into their standard libraries.

Cause #2: Don't know. Maybe it is because the language is old?

Alternatives #2: C#, Java, Python, Ruby, etc

The biggest problem I see with C++ is the legacy it inherited from C. On top of that, it introduces a lot of unique runtime problems of its own which make it rather complicated to use across modules. For instance, exception handling and RAII, when used properly, can significantly reduce the efforts required for handling errors. Nevertheless, exceptions cannot be thrown across module boundaries. Memory cannot be allocated in one module and deallocated in another safely across module boundaries. This is true of C, but becomes a greater problem in C++ with template containers which can easily cause memory allocation/deallocation mismatches.

The lack of memory management isn't necessarily a weakness. The language provides you with the building blocks to implement any kind of memory management system you can imagine, and there are plenty of libraries available to do this for you. It doesn't have an integrated garbage collector like Java, yet one can develop one if desired.

That said, this is somewhat idealistic. Many programmers still continue to rely on manual resource cleanup in spite of having all the tools to automate it. Modern C++ thinkers like Sutter suggest going so far as to use nothing but smart pointers for all memory management so that there isn't a single instance in your code where you're manually freeing memory. This might seem excessive yet this kind of strict conformance is typically required for a team to successfully develop very robust, large-scale applications, especially when exceptions are involved.

A lot of the power of C++ is that it doesn't assume too much at the language level, allowing one to achieve very expressive code and even implement DSELs directly in C++. The lack of memory management enforced at the language level is but one example of this. The problem with that is that sometimes people try to get a little too creative and end up with something that might seem brilliant at the time but is actually very awkward and problematic to use in practice.

C++, being such a general-purpose language and one which makes very few assumptions at the language level, is a language which has great appeal to those who take it seriously. It is riddled with problems, but there's a tremendous difference which is probably one of the reasons it has die-hard enthusiasts like myself.

When we run into a language barrier in many other languages which causes systemic problems in the code your team produces, there's little we can do about it but work around it. As an example, there is no really elegant solution to deal with resource cleanup in Java and people often neglect to cleanup resources properly in the finally block. In C++, there are plenty of solutions available that people have built on top of the language (ways to implement RAII) since these kinds of things are not language-level problems in C++: while the language doesn't always provide solutions, it doesn't restrict solutions either.

This kind of freedom is probably one of the greatest appeals of C++ just from a pure language standpoint without considering other factors like efficiency. It has also lead to a lot of exploration and experimentation which has caused truly elegant and superior solutions to bubble up, yet those solutions are often awkward when it comes to implementation because they are built on top of such a general-purpose language with no specific accommodations for such solutions.

This kind of freedom is also the language's downfall. Too many self-proclaimed gurus tend to get creative and devise solutions to problems which have already been solved, and their solutions are often inferior to those which have been accepted and reviewed. Consider how many people have implemented their own reference-counted smart pointer in C++ without considering polymorphism, capturing on-site deletion, and the need for weak references. If C++ is going to move forward, more developers need to focus on the solutions that have worked and why they have worked rather than abusing the freedom that the language provides to roll their own solutions when superior solutions already exist. When it comes to C++, there's much more to learn than just the language itself; the freedom requires that we carefully study how it can be used effectively since there are too many ways to use it ineffectively.

The language also needs to evolve with these new discoveries and trends which it fortunately appears to be doing with C++0x, albeit slowly.

The greatest pitfall of C++ is the all C++ code that has been written incorrectly. C++ is incredibly complicated and it doesn't offer much of a buffer from the complexity of writing code. Many things are blamed on C++ that has nothing to do with the language and everything to do with the usage of the language.

To be fair developers are human, my C++ is far from perfect so I too have to pay close attention to ensure that I use it correctly.

Regardless, I would be highly critical of any "you can't do X in C++" statements as this is almost always false for at least three reasons: 1) C++ is Turing complete thus if a certain functionality can be computed then it can be written in C++. 2) C++ is fast, if you need to do X in Y microseconds on Z hardware then C++ is often times your best bet. Even if the compiler isn't good enough C++ supports inline assembly and it doesn't get much faster than that. 3) Most of what people describe as language features are actually standard library features. Those same libraries in Java and C# can be ported to C++. Even GC can be done in C++.

Also, while C++ is very complex there are ways to mitigate the complexity of it. With a good library (3rd party or in house) many things can be made much simpler. C++ offers an incredible amount of control over the implementation syntax (operator overloads, macros, templates). Furthermore, with good development practices the complexity of C++ can be managed.

Now, some may suggest that this complexity is a pitfall of C++. However, the complexity exposed in C++ exists in the other languages as well, some languages just hide these issues better by providing a prepackaged solution. This will allow you to make things work quickly, but once one of those more complex and underlying issues becomes a problem it still needs to be understood and fixed. In C++ you can still still do those kinds of fixes.

There are still many things that can be improved with C++ and there is definitely a need for extensions to the standard library. The syntax could be made more expressive, and the inclusion of C in C++ is a bit contradictory. Also the compilation model as someone else here suggested, may be in need of an update.

C++ is sometimes very convenient and can ease development of some low-level code in C. Aside from various specific complications, the problem is that C++ is too often considered a much higher-level language than C, which is true in terms of the concepts and abstractions it recognizes, but those are mostly statically interpreted before actually compiling the code. In the way that the code is generated, it is almost as low-level as C. The compiler goes to a great length in trying to generate optimized low-level code equivalent to what the program specifies and hide the details from the programmer, but the details are there and have an effect in plenty of special cases which in practice requires you to take them into account.

Two main traits of the kind you had in mind follow:

Unclean function/module separation in generated code

Most classic compiled languages as well as modern "byte-compiled" languages, have the nice property of code generated by the compiler in so-called "units of compilation" - routines (functions or procedures) within modules (libraries, namespaces).

In C, for example, the body of every function can be compiled independently of that of every other function (of course the prototypes of functions and declarations of global data used need to be available to it, but those do not change when their implementation changes), resulding in text symbols (for functions) and data symbols (for global and static variables) in the generated object file. The code generated for calling a function is independent of the called function's code. This even extends to modules - different source files can be compiled separately into modules at different times (even by different compilers) and as long as they work and their interfaces (declarations and prototypes) do not change and the binary format is compatible (usually dictated by the operating system), one can be changed and re-linked (possibly at execution time) with the others.

In C++, this is not the case. Big parts of a program must be compiled together. Inlined code can span modules, code changes in small part of a class can change the code generated for many member functions, and users of the class, and big part of the code generated for templates is generated when compiling code that uses the templates (which is why in most implementations all templated code used externally needs to be implemented in header files). This can inflate executable sizes and compile times and make debugging more difficult. It also hinders modularity of compiled code (try distributing libraries that work with different compilers) and is largely incompatible with a main idea behind shared libraries - you can update one without having to replace or rebuild all programs that use it.

In practice this is not always a big problem - modern debugger technology often eases handling the generated code, big executables are tolerated if most of the code is not shared anyway, programs are tightly bound to one version of a library anyway, multiple versions of libraries can coexist, rebuilding is possible, and modern hardware and compilers are fast so compilation time does not necessarily matter so much. But this makes C++ feel very unclean, and in some cases when large systems are maintained, this can be a great pain.

Compile time problems / leaky abstractions

Pitfall: Many times, a small change in your code in one place can cause a much bigger change in the way code around it and types or objects used by it is treated, due to the great amount of static inference the compiler performs. Such a change can then cause the compilation to fail because this static inference does not work. If those details are ignored and the code at which the error occurs is inspected at the intended level of abstraction, there is no visible problem in it, but following the declarations will lead to an ambiguity or clash elsewhere. The error message generated by the compiler in such a case is likely to involve those static details that a real abstraction would not reveal, and to resolve the error you will need to understand them at that level.

Cause: The advantage is that even if the programmer is aware of those details, the compiler often takes care of them in an better way than the programmer would manually and unless a lot of attention is given, better optimized code is produced, while maintenance is simplified. Such errors often result from misunderstanding of the implications at some stage or insufficient care in the use of some language features, which is all too common. The programmer needs to understand the language well, be aware of those details and take care while writing such code.

Example: Compilation to fail where templates are used in multiple places, used elsewhere, due of infinite recursion at compile-time (which is of course detected by the compiler), resulting from a reference to a common type. Templates are designed to provide a polymorphic interface where compatible types can be substituted independent of the declarations behind them, but strictly the interface of a template is much more complex than the method signatures, involving all implicit types in the class definition.

Alternatives:

Such details do not need to be inferred if they can be made explicit, requiring somewhat finer abstractions - this means more elaborate (and thus longer) code. This leads to a lower level interface closer to the actual semantics, and can to some extent be implemented even with features in C. In this case such errors are localized and error messages point where the clash is - which the programmer cannot be unaware of due to the explicitness of the interface. This is appropriate when low-level control and deterministic runtime of the kind that C++ can offer is desired.

Or, higher-level generated code (interpreted code, intermediate code that is not directly executable by the CPU, or a runtime abstraction library as used in Objective-C) can help better abstract such interfaces making them less leaky, redefining them in a more consistent way at the cost of avoiding some non-trivial static optimization that span large chunks of code. This results in somewhat slower code as some of the abstractions need to be handled by the interpreter or abstraction library at run-time. In some cases however this slower abstraction is either tolerable because it is not a performance bound or negligible because it is not a bottleneck.

In the case of intermediate code, just-in-time compilation in which optimization can be made at runtime based on such things as type information available, can be used to remedy this and result in performance that is often as good as statically optimized code. However, the increased complexity and non-deterministic performance can make it undesirable for some uses where low-level code would be desired.

A lot of apologist for C++ have had their say. Here's mine:

I started programming in C++ around 1989/90. Presented a paper on enhancing C++ at OOPSLA '93. Interacted with Stroustroup regarding this enhancement, which he favored at the time. (Met up with him at conf. in Portland and started many months dialog from that point.)

Used C++ professionally up until probably writing last code in it around 2005.

These days in enterprise development I use mostly Java. Have also used C# for many things. I never really encounter anything anymore that would justify pulling C++ back out of the closet.

Bottom line for me is that Java and C# are both way more productive to write most kinds of entrprise-related software in than C++. Any claim that C++ attempts to make over performance, etc., is usually irrelevant (or not even entirely true given steady improvements in VMs over the years) - relative to the cost of producing the software. There is just not much occasion in the software I've written during this decade that C++ could make a viable argument for itself.

Folks that do commercial game software still rely heavily on it. Much of the serious OS kernel and related software is written in C (or Objective C). There is still some embedded development activity too for devices, etc. But in mainstream software, and particularly the web related and enterprise stuff, there's no need for, nor rationale that makes any persuasive case for C++. It's way too expensive to develop in relative to the much better alternatives.

It's just that C and C++ are oriented to execution efficiency first, not programmer likeness first like some other languages. This fact make it hard to learn, so people hurted by the difficulty (like managing memory yourself and with precision, while trying to express something with your code...) tends to prefer other languages more adapted to get things right quickly and without too much thinking (because thinking about the hardware representation of your program at the same time as the high level representation is hard).

So, it's more like people who need efficiency will accept the power of c and c++ in exchange of their "complexity" (that is in fact dependent of the complexity of the software and the way it have been expressed) and other peoples who just want their windowed application done right and don't need all that C and C++ can offer as it's not the point.

For example, in videogame on console, you simply have no choice. On some embedded software, you have choice between C, C++ and Java but if you really need system resources access or speed, you'll not choose Java if you can.

So, to resume, the pitfall of C++ is that it gives you maybe too much power too bear, and in lot of case its more than you wanted. If i wanted to make a game that would be fast, i'd go c++ (and i do). If i want to make a management tool, i'd go a more high level language (C# for example).

The biggest pitfall of C and C++ is that the programmer has to manage everything. There is garbage collection, so every object that you dynamically create, you must also remember to destroy.

Other then that, both C and C++ are great languages and have their uses. Anyone who says that they are outdated/stupid/inefficient really doesn't know what they are talking about. Personally, I think every programmer should have to learn C at some point in their career and create an non-trivial application with it. Until you learn C, you really can't understand or appreciate any other language. In order to program efficiently you must understand things like dynamic memory allocation and pointers.

1 Pitfall: compiler dependencies - some features like RTTI, exception handling are not handled the same way across different compiers/platforms making it difficult to port.

cause: advanced features / lack of compatibility in old compilers ...

Alternative - i guess it is C++ specific :p

2 Code Bloat with STL - though there are ways to avoid it, it doesn't enforce them and every possibility of code bloat in real projects(though the design might be good).

cause: abuse of generic programming.

Alternative - not sure :(

3 Lack of Standard Unit Test Frame work - though there are many unit test frame works for C++ ( and many keep adding, with gtest being the latest one (as per my understanding) ) due to its very nature , it is hard to have proper Unit Test Frame work.

Alternative - JUnit and NUnit ...

There is a relevant discussion here:

C++ - Anyone else feel like C++ is getting too complicated? ^[1]

Hear Jeff Atwood's opinion ^[1] on this.

Programmers hate C++ because it reminds them that programming is difficult. I mean, do we have to warp our brains around Boost templates all the time? Do we have to be told the difference between const and non-const (that's to not mention volatile) all the time? Why can't everything be non-const and that's the end of the problem? Oh, I see. When it's const, the compiler can perform some optimizations it can't when it isn't const. But, dammit, how does that reflect into something I can actually see, touch, smell, whatever? How many picoseconds of processor time am I saving by not using, say, Visual Basic and getting the thing done in 10x less time?

When I was at high school, I had a similar experience with grammar and syntactic analysis. The abstraction needed to parse those long sentences into subjects, predicates, complements, etc. was above what our little brains were willing to perform. It became worse when there were nested sentences ("I wish I had studied before the exam.", "She said she had done her homework when, in fact, she hadn't.", "The boy who ate her pie went away five minutes before she came."). It's the high school equivalent of programmers hating C++.

By the way, I happen to like C++. And I didn't dislike syntactic analysis when I was at high school, mainly because I was learning how to write (lame LL(1)) parsers, and I was excited with this language processing thing. But maybe that's because I'm an nerd with no life.

What annoys me no end is that there isn't a singe string class. Half the time I spend converting strings from one type to another.

You name it { First ANSI X3J16 technical meeting 1990}:

Well, I don't like C++ because it doesn't have the CPAN! My current regular language is Java; I'd prefer Java to C++ because (I believe) the JDK includes so many more standard libraries than C++. But I prefer Perl over that because CPAN has so many more libraries available on it.

When I want to write a program in Perl, I check out what CPAN has and build on it. If I'm wanting to do something with FTP, for example, there's a CPAN library (or two or three or four) to make it easy and let me focus on the unique part of my program, rather than opening socket connections and feeding it bytes. More importantly, there's CPAN libraries for things much more unusual and unique than FTP. You name it, somebody's taken a stab at it on CPAN.

In Java the situation is different. Opening FTP and HTTP connections is builtin, as is parsing XML (and HTML? can't remember). But if I have to go outside of what comes standard with the JDK, I'll have to look around the entire Internet rather than just one comprehensive archive that attempts to attract everything and even has private groups offering quality ratings. And despite the language being so much more popular and the fact that Java code is available across the entire Internet rather than just in one place, the fact is that the odds of finding a library to do what I want are usually lower in Java. Very often it's not that I can't find the library; it's that it doesn't exist. Or, rather, crappy implementations exist in thousands of companies, and they will never be released for everybody to pool their resources on and generate a high-quality version on which many people can build.

The situation in C++ is worse. You've got the standard template library (which I used in my shortlived C++ days), and you've got Boost (which I only know about in passing). And I'm sure there's other libraries out there. But there's less of it than even Java has.

I'd use C++ in a heartbeat if an employer made me a good deal on it. I'm not prejudiced against the language. But I do know that other languages have technical and cultural reasons that make modules, libraries, and extensions much easier and therefore much more plentiful, and I will always like that better.

First everyone should admit that learning curve for c++ is really steep.People are in a hurry to use feature before learning it completely and correctly.

1. There is more than one way of doing thing in c++.So people stick with one they are good in,but when they come across others way it look little alien.
2. We tend to spend more time in learning language rather than with solving the actually problem.
3. We tend to write compiler dependent code with out even knowing it is.
4. When using pointer we should know about the low level things on the other hand we should forget the same while using high level containers like std::vector.
5. Undefined things in c++

I spent 4 years learning/writing C++. Now I am mainly a .NET developer.

I generally avoid using C++ except when I am working on a module that is dealing with complex computations.

Also it is very un practical to deal with un managed code these days.

There is nothing wrong with it , as long as you can learn a language from its Standard. The lack of ability to learn from Standard shouldn't be C++'s fault. It is Human Being's fault!

The only thing I really wish for in C++ was thread support in the language. (But I suppose that is coming?)

Here's a book-length list of what is wrong with C++, called the C++ Frequently Questioned Answers ^[1]. I would not start a new project in C++ unless it was performance-critical. But if C++ works for you and suits your need, please feel free to ignore the previous sentences.

My main problem with C and C++ is that both force me to think like a computer, which I find is not conducive for solving a lot of high level problems quickly.

I find C++ quite cool.

One drawback: the lack of default (read STL ^[1]) powerful buffered I/O ^[2], especially compared to C#. Indeed you're free to optimize the bottleneck, but having it by default is great.

• Templates are half-assed dynamic typing that occasionally provide performance advantages.
• Boost tries to patch up the gaping holes in the standard library.
• RAII is an attempt to address the worst side effect of exceptions.
• 3rd party lib, primitive types, manual memory management are all courtesy of C.
• It's well known that explicit memory management is not faster than the best GCs.
• The C++ standard library duplicates and is inferior to the corresponding C library. The only part of libstdc++ that C sorely needs is an equivalent to STL, albeit with better performance and debuggable. The rest should be tossed.

The problem is that C++ is a renowned-rapist:

According to researches, C++ programmers have Stockholm Syndrome ^[1]. Because, they first get raped by C++ itself during the learning curve, and can't abandon it aftermath!

Have you ever seen a C++ program that never crashed?

C++ is soon as perfect as much as my ability and this is for any language.

There are just other languages and platforms that make certain things trivial to do, that would require hours to do it C/C++.

But other things that can be easily done in C/C++ are themselves often painful in languages that feature higher levels of abstraction. This is becoming less frequent though as the newer platforms evolve and mature.