

Would you buy this C++ book? Please help shape its structure and contents - cdmh
http://cdmh.co/12AO5dJ

======
wicknicks
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/

~~~
jbn
agreed, most people don't take the time to read such books... that's one
reason for the sorry state of the SW industry!

------
brudgers
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

------
thrush
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://meta.stackoverflow.com/questions/68647/setting-up-a-faq-for-
the-c-tag)

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

[http://stackoverflow.com/questions/388242/the-definitive-
c-b...](http://stackoverflow.com/questions/388242/the-definitive-c-book-guide-
and-list)

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

------
ysapir
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

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

------
bcoates
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"

~~~
brudgers
Rereading my comment, I was going to add an edit about examples. PG's two Lisp
books have non-trivial examples, among them PROLOG in Lisp and an inference
engine. Seibel's _Practical Common Lisp_ also contains reasonable examples -
though not as full blown as PG's.

My gut tells me that the Cpp book market is mature. Clojure is a language
where one could combine the literary tradition of Lisp with the sobriety of
the Java shop.

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

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

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

~~~
ysapir
Maybe it's not a typo. You can fill in the appropriate verb. ... plan to
improve ... ... need to improve ... ... hope to improve ... ... forgot to
improve ... ... don't intend to improve ... ... leave it to me to improve ...

~~~
clesenne
:-) It's been corrected now.

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

------
coherentpony
Nope.

