The title immediately made me doubtful, turning to the back-cover only deepened my sense of unease. Here is the start of the back-cover blurb:

My first problem is that optimisation is always something that should not be taken lightly, indeed we should avoid it unless testing shows that it is necessary. All forms of hand optimisation tend to make code more fragile and harder to maintain, going down to assembly level is an even further step in the direction of maintenance problems.

Attempting to use assembly code as a way to optimise high-level anything seems to be entirely wrong to me. From where I am sitting, assembly code belongs in the lowest layers if at all.

Writing mathematical functions is an extraordinarily skilled task, and one that I am more than willing to consign to talented library implementers. I have some sympathy with regards to working with strings were that to mean using std::string, but it does not, it refers to using nul-terminated arrays of char.

So let me turn to the content. The first thing that quickly becomes apparent is that for the most part the author is not actually writing C++ nor even Visual C++, he is writing C with a small spicing of C++ and a large dose of Microsoft extensions. What puzzles me is why he is using _asm instead of the C++ asm keyword where he is putting assembly code into C++ source code. Maybe that is a VC++ issue.

The assembly code parts of the book seem to be fine (but remember that for the last ten years my attitude to knowing assembler code for a machine is that its main value is in identifying bugs in the compiler. The author covers both free standing assembly code in their own modules that will be linked in at link time, together with assembly code embedded in C++.

The author's optimistic estimate of the potential improvement by using assembly code is around 17%. That should be balanced with the way that assembly code will kill some of the optimisations available to Microsoft's most recent link technology. I also think it is being more than a tad optimistic and based on measurement of limited parts of an application rather than on overall performance.

However let me accept the author's estimate, and then pose the question as to how many months would go by before the current hardware was providing more than a 17% performance improvement. There are very few applications where maximal performance is an absolute requirement. In most cases once a certain level of performance has been achieved further improvements are of little added value.

I think that a much shorter book showing the reader how to add assembly code to already well written C++ would be much more to the point. Even such a book would have (or should have) a very limited sale.

If you absolutely need to write assembly code for your C++ application and are already a good C++ programmer you can probably distil what you need to know from reading this book. However most C++ programmers would do better to spend the equivalent time improving the quality of their C++.

I guess the amateur games programmers might find something useful in this book. The professional ones have to worry about issues of portability which makes use of inline assembly code problematic.