Would you buy this C++ book? Please help shape its structure and contents

Quite frankly, I don't understand why people write encyclopedia sized books for CS topics. Firstly, the relevant themes change very quickly. Second, nobody has the time to read a 1000 page book, where one topic just follows the other. Third, after reading the whole book one might realize -- oh how do I use lambda's in C++[1], a new feature introduced recently? If people are buying books to learn lambdas, your entire effort might be rejected because of one topic.

As authors we need to understand that aspiring programmers have the whole web, where easy to read blogs and article surface on a daily basis. Paper books are more of an impulse buy than a self-education commitment. Books are too monotonous and incomplete to compete with the web.

That said, I will be honest and say that I will not buy this book. I will just Google for topics, read a book like Learn * the Hard Way [2] or take one of the Coursera courses [3] to get started. I would encourage you to find new ways to delivering study materials (through video for instance) than just writing a book -- which I personally think is a disruption waiting to happen.

On the other hand, if you succeed in writing a book like [4], then things are different -- you are explaining programming and not a language (syntax, features and caveats).

Good luck!

  [1] http://en.cppreference.com/w/cpp/language/lambda
  [2] http://learnpythonthehardway.org/
  [3] https://www.coursera.org/course/cplusplus4c
  [4] http://mitpress.mit.edu/sicp/

Paul Graham's On Lisp doesn't talk about configuring Emacs. It sticks to the important ideas which are not widespread. It doesn't try to be a survey.

http://lib.store.yahoo.net/lib/paulgraham/onlisp.pdf

What I am suggesting is that a section on compiler warnings is just stamp collecting. The reader still needs to RTFM. Same with source control and development servers. At best these are items for an appendix or end notes. Don't drag the reader through context unless you are writing a textbook - and even then, don't.

I guess the tl;dr is that the table of contents looks longer than necessary for a book which has a thesis about design. Respect the fact that your readers will work out the implementation for themselves. Save "Use const wherever possible" for the supporting blog.

Edit away everything that is unnecessary, as I have not done with this comment. Do you really have something objectively important to say about namespaces, or are you just expressing an opinion based upon your preference? And even if you do have something important to say, about namespaces, is it something that a professional developer can integrate into their existing workflow without horrible disruption?

What is the MVB?

Good Luck

Stack overflow talks a lot about its C++ FAQ tag. It may be good to include this information:

http://meta.stackoverflow.com/questions/68647/setting-up-a-f...

http://stackoverflow.com/tags/c%2b%2b-faq/info

http://stackoverflow.com/questions/388242/the-definitive-c-b...

NOTE: I am not sure I would buy it, but I might read it!

I wouldn't buy it.

I'm a C++ programmer with over 10 years, I buy software books, but I basically only go for well vetted books.

I dislike a chapter heading reading "Exception throwing destructors" even if that is a one page chapter with one big word "Don't." It also happens to be the type of thing I already expect a professional C++ programmer to know.

Actually, the only chapter I found interesting is #12 (MapReduce) and it doesn't really have much to do with reliable C++. But after reading up on this, I found that it gained little interest in boost [1], and its description in [2] is rather bland. Compare the description for N3554. So, instead, a book with only chapters like #12 but which touched on very useful, well-tested libraries would actually be more interesting. Not the normal libraries, the usual ones like boost in which professional programmers should already be adept, but some other ones that are real gems nonetheless. But all that is assuming that I would still be interested in writing C++ code.

However, I don't really see a future for C++ for most purposes, so "Scala for Profesional C++ Programmers" may be even more interesting.

  [1] http://lists.boost.org/Archives/boost/2009/08/155729.php
  [2] http://www.meetingcpp.com/index.php/br/items/a-look-at-c14-papers-part-2.html

No, wouldn't buy it.

The beginning of Part 1 looks more like a beginner programming book than a C++ book. They're important topics, but none of them are specific to C++, and they're not the reason I'm buying a C++ book.

The rest of Part 1 looks like a rehash of "Code Complete" and "Clean Code." There are already good books on those subjects, and I'm not seeing what this one adds. Might be interesting to the same people who don't know about SCM and compiler warnings, but I'm not in that demographic, and even they are probably better off in the long run going with other books.

Part 2 looks interesting, but not enough to buy the first half of the book along with it. There are other books on writing reliable multi-process/multi-threaded code (both in general and in C++), and my impression is they would go into more depth than a book that tries to be as broad as this one.

I should point out I was already predisposed to say "no" because my preference is to avoid books that tie themselves to a specific language unless I'm learning the language or the particular language has an unusual advantage for a particular thing (such as Erlang for reliable multi-processing). Unfortunately neither of those apply here, so I'd prefer the more general books on these topics.

First, I'll second brudger's point about scope. You say this is targeted at professional C++ developers, so you can assume a basic understanding of how C++ features work and restrict yourself to explaining how to choose and use those features to write reliable programs, don't feel any need for "completeness".

You've got two sections, guidelines and design ideas. I would probably get the most value out of the design ideas section, as learning new patterns to do things well is always handy.

But the guidelines section you're going to have to be a lot more careful. Most C++ advice books are targeted at beginners for a good reason, everyone has an opinion about how to write C++ best and they are rarely well supported. I would expect advice intended to be taken seriously by professionals to come with specific real world examples of how it addressed a reliability problem in a largish project, not just an expert author's say-so.

If you could actually collect that, it would be incredibly useful. You could even give it a nice inflammatory title like "n C++ mistakes that have wrecked projects"

Sure.. It should reference Lakos for good design. In ch7, you should have a section about singletons. Singletons should not exist, GoF hurt the industry a lot by saying singleton was OK... it most certainly is not OK. No one needs it, and to get reentrant code you don't want it.

For ch9, it's like a C++ version of the Goetz book... you should make the same point: people shouldn't write their own thread pools. Also make a point about ownership transfer when posting to a pool: just don't share any data.

Step 1: Put a basic book ToC onto the interwebs, and ask others to make it better.

Step 2: ???????????????????

Step 3: Profit $$$$$$$

like there aren't 100 Cpp books already available that would cover the topics in far more detail than this ever would.

That the first sentence of your announcement of "Reliable C++" should contain an obvious typo is an unfortunate paradox.

Your link that goes through two URL shorteners. It's tacky.

Nope.