How to learn to write idiomatic c++ code [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

开发者_Python百科

We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.

Closed 7 years ago.

Improve this question

I recently forced myself to study C++ and I just finished reading the book C++: The Complete Reference, by Herbert Schildt. I liked the book and think I got more or less the big picture. I noticed though that when I try to check with other people the things I code using the material I learned, they are usually considered non-idiomatic and superseded by an STL way to do it that is safer and easier (well, the book doesn't cover STL and Boost libraries).

So I'd like to ask: what are good sources to learn the patterns of a good C++ program? Where can I learn basic patterns from the "C++ way" to do things and not just repeating C patterns in C++?

I'd be particularly interested in sources that included STL and Boost stuff.

---

You might wnat to check out The Definitive C++ Book Guide and List

For your purposes I would especially recommend:

• C++ Coding Standards
• Effective STL
• Beyond the C++ Standard Library: An Introduction to Boost
• Code Complete
• Clean Code (Examples in Java, still valid though.)

They are not in particular order, also you might want to read and code something in between them.

(Note: As noted by @John Dibling the Boost book might be a bit out of date, I do not have experience with that one myself)

---

Since you have completed the Herbert Schildt book, you can read the book by the Bjarne Stroustrup (The C++ Programming Language) or Bruce Eckel's book (Thinking in C++ Part 1 & Part 2). The Eckel's book is freely available on the internet and Part-2 talks about STL.

---

The best way to learn how to write C++ idiomatic code is ... to write C++ code and to have your code reviewed by some advanced C++ developer. You should also read some of the most famous C++ books (Effective C++ by Scott Meyers is a good start, Modern C++ Design is a bad book to learn how to write nice C++ code but is a great book if you want to discover and understand the concept of generic programming).

On top of all that, you should read much doc about STL and boost and learn a lot about iterators. Iterators are the key to use STL (and boost implementation of containers and algorithms) and if you don't know how to use them, you won't write C++ idiomatic code. Ever.

---

Accelerated C++ is an introduction to C++ that uses the STL from the very beginning. It's not a long book, but it's "dense" and a great choice for someone in your situation IMO. My experience with C++ was similar to yours when I read it.

---

I'd (also) recommend:

• Effective C++, Effective STL by Steve Myers. They are easy to digest, yet very valuable - sometimes even illuminating.
• Code Complete (The 1993 edition is available cheaply and not that much different). It's lengthy, but it walks across the entire field from what it means to be a programmer to how a for loop should look. (It would be better if it was shorter - the way it is it covers so much ground it's hard to place it). I hold it dear because it illustrate two points very well:
  • code is compromise
  • There are know facts, (but we still manage to get by by gut feel)
• C++ FAQ Lite / C++ FAQ.
• I'd throw in Facts and Fallacies by Robert Glass - it doesn't fit your request very well, but go read it.

---

It's natural that you are unhappy with other people's code. That's typical for programming - heck, even my own code of five years ago was written by a total n00b. That might be more articulated for C++, since it caters for different styles, and often puts freedom ("you can") over guildelines ("that's the way").

Still, mulling over existing code - yours or others - and considering how it can be improved. Also, figuring out why it is the way it is sometimes helps.

---

(I remember a few TheDailyWTF's where everyone would chime in how stupid and unreasonable this is - yet somewhere, buried among the me too's, was someone with domain experience explaining convincingly under what circumstances this was better than the obvious solution).