Rating:  - A solid foundation in C++, and then some.
This book about Standard C++ is very unique, in that it covers more than just the syntax of the language. Eckel goes into detail as to *why* things work the way they do, and even gives insight into what problems were encountered that led to the implementation of certain language features. True, this makes for a very wordy book, but the end result is that the reader understands the language as a whole, not just the syntax of it.
Eckel spends a great deal of time lecturing, and his experience in teaching the language shows in the writing of this book. Examples are clear and very concise - he does not fill his examples with unnecessary fluff to make them 'cool' but instead focuses only on the functionality that he is presently covering.
One particular strength of this book is coverage of the stream classes, which was a very strong point in the first edition as well.
This book does not cover everything, but covers enough that someone who is serious about learning the language can use this book to build a rock-solid foundation. There is a volume 2, available on Eckel's website, that covers the Standard Template Library (STL) and other more advanced topics.
If you only buy one book on C++, this is *the* one to buy.
Rating:  - One of the best intros to C++ on the market.
Bruce Eckel, Thinking in C++ vol. I (Prentice Hall, 2000)
This is what so many other books about the process of programming C++ could have been. Eckel uses the most up-to- date C++ standards, the strictest programming techniques, and takes enough time to explain both the how and the why of the things that he's talking about in enough detail that the user, while perhaps needing to read certain sections two or three times to really get the gist of them, should have a thorough understanding of the subject by the time the reader has finished the section. This leads to a complete absence of the usual "here's what to do, don't worry about why you're doing it until we get to chapter X" found in most programming books. It also stresses programmers developing their own programming style, but imposes the strictures called for by the ANSI C++ standard. Sometimes too much freedom IS a bad thing, and that's the case with the vast majority of books on C++ programming. Individuality is important, but clarity of code is important, too.
The book has few shortcomings. The section on namespaces could be a little clearer considering a number of the prospective readers of this book are less familiar with them than they are with most of the other concepts covered here, for example. But the shortcomings are few and far between.
The most important thing about the book, though, is that Eckel uses the book's style and presentation as a physical model of abstraction, the most important move any programmer makes from a procedural language to an object-oriented language. The astute reader will pick up from Eckel's discussions of the philosophy of programming an understanding that not everything is about code, and that code is not the be-all and end-all of the programmer's job. A lot of it, especially in the design stages, is concept. Many of us in today's workforce, especially those who have spent whole careers doing nothing other than modifying existing code, forget that all too often. We're stuck in reactive environments, where the company believes that keeping things running is more important than improving them. A grounding in the design concepts presented here may allow more adept programmers to turn a reactive situation into a proactive one--being able to keep things running at the same time they're being made better. And that's how it should be. ****
Rating: - Why no diskussion about pointers in the book?
The book is brilliant, but....
Why isn't there a comprehensive paragraph explaining the
concept of pointers?
Pointers and deeper sense:
Pointer as function parameters or return type:
What does Call by Reference mean?
If you use pointers as function parameters or return types the call mechanism
"Call by Reference" relates to the objects the pointer points to, not to the "pointer(address)" itself if you use a pointer
in the call and even not to the address of any structure/ object in memory.
Inside a called function you can use pointerarithmetic to get access to structure/arrayelements or whatever.
But, you will never change the address of any storage object this way.
Addresses of objects are "called by value"! Objectaddresses are copied to the stack.
The objects/variables themselves are called by reference!
This way you can change their values inside of the called function and use the
changed values after the function has returned. You can apply pointerarithmetic to a pointervariable
inside a called function and walk through the different elements of a memorystructure.
Pointerarithmetic here does not mean:
- to change the address of the pointer itself neither inside the function call nor (because it is called call
by reference) to reflect the change in the calling function.
example:
void func1 ( ) {
int val = 3;
int * ptr = &val;
func2 ( ptr );
}
void func2 ( int * ptrin ) {
ptrin++;
}
a debug session would tell you:
before the func2(ptr); call:
&ptr: 0x0012ff78
ptr: 0x0012ff7c
*ptr: 3
inside func2 one step behind ptrin++:
&ptrin: 0x0012ff28
ptrin: 0x0012ff80 = 0x0012ff7c + 4
*ptrin: undefined
after the func2() call returns:
&ptr: 0x0012ff78
ptr: 0x0012ff7c
Call by reference here does not mean:
- The changed pointer value inside the called function can be used after the function call has returned
in the calling function. The objectaddress is copied to the stack and can be used inside the function.
But, any changes of the pointervalue are not reflected back to the calling function!
If you want to return a changed pointervalue you can:
- return a pointer
void main(void)
{
int val = 3;
int * ptr = &val;
std::cout << *func2 (ptr ); // outputs 3
}
int * func2 ( int * ptrin ) {
ptrin++;
return --ptrin;
}
-return a reference to a "pointer":
// this is not a brilliant solution, you don't get a pointer back
// can be omitted
void main(void)
{
int val = 3;
int * ptr = &val;
std::cout << func2 (ptr ); // outputs 3
}
int & func2 ( int * ptrin )
{
ptrin++;
return *(--ptrin);
}
use a "real" call by reference, call parameter gives back changed pointer
void main(void)
{
int val[2] = {3,4};
int * ptr = val;
func2 (&ptr );
std::cout << *ptr; // outputs 4
}
void func2 ( int ** ptrin ) {
(*ptrin)++;
}
-return a reference to a pointer, Bruce Eckels version, p 478 Tic2Vone.pdf Thinking in C++,
Volume 1, 2nd Edition,
int main(int argc, char* argv[])
{
int val[2] = {3,4};
int * ptr = val;
func2 (ptr);
std::cout << *ptr; // outputs 4
return 0;
}
void func2 ( int *& ptrin ) { ptrin++; }
Regards.
UK
Rating: - Great book, but it depends on where you are coming from
Bruce Eckel has done a great job with the book. He clearly has put some thought into how to structure the book, and it shows with each chapter focused on one major topic. The explanations are clear (to me anyway), and greatest of all, he goes into decent amount of depth, unlike many other c++ books out there. However, I have two minor problems with the book. The order of the chapters could probably be revamped; inheritance and composition are only introduced in chapter 14, way too late IMO. If you are the type of programmer who likes to get writing code straight away, this book is not for you. Also, I think some of the examples and exercises are bit trival and boring, but that could be due to Bruce's aim to keep everything simple and understandable, and let the reader find the "real world" problems. But overall, a good book to learn c++ if you have some background in C or java. BTW, to put my review into perspective, I am a computer science student learning c++ and MFC in my spare time because my university don't teach these things.
Rating:  - More bad than good
Having used this book for three semesters to teach OOP and C++ programming, we are replacing it as the required reading. Feedback from the students has been dismal and most of the instructors have abandoned it except for reference, for which it serves poorly. Here's why:
The order that the topics are presented is not useful for either novices or experienced C programmers. Yes, there's a lot of material in there, but it is disconnected such that to teach a subject thoroughly requires tedious and non-intuitive jumping around in the book.
Also, the book does not cover all of the topics and language/library features that one would expect in a modern approach to C++ and OOP. To require two volumes to teach the rudiments of the language is an indication that something is wrong with the author's approach. If you have learned C++ from this book, you have not really learned C++.
Along the same lines, the author's style is long and drawn out. The two volumes probably could have been put into one (more effective) volume without all the distractions the author puts into the text. This, coupled with a change in the order of topic coverage and more contiguous focus on individual subjects, would make this a very useful book to learn C++ and OOP.
On a personal note, I have never liked the author's writing style in his previous books, though I respect his depth of knowledge and intent.
|
