I know this has been asked before, but I'm coming at it as an experienced developer so perhaps the advice is different.

I've been programming professionally for 15 years, the last 7 or 8 in C++ and C#. I consider myself pretty good at both of them, but I look at how real gurus utilize the language and it is humbling, to say the least.

I came from a C background initially, so my C++ is often a blend (best case) of C and C++, which bothers me from multiple points of view. Part of my problem in solving this is not having a clear set of guidelines to work from. (Another part of the problem is the shortest-path problem; it's hard on a deadline to force the right style over function.)

So what are some good guidelines for a more experienced programmer? I feel like I have a strong handle on most of the STL and on some bits of Boost. I'm a bad template programmer (and thinker). I don't have any clear methodology around exception handling-- I often prefer return codes over throwing exceptions. I haven't really embraced RAII which leads to occasional resource leak issues. I have mostly eschewed smart pointers but feel like I'm really missing out.

How do I make the next jump from competent-but-not-very-pretty programmer to a better structured one in C++? What rules do you force yourself to follow to avoid falling into comfortable shortcuts/ruts?


Learn a different language.
Only after I learned about lambdas in python did I become interested in the ideas of method pointers, boost::lambda and the upcoming c++0x lambdas.

A fresh and different perspective can make you think about how to do things differently within the languages you already think you know.

10 accepted

Have you read Meyer's two books, Effective C++ and More Effective C++? After 7 or 8 years you may know a lot of their content already, but they're a useful list of about 85 mistakes to avoid using C++.

Also, have you read Stroustrup's C++ Programming Language? I found it good to read after Meyer's books: it's big so it fills in little details that you won't have read previously, and, gives you ideas of how he imagined people would want to be using C++, and why therefore C++ is designed as it is.


Write a lot of code. As much as you can, and branch out into different areas. You can find books and tutorials on your own, and those are great, but the real world experiences are the ones that stick with you the longest.


I would agree with everyone else read, read, and read some more. Oh yeah, and write lots of code. I often feel left out because I haven't embraced template programming to the level that Alexandrescu and the others have. I just assume that I haven't found a need for that level of complexity though.

As for the STL, there are two must read references: the original SGI STL documents and The C++ Standard Library: A Tutorial and Reference. Read the tutorial and refer to the SGI documents regularly. They will enhance your understanding of the C++ Standard Library dramatically.

I'm surprised that Herb Sutter's Exceptional C++ series hasn't made the list thus far. These two books did more for my understanding of exception handling issues more than anything else. They are also excellent at explaining a number of the dusty corners of the language. If you haven't read through the Guru of the Week archive, then I recommend that you visit it for a good sample of the sort of detail that Mr. Sutter delves into.

The last thing to glance at in your spare time is Marshall Cline's C++ FAQ Lite. This is a fun thing to read over during lunch or when you are waiting for something to build. By the time that you manage to make it through this list, you should feel quite comfortable with RAII, exception handling, and the STL at the very least.


Regarding rules to follow - check the Google C++ style guide. I think it's a reasonable set of rules that reduce complexity of C++ without reducing too much of its power. It proved to be working well for a large group of very good programmers.


Reading books and writing code are of course two excellent ways of learning the trade. Reading code and writing books are two more things :) It doesn't have to be anything big, it could be a simple blog about your findings.

There's always someone else that can benefit from it. Teaching someone is a very nice tool to advance your own thoughts and ideas.

Cheers !


A lot of good books have been mentioned, but what also helped me a lot was to read the questions on comp.lang.c++.moderated, see if I could answer them, and then read the answers (usually from experts in the field) and see how close I came. When I could answer correctly, I knew I was getting better.

Of course, nowadays, you'd read SO. :)


Reading professional blogs helped me to learn some new techniques. I've been programming for money for about 10 years. And I've read almost all C++ related books. Every day's a school day still.

Here is how:

Look to the master,
Follow the master,
Walk with the master,
See through the master,
Become the master.

I always find it helpful to actually read a lot of code that gurus that you mentioned write, pick up their 'tricks' and then use them as much as possible. Reviewing open source code is also quite helpful, especially if you have a open source project that partially(or fully) address similar problems that you have to deal with.


All answers thus far are great examples of ways to get started. I would add that looking through some open source programs to see how other experienced programmers are implementing projects with C++ would be worth your while.


Join and/or start your own open source project which uses C++. Your co-developers and users in your project will challenge you to become a better programmer.


I'd offer you advice on thinking positive and not listening to what other people say, but I dont think this is the answer you'r looking for so I'm telling you:

  • Forget everything that you think may lead you into a pitfall.
  • Review lots of code written by clever people and try to fully understand and embrace it.
  • Do a lot of exercises by writing "hard" code (code you previously thought was hard and puzzled) found in books and such.
  • while(true) { Read, read, read; Write, write, write; Understand, understand, understand; }

OK, men, you need to read a lot of book and code. of course, you need write more.

In my exp(although I only have 3 year exp), language is not important(at last not that important), the key point is, whether or not you are familiar with the OS,CPU,Software Engineering,language philosophy,the detail of implement.

So I suggetst you to read this books(if you not have them done):

I suggest you read the code from sourceforge.net , there are lots of good code there.

15 year exp... We all have a long road to walk..

ps: the suggestion others post are more objective, take them.


Other than learning a new language as suggested in another answer, I'd read some of the classics. I haven't yet (just bought my first one: Pragmatic Programmer), but I made a list based off this SO thread:

What is the single most influential book every programmer should read?

I made a list in pretty much the same order as by upvotes on that thread, except I started with Pragmatic Programmer since it is shorter.

EDIT: This probably does not make you a better C++ per se, but definitely a better programmer in general, which will translate to your C++ code.


I've found that there are few substitutes for the draft standard. It's not very interesting for idle reading, but C++ is a large and complex language. When you've got a specific problem, and you're stuck trying to figure out why the compiler is doing something or other, it can be of great benefit to actually look up the details of how it's supposed to work. It's hard to get that from other resources.


Read a lot of code. From what I understand, you already have written lots of code so what you need is learn how other people think in C++. Read code that was written by really smart people that solves some real-world problem (like open-source projects).

Think about, if you're writer, do you need to read? Stephen King, in "On Writing" says that a good writer absolutely must read a lot. Programming isn't all that different.


Read James Coplien: Advanced C++.

If you haven't been exposed to other language styles then it'll teach you to mimic the styles of other languages in C++.

It may get you thinking differently


My addition: Learn and understand the details of a computer system. The details contained inside of a book like "Computer Systems: A programmer's perspective" can really improve the design of some one's functions as well as memory handling.

A programmer's perspective

For me, so far, Chapter 3 and Chapter 6 will have the biggest impact on my thoughts while coding.


Coming from a C background myself, I have two advices for you:

  1. I think you should look into how object oriented programming is done in ANSI C. That's right. It is possible to do it. These are actually the roots of C++. Check out OOC, which as an awk program written by Axel T. Schreiner. It is incredibly well documented and the documentation will give you an insight into how you can use object oriented concepts in plain ANSI C. After reading the documentation, I think you will gain a better appreciation for how things are actually working under the hood.

  2. The advice above won't help you with templates and other more sophisticated aspects of the language. For that, I think your best choice is to learn from the Gurus. Using the Boost libraries is already a good start as it will give you an insight on how its developers have solved certain problems. Better yet, the Boost libraries are open source. So you can peep into the code and learn from it.



C++ has the added bonus that it allows you to program in any style you choose. As a result it is usually possible to solve problems in 3, 4 or 100 different ways.

My recommendation therefore is, when you are confronted with a problem that you believe you have a solution for, then stop and try to think how it might be solved using a different style.

For example if polymorphism will solve your problem, then why not try to use templates to come up with a solution that uses "compile time polymorphism".

Books and coding styles are invaluable, but I find it's easier to really comprehend their meaning when I'm applying what they teach in real code.

Finally, don't be shy of using 3rd party libraries. IMHO, boost and QT provide the missing pieces that C++ lacked (in comparison to say Java) as well as removing a lot of the low level pain such as memory management etc.


Don't just learn another language, learn about what makes those other languages special. I hate to use the term paradigm, but that's exactly what you need: a shift in paradigm. Learn about functional programming in scheme or haskell or ML. Learn about 'logic' programming via prolog. Learn about building massively scalable apps in erlang. Learn about clojures and lambdas and actors and type systems. And then take those ideas and see how they apply back to your work in C++ and C# by revisiting old code (like code you wrote 7 or 8 years ago). What would you do different, and more importantly WHY? Then try to imagine how you would re-write that code in another ten years, and why.