Good C++ book

[PAolo]

Hi,

I am a good C programmer, and I am able to use C++ at a "not expert"
leve. I am lloking for a good C++ book that can teach me all the
aspect of the language, possibly explaining more complex object
scenarios (multiple inheritance, abstract class and virtul methods,
templates, etc) in a "theoretical" way too. I need a good section on
STL too (well not a cut and past of the reference... ).

I looked around on this group and searched on book selling sites. I
didn't find much that matches my needings.

Can anyone provide me some good suggestions?

Thnx
Paolo

 

[Victor Bazarov]

I am a good C programmer, and I am able to use C++ at a "not expert"
leve. I am lloking for a good C++ book that can teach me all the
aspect of the language, possibly explaining more complex object
scenarios (multiple inheritance, abstract class and virtul methods,
templates, etc) in a "theoretical" way too. I need a good section on
STL too (well not a cut and past of the reference... ).

I looked around on this group and searched on book selling sites. I
didn't find much that matches my needings.

Can anyone provide me some good suggestions?

AFAIK, no such single book exists. Get yourself a copy of TC++PL
Special Edition, a copy of the "Effective" series by Meyers, a copy
of "C++ Templates" by Vandevoorde and Josuttis, a copy of "The C++
Standard Library" by Josuttis, a copy of "Modern C++ Design",
a copy of "Multi-Paradigm Design for C++" by Coplien, a copy of
each "Exceptional" book by Sutter, his "C++ Coding Standards"...

Now, I've just named you books from my shelf (and not all C++ books
I have, mind you). Just those will drain your book budget for the
next couple of years and will probably take you a few years to read
through. Which just suggests that you really can't do it in one
swoop or one shot.

Good luck!

V

 

[utab]

Hi,

I am a good C programmer, and I am able to use C++ at a "not expert"
leve. I am lloking for a good C++ book that can teach me all the
aspect of the language, possibly explaining more complex object
scenarios (multiple inheritance, abstract class and virtul methods,
templates, etc) in a "theoretical" way too. I need a good section on
STL too (well not a cut and past of the reference... ).

I looked around on this group and searched on book selling sites. I
didn't find much that matches my needings.

Can anyone provide me some good suggestions?

Thnx
Paolo

C++ primer by Lippmann is a quite readable text, and Accelerated C++
will fit you best If you know C. The books suggested by Victor Bazarov
are all good books but these two are the best bets in my opinion where
Accelerated C++ starts with a lot of examples from STL and C++ primer
gives deeper explanations. TC++PL is the definitive next step I
suppose...

HTH,

 

[red floyd]

Hi,

I am a good C programmer, and I am able to use C++ at a "not expert"
leve. I am lloking for a good C++ book that can teach me all the
aspect of the language, possibly explaining more complex object
scenarios (multiple inheritance, abstract class and virtul methods,
templates, etc) in a "theoretical" way too. I need a good section on
STL too (well not a cut and past of the reference... ).

I looked around on this group and searched on book selling sites. I
didn't find much that matches my needings.

Can anyone provide me some good suggestions?

In addition to what Victor suggested, I recommend "Accelerated C++" by
Koenig and Moo.

Another thing to realize it that you may (probably will) have to
"unlearn" many programming habits you learned in C. The key thing being
memory management. You almost *NEVER* want to deal with raw pointers in
C++... The Standard Library provides almost everything you need to avoid
it -- if you need dynamically sized arrays, use std::vector. If you
need a linked list, std::list provides it for you... etc... To me, this
was the hardest part of learning C++, was to think in a C++ style rather
than a "C with Classes" style.

 

[gnuyuva]

Hi,

I am a good C programmer, and I am able to use C++ at a "not expert"
leve. I am lloking for a good C++ book that can teach me all the
aspect of the language, possibly explaining more complex object
scenarios (multiple inheritance, abstract class and virtul methods,
templates, etc) in a "theoretical" way too. I need a good section on
STL too (well not a cut and past of the reference... ).

I looked around on this group and searched on book selling sites. I
didn't find much that matches my needings.

Can anyone provide me some good suggestions?

"Accelerated C++" is the way to go.. Please read the same first.

 

[Jeff Schwab]

[Victor said something to the effect of "that's like deciding to climb
Everest this weekend, you need to rethink the amount of time involved,
here are some good leads, and may the force be with you."]

In addition to what Victor suggested, I recommend "Accelerated C++" by
Koenig and Moo.

I've seen that book highly recommended for beginners a bajillion times.
Is it still worth reading by practicing C++ developers, or is just
meant to be a gentle introduction that gives a better foundation than
the "C++ By Numbers" style books?

 

[Victor Bazarov]

[Victor said something to the effect of "that's like deciding to climb
Everest this weekend, you need to rethink the amount of time involved,
here are some good leads, and may the force be with you."]

In addition to what Victor suggested, I recommend "Accelerated C++"
by Koenig and Moo.

I've seen that book highly recommended for beginners a bajillion
times. Is it still worth reading by practicing C++ developers, or is
just meant to be a gentle introduction that gives a better foundation
than the "C++ By Numbers" style books?

It's an interesting thought. And I've thought it for all of the
last minute. Here is what came out of it.

If you give a practicing carpenter a book on how to drive nails or how
to saw wood, he may even humour you and give it a read (when he has
a bit of time free from practicing carpentry). However, even if there
are gems in the book that our carpenter could use in his everyday wood
sawing nail driving activities, he is likely to miss them again while
reading the book in that bit of spare time. Unless a more experienced
carpenter comes along, looks at our carpenter's work and gives a few
life-changing suggestions (like, "oh, man, have you been holding that
saw upside down"), the real need our carpenter has is a good manual on
how to use that pneumatic nail driving thing or that electical table
saw.

Skimming over a beginner book is a waste of time because anything with
a deep enough meaning is most likely going to be skipped over (if there
is anything with a deep meaning in a beginner book), because sometimes
things get skipped over when you skim over a book. Reading the book in
such a way that nothing with a deep meaning escapes the trained mind
is also a waste of time because most of the time is spent while trying
to find the deep meaning in something that does not have it. It's
a beginner book, FCOL.

So, for me, a prerequisite for getting the most use out of a beginner
book would be *unlearning* what you already know first. Is that at
all possible? I doubt it. Especially if you don't have enough time
to begin with, anyway.

V

 

[Jeff Schwab]

I am lloking for a good C++ book that can teach me all the
aspect of the language, possibly explaining more complex object
scenarios (multiple inheritance, abstract class and virtul methods,
templates, etc) in a "theoretical" way too. I need a good section on
STL too (well not a cut and past of the reference... ).

[Victor said something to the effect of "that's like deciding to climb
Everest this weekend, you need to rethink the amount of time involved,
here are some good leads, and may the force be with you."]

In addition to what Victor suggested, I recommend "Accelerated C++"
by Koenig and Moo.

I've seen that book highly recommended for beginners a bajillion
times. Is it still worth reading by practicing C++ developers, or is
just meant to be a gentle introduction that gives a better foundation
than the "C++ By Numbers" style books?

It's an interesting thought. And I've thought it for all of the
last minute. Here is what came out of it.

If you give a practicing carpenter a book on how to drive nails or how
to saw wood, he may even humour you and give it a read (when he has
a bit of time free from practicing carpentry). However, even if there
are gems in the book that our carpenter could use in his everyday wood
sawing nail driving activities, he is likely to miss them again while
reading the book in that bit of spare time. Unless a more experienced
carpenter comes along, looks at our carpenter's work and gives a few
life-changing suggestions (like, "oh, man, have you been holding that
saw upside down"), the real need our carpenter has is a good manual on
how to use that pneumatic nail driving thing or that electical table
saw.

Skimming over a beginner book is a waste of time because anything with
a deep enough meaning is most likely going to be skipped over (if there
is anything with a deep meaning in a beginner book), because sometimes
things get skipped over when you skim over a book. Reading the book in
such a way that nothing with a deep meaning escapes the trained mind
is also a waste of time because most of the time is spent while trying
to find the deep meaning in something that does not have it. It's
a beginner book, FCOL.

So, for me, a prerequisite for getting the most use out of a beginner
book would be *unlearning* what you already know first. Is that at
all possible? I doubt it. Especially if you don't have enough time
to begin with, anyway.

Thanks; I suspect your analogy is a good one. There do seem to be an
awful lot of professional programmers still "holding the saw upside
down" though. (Btw, that image made me laugh.)

I guess the short answer is that in the amount of time it would take to
find the gems in the book, someone with experience can probably learn
more in c.l.c++.

 

[noagbodjivictor]

Go on www.pragsoft.com, there is a free book there for the basics and
class stuffs.
As for the STL, I think you should go by what have been suggested to
you.

 

[PAolo]

Go onwww.pragsoft.com, there is a free book there for the basics and
class stuffs.
As for the STL, I think you should go by what have been suggested to
you.

Thnx everybody. I will start spending my money on some new book next
days

Paolo

 

[Nick Keighley]

Another thing to realize it that you may (probably will) have to
"unlearn" many programming habits you learned in C.  The key thing being
memory management.  You almost *NEVER* want to deal with raw pointers in
C++...

so how do you set up complex data types like trees?
Or collections of large objects?

 

[Jeff Schwab]

so how do you set up complex data types like trees?
Or collections of large objects?

With typedefs for appropriate pointer types, e.g. tree::node_ptr, which
may be indeed be a node*, but may not be.

 

[Michael.Boehnisch]

so how do you set up complex data types like trees?
Or collections of large objects?

If you cannot avoid pointers for some reason, restrict them to low-
level aspects of your solution and make them private.
E.g. for trees, hide the pointers in a generic tree class, offer
iterators as an interface for traversal, search and modification. The
user of the tree class should not (need to) see any pointers. The STL
demonstrates that this leads to efficient and flexible constructs for
dynamic container types (std::set<> and std::map<> are implemented
using trees, no pointers exposed to the user of the classes).

In C it was very custom to use pointers excessively, and C++ offers
good alternatives for most common use cases (e.g. std::string instead
of char*, or std::vector<T> instead of T*). Memory leaks due to
forgotten free() calls are much less frequent with this style of
programming. Pointers do have their place in C++ but if there is a way
around, the alternative is IMHO the better approach.

best,

Michael

 

[dave_mikesell]

so how do you set up complex data types like trees?
Or collections of large objects?

Smart pointers.

 

[André Castelo]

Well, i've been using Thinking in C++, by Bruce Eckel. The chapter
about iostreams and about the containers are really good. What you
guys think of it ?

 

[Nick Keighley]

Nick Keighleywrote:



With typedefs for appropriate pointer types, e.g. tree::node_ptr, which
may be indeed be a node*, but may not be.

to me that still looks like a pointer. Hiding it behind a typedef
doesn't make it not a pointer.

 

[Nick Keighley]

If you cannot avoid pointers for some reason, restrict them to low-
level aspects of your solution and make them private.
E.g. for trees, hide the pointers in a generic tree class, offer
iterators as an interface for traversal, search and modification. The
user of the tree class should not (need to) see any pointers. The STL
demonstrates that this leads to efficient and flexible constructs for
dynamic container types (std::set<> and std::map<> are implemented
using trees, no pointers exposed to the user of the classes).

ok that makes sense. They no longer are "raw" pointers
as they are hidden in a class that is entirely responsible
for them.

In C it was very custom to use pointers excessively, and C++ offers
good alternatives for most common use cases (e.g. std::string instead
of char*, or std::vector<T> instead of T*). Memory leaks due to
forgotten free() calls are much less frequent with this style of
programming. Pointers do have their place in C++ but if there is a way
around, the alternative is IMHO the better approach.

thanks

 

[Nick Keighley]

Smart pointers.

I think you'd need to use some of the boost smart pointers
and they aren't in the standard (yet)

 

[Ian Collins]

I think you'd need to use some of the boost smart pointers
and they aren't in the standard (yet)

Why, it's a simple enough job (and an excellent learning exercise) to
roll your own.

 

[dave_mikesell]

Why, it's a simple enough job (and an excellent learning exercise) to
roll your own.

As a learning exercise there's certainly benefit to rolling your own.
But in production code I use Boost. And aren't they going to be in
the next standard? std::auto_ptr cut down the trees years ago.