C++-books

[Stefan Ram]

There are some important C++-topics not covered in all
C++-books. So I tried to find a book that covers all of
the following topics (with no success, but - of course -
I am not able to access all the books):

- deviations of C++-arithmetics (int and double) from
mathematics, so that the reader can, e.g., assess the
possible values of »2000000000 < 3000000000« in C++
- sequence points and undefined behavior
- Argument-dependent name lookup
- RAII
- The rule of the three
- exception-safe programming

Could one say that a C++ text book is poor unless it
covers at least /all/ of the above topics?

Are there any topics you would like to add or remove from
the above »check list« for books? What does one need to know
about C++ before one can honestly call oneself a
»C++ programmer/developer«?

Of course, I take many topics for granted since they are
indeed usually covered in all C++ textbooks, such as, for
example, the addition operator for small int values, as in
»2+3«, or the while loop statement. So those do not have to
be listed.

(Only for readers of the ACCU-Reviews
Do you think that the quality of the ACCU-Reviews in the
decade 2001-2010 was as high as in 1991-2000?

 

[Victor Bazarov]

There are some important C++-topics not covered in all
C++-books. So I tried to find a book that covers all of
the following topics (with no success, but - of course -
I am not able to access all the books):

- deviations of C++-arithmetics (int and double) from
mathematics, so that the reader can, e.g., assess the
possible values of »2000000000< 3000000000« in C++
- sequence points and undefined behavior
- Argument-dependent name lookup
- RAII
- The rule of the three
- exception-safe programming

Could one say that a C++ text book is poor unless it
covers at least /all/ of the above topics?

No.

First off, the int(2e9) > int(3e9) (you did mean '>', did you not?) is
not specific to C++.

Second... Sequence points? Really? I don't know. A mention might be
OK, but full coverage? <shrug> Just give the rules, like "don't change
the object's value twice in a single expression", or "remember that
arguments are evaluated in an undetermined order". Tease them, get them
interested to learn more, send them to c.l.c++[.moderated]. :*)

Third, ADL. Probably covered in some book, like Koenig's "Accelerated
C++" (I don't have a copy).

RAII? Hmm... Is it C++ specific?

Then, the Rule of Three. Most like is covered in the "Effective C++".

And lastly, exception-safe programming is a technique, not a language
specific topic. Just like multithreading. There is no particular need
to have that in a C++ book, although a C++ book about it might actually
be useful, and there are some that exist.

Are there any topics you would like to add or remove from
the above »check list« for books?

I'd remove ADL. Or at least I'd place it in the "advanced" section.
What throwing an exception does (like stack unwinding) should be enough
for a thoughtful programmer to understand that only local objects are
destructed properly. Specifics of some arithmetic (and their
platform-dependence) should be mentioned, perhaps, but not too deeply,
since it's specific to the platform, let them figure it out by testing
or by reading the compiler docs. A properly written program does not
have undefined behavior, so UB does deserve a mention in a couple of
contexts with a footnote containing a link on where to learn more, if
the reader so desires.

I'd definitely add the library as the main focus after the language is
covered. Structure the book like the Standard, just use a better
(easier) language to present the material.

What does one need to know
about C++ before one can honestly call oneself a
»C++ programmer/developer«?

The grammar, the library (some of it). The rest is not C++ specific.
The book *might* contain some idioms and techniques, but that's not
generally required to make it a C++ textbook since techniques worth
knowing (and bragging about knowing) are often quite language-neutral.

[..]

V

 

[Öö Tiib]

RAII?  Hmm...  Is it C++ specific?

The technique was invented by Bjarne Stroustrup. But it can be used
elsewhere like in D and Ada too.

 

[Björn]

Could one say that a C++ text book is poor unless it
covers at least /all/ of the above topics?

IMHO there is no absolute criterion for goodness. It always depends on the
purpose. If, for example, you have to follow the strict coding standards of
railway safety systems you can leave out a lot of stuff. If, as another
example, you program an embedded system with its own special memory
allocation it might help to know something about placement new and allocator
requirements.

Of course, there is at least one general criterion for badness: If the book
teaches plain wrong things.

Are there any topics you would like to add or remove from
the above »check list« for books? What does one need to know
about C++ before one can honestly call oneself a
»C++ programmer/developer«?

I'd say you are a C++ programmer once you successfully programmed your first
C++ program even if it is a Hello World. The question is only if you know
enough to fulfill your current programming task in reasonable time or not
(including requirements on stability, manageability, and the like).

Regards
Björn

 

[Rune Allnor]

And lastly, exception-safe programming is a technique, not a language
specific topic.  Just like multithreading.  There is no particular need
to have that in a C++ book, although a C++ book about it might actually
be useful, and there are some that exist.

....which C++ books would cover exception-safe programming?

Rune

 

[Balog Pal]

...which C++ books would cover exception-safe programming?

Look up Herb Sutter for starters.

 

[Rune Allnor]

Look up Herb Sutter for starters.

His 'Exceptional C++' books?

I have seen them mentioned at amazon.com, but the subtitles
which involved words like 'puzzles' and 'solutions' gave
the impression that these were more like excercises for
use in classes or courses.

Rune

 

[Balog Pal]

His 'Exceptional C++' books?

I have seen them mentioned at amazon.com, but the subtitles
which involved words like 'puzzles' and 'solutions' gave
the impression that these were more like excercises for
use in classes or courses.

http://gotw.ca/

the "exceptional" books are based on GOTW http://gotw.ca/gotw/index.htm that
you can read just there. A plenty of items are reltated to exception safe
stuff. And all are worth reading.

Check out the articles, Herb wrote several on exception safety before
shifting to concurrency.

 

[MikeP]

The technique was invented by Bjarne Stroustrup.

I would say that it was found more than invented. It seems to have fallen
out from what previously existed in the language and that was the scratch
to the itch. Does everyone invent scratching the first time they have an
itch? That said, it's better to be proactive and not go into the poison
ivy patch to begin with rather than being reactive and doing all that
scratching and making the situation even worse.

 

[Michael Doubez]

I would say that it was found more than invented. It seems to have fallen
out from what previously existed in the language and that was the scratch
to the itch.

IMHO you dismissed too quickly the theory of invariants that was the
ground for many C++ features. The constructor/destructor mechanism is
essential to allow the design of class in canonical form. That is the
heart of RAII.

Does everyone invent scratching the first time they have an
itch? That said, it's better to be proactive and not go into the poison
ivy patch to begin with rather than being reactive and doing all that
scratching and making the situation even worse.

Except when someone invent a tool to make the scratch easier; he his
effectively the inventor of the scratching device.