Slashdot Mirror
Mike and Phani's Essential C++ Techniques
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 problemsFor 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 stuffThis 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.
SummaryMike 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.
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.
Oceania has always been at war with Eastasia.
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".
Karma cannot be described by words alone.
In the beginners department you can't beat Accelerated C++ by Koenig and Moo. For more advanced programmers there is Scott Meyers.
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.
--Rosie
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++: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:As an aside, the Intel compiler is far better.
Education is the silver bullet.
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++.
Oceania has always been at war with Eastasia.
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.A hack is just an idiom waiting for wider use.
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.
thank God the internet isn't a human right.
It is an old book: September 1999
NullPointerException
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
Coming soon - pyrogyra
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?
Oceania has always been at war with Eastasia.
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.
> 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.
Authors: Michael Hyman and Phani Vaddadi
Publisher: APress
Copyright: 1999
ISBN: 1-893115-04-6
Pages: 300
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.
42. Easy. What is 32 + 8 + 2?
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)