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).