Applied C++: Techniques for Building Better Software

Applied C++: Techniques for Building Better Software Cover
ISBN-100321108949
ISBN-130076092017523
AuthorsPhilip Romanik,Amy Muntz
PublisherAddison-Wesley Professional
Publication Date2003-05-02
Pages352
Dewey Decimal005.133
Rating3.50
Categories

Absolute junk

I wholeheartedly agree with the reviewers that gave this book 1 star. From page 12, when the first class in the book (apImage) itself is incompletely defined (the definition "pixels_" is missing) it is a steep and fast ride downhill. This book is going to be returned -- this would be the first time I am returning a book.

Good intro to 2D image processing, very nice framework

As a programmer who had never done any image processing before, this book helped raise my knowledge from zero to a reasonably good understanding of 2D image processing, and provided me with a very useful framework that I am using everyday in my job.

I feel that the book also does a good job demonstrating template techniques, and provides a good overall SW development process to follow.

The authors have been very responsive to questions and problems, which I greatly appreciate.

The only thing I really didn't like was the lack of makefiles for the non-template code. I would have liked to have a makefile that creates a library automatically. I ended up doing it myself, which frankly wasn't all that difficult.

a solid C++ software development book

There are many books about C++, and there are many books about software development. This book is one of the best I've seen at combining the two topics. The authors are obviously real-world developers because they offer real-world solutions and approaches, unlike the authors of many development-oriented books who apparently live in ideal worlds where every project goes perfectly.

C++ continues to be one of the most popular programming languages ever, and I highly recommend this book not only to any developer who writes C++ applications for a living, but also to team leaders and architects who want to make sure their teams are writing the best code possible. I can say based on years of experience that the techniques offered in this book are critically important for real-world, robust, production-quality C++ applications.

Nothing really new in this book

I was a little bit disppointed with this book, especially when I look at other books in this serie.

Although I cannot find any point totally wrong in this book, I cannot find anything that I did not already knew. I believe that this book is best suited for people rather new to the profession, or maybe even more to people who only use C++ as a better C, and would like to start using C++ specific features.

Maybe in this case, they can find in one book what usually requires at least three books. But that would not take them as far as those three books would do.

I think my biggest disappointment with this book, is that when the authors discuss about their design, they explain how it work in details, sometime they even suggest why they choose this possibility, but they almost never review other possibilities to weight to pro and con of each one.

The text is sometime a little bit tedious to read (the kind of repetition that one would expect in documentation where everything has to be detailled, but not in book).

Finally, there are some technical points where I disagree (or where I beleive a better solution exists, and should at least be evoqued):
- The use of prefix instead of namespace, making code more difficult to read, and I believe even more innapropriate in a book than in real life
- Not a word about the template techniques that might unroll the loops they tediously unroll manually
- The use of trait associated with pixel type could probably ease the use of the library (for instance, specifying the type to be used by default when adding two pixels)
- I think it is rather surprising the way the authors complain about a change in the standard from a well defined behaviour to a buggy one that broke their previous design on purpose (you may think I am cynical, but they _complain_ about this special point at least three times in the book (for their function add2), but never explain why the standard is written as it is)

Great idea, terrible execution

A true disappointment. Other books in the series (Sutter, Alexandrescu, Koenig & Moo) have been instant classics, but I get the feeling that Stroustrup didn't really read this one (he's the "series editor", not the "book editor", and not mentioned in the acknowledgements). If he had, I doubt he'd let the following gems see the light of print:

-- "It is easy to spend too much time researching the problem in hopes of finding the most efficient STL component. For example, we could have also chosen to use std::set, as this matches the requirements of our object very closely. ...If you have not used many STL components, you will soon discover that you end up using only a small subset of objects..." (p. 107) In the context, the authors have just selected a std::map whose value type they plan to ignore completely. The C++ standard library is TINY compared to most other currently popular languages, and much more consistent. Wouldn't it be more worthwhile to take a second to learn about std::set just this once, so you'd remember it next time?

--"Namespaces were added to the language to prevent name collisions, but aside from their use in the standard C++ library, we have seen little use of them elsewhere." (p.74) Then, they go on to advocate prefixing all class names, a la "apString". Why not just make an "ap" namespace, if you realize that that's what namespaces are for? Maybe they haven't seen any use of namespaces because they systematically avoid them out of sheer stubbornness?

The book is filled with other inane advice displayed in special boxes: "If you decide to graphically depict your object relationships, take advantage of both axes to represent them." Darn, why didn't I realize this sheet of paper was two dimensional? Glad I bought the book!

The only remotely redeeming factor is the stuff on image processing, but any two-bit text devoted to image processing would be better. Heck, just about anything you could dig up on Google would be just as good, I imagine.

Finally, the included CD stinks. After all that, what you get is essentially a makefile with some lousy code--not even a dummy application that lets you see it in action.

I wish I could give it 0 stars, but it doesn't seem to be possible. Don't waste your money--almost any other AW book on C++ would be a better choice.