Mike and Phani's Essential C++ Techniques

Reader yamla writes with the following review of Mike and Phani's Essential C++ Techniques from APress. Yamla finds a few bright spots in this book, but also several weaknesses. Read on to see whether you fit into the group he says would find this book useful.

Mike and Phani's Essential C++ Techniques
author	Michael Hyman and Phani Vaddadi
pages	239
publisher	APress
rating	2/10
reviewer	Chris Thompson
ISBN	1893115046
summary	This book is useless to any other than the beginning Visual C++ 6.0 students.

The major problem

This book has one killer problem: It is not aimed at C++ programmers. Let me be more specific here; it is not aimed at ANSI C++ programmers. Instead, it is aimed at Microsoft Visual C++ 6.0 programmers.

Is this a big deal? Yes. The cover of the book is rife with mentions of C++. It even mentions ANSI C++. There is one, and only one, reference to Visual C++ on the cover of the book. Even inside, the index lists only three references to Visual Studio, none to Visual C++. With quotes such as 'Hundreds of tips and techniques for advanced C++ programmers' on the cover, I was very surprised to realise this book is for Visual C++ 6.0 users only. At best, the cover of this book is misleading.

The rest of this review (and the book's rating) assumes you are still interested in the book. You therefore use only Visual C++ 6.0 and have no plans to upgrade.

Other problems

For a book apparently aimed at intermediate and advanced programmers, this book contains a lot of tips that any experienced beginner should already know. Techniques such as ensuring you never return a pointer to an automatic variable really have no place in a book with the stated audience. Really, this book would be more suited to programmers who were still learning C++.

Except there are a number of other issues that make this book poorly suited to people learning C++. Instead of using standard C++ strings, this book chooses NULL-terminated C strings. Files are not included the C++ way (cstdio instead of stdio.h, iostream instead of iostream.h). The STL is not mentioned at all, with dynamic arrays having their own chapter rather than a simple mention of vectors and with an entire chapter devoted to code for sorting instead of showing the programmer how to use the STL sorting algorithms. The smart pointers? Either use the built-in autoptr or use boost.org's vastly superior implementation.

Some good stuff

This book is not completely without redeeming qualities. Many of these techniques are good and useful. If you are a new Visual C++ 6.0 programmer and you are learning from a substandard text, you may find this book covers some of the shortfalls of your other textbook. Similarly, if you are taking a class in C++ and your instructor is particularly lousy, this book could help you out.

Summary

Mike and Phani's Essential C++ Techniques is useless to any other than the beginning Visual C++ 6.0 student. It ignores ANSI C++ to focus instead on Microsoft's implementation. It contains a number of stylistic problems, relying far too heavily on C instead of the facilities provided by C++. And finally, it only covers techniques any reasonably experienced C++ programmer should already know.

---

You can purchase Mike and Phani's Essential C++ Techniques from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Re:Bright Spots?

[yamla]

I reviewed it because maybe I could help stop other people from buying the book. I absolutely agree that Scott Meyers's books are excellent. I wish he'd write one on templates and generic programming but Modern C++ Design by Andrei Alexandrescu (with a foreward by Meyers) is good enough for me.

Re:More specifics on VC focus

[koh]

The most common form of "bending towards VC++" is to give many examples that use ClassWizard's "features".

For instance, if you read the developper's guide from Microsoft and lookup how to bind an event to, say, a button, the devguide will advise you to double-click the button in the dialog editor then use ClassWizard's moronproof dialog boxes, instead of directing you to add a method and a message map entry to your container class...

This IHMO heavily contributes to the fact that many people now can't understand how C++ frameworks work. They're only able to invoke ClassWizard and let it do the job. Of course, there are things ClassWizard cannot do, but in that case... they won't implement the feature at all and whine about "support not present".

Kickasso reviews 99.99% of all C++ books at once!

[Kickasso]

They are crap.

In the beginners department you can't beat Accelerated C++ [acceleratedcpp.com] by Koenig and Moo. For more advanced programmers there is Scott Meyers.

Not so great

[Rossalina W Sanchez]

I found this book a curious pot pourri. By no stretch of the imagination is this book going to be much use to its declared readership--advanced C++ programmers. No one in that category needs to be told such simple things as that classes designed with the expectation that they will be derived from should have virtual destructors.

Code in books such as this one should be well written. In many places the authors provide before and after code in support of their guidelines/techniques. What do you think of the following as an 'after' (it does not matter what the technique is that is being written about):

class baseClass {
public:
baseClass() : fltSalary(0.) {}
char *szName;
float fltSalary;
};
It becomes clear, long before the chapter on using Assembly that the authors are writing about C++ on a very specific platform and based on experience with a specific implementation of C++. They have little familiarity with what are rapidly becoming standard techniques among more experienced C++ users. Couple this with a pre- occupation with what I might call micro-optimisations and we finish up with a book that not only offers nothing to advanced C++ programmers, and very little to experienced ones but it also provides a dangerous mindset for inexperienced programmers.

What I find frightening is that the authors are clearly writing about the way they write C++ code. Frankly they are, in my opinion, still at the point where they have a good deal to learn about C++ techniques from the real experts of the industry.

Finally let me quote 'Technique 129: Avoid the CRT If You Can' in its entirety. I think that may give you the sense of why I think this book is wholly misguided.

Re:Difference between MS and ANSI?

[Viking Coder]

Microsoft is not particularly ANSI C++ compliant. And it's STL implementation is fairly lousy. That makes it hard to both port code TO and FROM MSVC++, because you expect certain standardized behavior, and Microsoft's implementation of C++ is not correct in all cases. (Note that, until fairly recently, NO C++ implementation was ever "correct" according to the standards.)

It basically means that there are perfectly legal constructs in ANSI C++ that are not allowed in MS Visual C++.

The best example I can name off the top of my head is that something like this is not allowed in MSVC++:

template <class Type>
Type myFunction()
{
Type result;
// do calculations at the precision of Type
return result;
}

int r = myFunction<int>();
// supposed to be allowed in ANSI C++,
// but it isn't in MSVC++. They just can't
// parse it, for whatever reason.

And there are things that MS Visual C++ allows by default that it's not supposed to. The most glaring example I can come up with off the top of my head is:

// do something in a loop with variable i
for (int i = 0; i < 10; ++i)
{
}
int other = i;
// re-use the variable i - NOT ALLOWED
// i is supposed to lose scope after
// the above for-loop

As an aside, the Intel compiler is far better.

Re:More specifics on VC focus

[yamla]

I initially included examples of how it was bent so completely toward VC++ but it really made the review hard to read.

It is comments such as 'Always use at least warning level 3', with information on how to select it in Visual C++ but without any note that this isn't an ansi-C++ technique, that really annoyed me. The book is littered with techniques that would only work in Visual C++ (and only with Visual C++ 6.0). There are sixteen chapters and I was able to find several examples in pretty much every single chapter. This was all the worse because the book appears to be targetted at ansi-C++.

Re:Difference between MS and ANSI?

[alefbet]

Microsoft Visual C++ has a few extensions to the language, mostly inherited from its extension to the C language, and nothing you can't get by without (unless you are looking at its "WinMain" function or other extensions designed specifically for programming under windows).

On the other hand, there are some problems with the language and libraries if you try to compile code ported from another compliant compiler.

• for loops do not create a new scope (resulting in error messages if you reuse/redeclare for loop counters). I believe this is fixable with compiler flags in Visual Studio.NET. (Technically it's fixable with compiler flags in Visual C++ 6, but the header files won't compile if you try it.)
• Visual C++ does not support Koenig lookup (good riddance IMHO, except the standard has it so I think Visual C++ should at least have a compiler option to use it). It is implemented for operator overloads, but not general functions.
• Visual C++ doesn't support partial template specialization (which I've really missed from time to time when writing reusable templates).
• Visual C++ can't parse the syntax for declaring a template member function and defining it outside the class body (not to be confused with a member function of a template). All such template member functions must be defined inline, causing some clutter in the class definition.
• The auto_ptr implementation is missing a critical member function (causing me to use it with STLport to get proper functionality of pieces of the standard library). You may be able to solve this problem by purchasing the latest version of the Dinkumware libraries to use with Visual C++. (Dinkumware provided the version of the libraries that ship with VC6.)

I've probably missed stuff. This is just what I've generally run into.

Re:Not so great

[Anonymous Coward]

If you're gonna quote another review, at least attribute the source!

http://www.accu.org/bookreviews/public/reviews/m /m 002067.htm

the for loop thing

[oliverthered]

SFAIK variable scope is a bit weird in ANSI C,

for(int i;...){
}
i=123;
is valid ANSI C (for some strange reason)

for(int i;...){
j
}
j=123;

is not valid
{
for(int i;...){
}
}
i=123;
is not valid

the same is true for if and switch

this is a pain because of reuse.
for(int i;...){
}
for(int i;...){
}

is invalid ANSI C because i is still in scope in the second for loop.

Book is from 1999

[1st1]

It is an old book: September 1999

Re:Difference between MS and ANSI?

[spectecjr]

Both your examples work great with the current Microsoft compiler. Especially the for-loop issue, which actually causes more problems than it solves if you're at all trying to optimize things, but hey. At least you can turn it on/off with a switch.

Simon

Re:Pot-kettle scenario

[yamla]

I would hardly say there is nothing wrong with using C constructs such as null-terminated strings and printf(). I would agree that there are many times that you do want to use such constructs, however, and I often do in my code. However, a book targetted to C++ programmers should use C++ constructs where appropriate. Use a null-terminated string if there's a good reason for it, of course, but otherwise, why not use the C++ string? And why, for God's sake, have a whole appendix on implementing your own string class in C++? It seemed to offer far less than the standard string class and didn't provide any advantages. I can see examining a class like this if you are trying to learn C++ and want a better understanding, but for an advanced C++ programmer?

Dude.

[Kickasso]

Read a good beginner's book about C++ and update your card accordingly. It's got more problems than I care to enumerate, and that's in sample sections only.

Re:Pot-kettle scenario

[Hortensia Patel]

> I don't know of any compiler that is 100% compliant

I think the EDG frontend is pretty much there these days. I don't doubt it still has the odd bug, but they do now have an implementation of "export", which has been the real ball-and-chain attached to the leg of any team attempting to hit full compliance. The Comeau compiler (www.comeaucomputing.com) uses this frontend.

Every indication is that the upcoming 7.1 release of the MS C++ compiler will be very good indeed; possibly better than G++. Their attitude to ANSI has really come on in leaps and bounds; I've heard from several sources that even the alpha could build Loki, Boost and Blitz without hacks. Loki in particular is notorious for killing compilers; it is to C++ what TeX was to Pascal.

> Good C++ programmers realize that there is nothing wrong with using C constructs such as null-terminated strings and printf

For quick hacks, sure. For big, critical production systems, I'd say that using printf is verging on professional negligence in this day and age.

> It's obvious the reviewer needs to get a dose of programming in the real world

Now you're just trolling.

Re:Not so great

[Euphonious Coward]

In C++, any declaration of two variables in the same definition statement, as described,

char* x, y;

is bad style. The correct code for the example given would be

char* x = something;
char y = something else;

You see there is no confusion about the type of x or y, and no possibility of confusion about whether x or *x is being assigned/initialized. Combining the definitions tempts you to leave out the initializations, which would also be bad style in C++.

This all matters particularly in C++ because, unlike in C89, the definitions are mixed in with other statements. C99 allows the mixing, and you may expect to see similar rules surface for C99.

Re:Difference between MS and ANSI?

[Antity]

Title: Mike and Phani's Essential C++ Techniques
Authors: Michael Hyman and Phani Vaddadi
Publisher: APress [apress.com]
Copyright: 1999
ISBN: 1-893115-04-6
Pages: 300

It uses old-style C++ (#include , for example), ignores valuable contributions to C++ such as the STL and the standard string class, and generally provides nothing a decent C++ programmer should not already know.

Now read that "1999" bit again. How, exactly, did "standard" C++ look back about 3.5 years ago?!

What did you expect? Hell, many modern C++ features weren't even implemented by most available compilers in 1999.

Re:Difference between MS and ANSI?

[dustman]

I am continually surprised at how often people complain about the for scoping bug in msvc.

For years, I have used a simple fix to get around it:
#define for if(false) ; else for

this gives the correct semantics, no matter the usage.

you can't do:
#define for if(true) for

because then the following would not give the intended result

if(x==2) for(...) doSomething();
else doSomethingElse();

(not really clear code, but still valid, and the previous #define example allows it)