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.

Comments

although

[REBloomfield]

There are a lot of companies still using VS C++ 6.0, and alot don't want to upgrade. The complaints I got from some users for rolling out .NET on their new workstations was unbelievable....

More specifics on VC focus

[binaryDigit]

It would have been nice to have more details on how the book was soooo heavily bent towards VC++. I would assume by the fact that he makes such a big deal out of it that these references are such that it wouldn't do any good for a non VC++ programmer? Are these things specific to the environment (visual studio, debugging, etc) or the OS (win32 api, m$ specific data types, etc).

Overall, I think his review needs a bit more beef (i.e. more examples) vs just saying "I thought it was blah ..." and us having to just take his word for it. Even more so because of the topic and the level at which it is apparently targeted.

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".

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?

[stratjakt]

Nothing with the language itself.

I assume that the examples use windows-specific libraries and stuff. Like MFC and COM stuff. Or maybe it just discusses the location of various options in the VStudio IDE.

If the book had anything insightful to offer, it really wouldnt matter what flavor implementation the examples are in. I have a really great OpenGL book, for instance, thats full of X-Windows specific examples (like creating and maintaining viewports, etc). Being able to take the ideas to windows is no big thing (cant think of the title of it).

If the book sucks then it sucks because it has nothing to say, not because it uses VC++ as an example. If being VC++ -centric is the only basis for saying it sucks, then the reviewer sucks.

Scott Meyers

[j_kenpo]

I've actually come to like Scott Meyer's books, particularly Effective C++ and More Effective C++. These books are aimed at C++ programmers to correct common mistakes, and C programmers making the migration to C++ (hence the first few chapters in Effective C++, prefer new and delete to malloc and free, etc.) The only other C++ books I really use regularly are the STL guide and C++ From the Ground Up. All of these are Ansi C++ oriented (at least there hasn't been anything that didn't work on a Ansi C++ compatible compiler). If a book is aimed at Visual C++, then it should say that in the title. Id be curious to hear what other books people use for reference (besides man pages).

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.

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

[Kickasso]

They are crap.

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

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: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.

Pot-kettle scenario

[pongo000]

It's not as if VC++ corners the market on non-ANSI compliant C++. I don't know of any compiler that is 100% compliant. Even GCC falls short of 100% ANSI compliance. (Ever try to call the stream manipulator "fixed" in GCC 2.9x? It's an exercise in futility, because you simply won't find it.)

I'm probably the last person on earth to jump to Microsoft's defense, but let's not be so quick to deride their compiler prior to pointing out that these deficiencies exist in every C++ compiler under the sun, in one way or another.

Good C++ programmers realize that there is nothing wrong with using C constructs such as null-terminated strings and printf to get the job done. It's obvious the reviewer needs to get a dose of programming in the real world before attempting to set himself (herself?) up as some sort of C++ expert.

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?

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:Difference between MS and ANSI?

[yamla]

I did try to point out that the book was bad even for Visual C++ programmers. 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.

It isn't so much that the examples are targetted for Visual C++ 6.0, it is that the techniques themselves are. It is no good telling me, 'If you set eax from assembly, disable warning 4035' unless I am using Visual C++ on an ix86-compatible processor. It just doesn't translate to any other platform.

Plug

[nycsubway]

This is time for a selfish plug. but an honest plug.

About a half year ago i was doing some C++ programming, which i haven't been doing as much as of as i'd like to, and I had an idea. It seemed each time I started programming something in C++, I would have forgotten some of the details of the language. I wanted a reference card for C++. I searched all over the internet for free ones, and even some I had to pay for. but there weren't any!

So i wrote one. It includes all the common syntax, plus a lot of advanced reference such as library functions.

gbook.org/refcard

This post is going to get modded down, but I wanted to say how much I like the concept of a one sheet reference card better than reference books.

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.

For MSVC development

[Timesprout]

If MSVC is your only environment try here for tips and pointers. They cover a lot of other stuff as well. For pure C++ then as others have said go with Myers / Stroustrup etc

Book is from 1999

[1st1]

It is an old book: September 1999

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:Difference between MS and ANSI?

[Gortbusters.org]

When I took an object oriented course a couple semesters ago, it used C++. I started out the course using gcc-2.96 on Redhat 7.3. Unfortunately, the teaching assitant was using MS visual studio 6. There were no compiler stipulations in the syllabus for the course either.. by the time the first project got graded, there was a ton of confusion.

0 compile errors on gcc, and like 50 in VS. I found out that where Linux let me to declare the std namespace in the main file where I had all my includes, VS wanted the namespace declared in every file to use anything from the STL. There was also other little stuff, but nothing tooo bad.

I couldn't spend all semester like this, so I picked up a copy of VS. After using it for the rest of the semester, my conclusion was: bleh. It was okay, but nothing to write home about and I missed the command line tools.

Were you expecting time-travel?

[devphil]

Even GCC falls short of 100% ANSI compliance. (Ever try to call the stream manipulator "fixed" in GCC 2.9x?

God bless slashdot. Anytime I need a good dose of revisionist history, I know where to look.

The library for 2.x (the part responsible for streams) predates the ANSI/ISO standard. It's full of "this is our best guess at what will eventually be voted on, based on the last meeting" code.

When the standard was finalized and published, the 2.x library was dropped, and a new one started from scratch. When GCC 2.x was shipped, its library was already known to be wrong, but stable and "mostly good enough". And the new one was already in the works.

For that matter, large chunks of the 2.x compiler itself had been abandoned for 2.x, knowing that it would be better to rewrite it for 3.x completely.

Boggles my mind why people expect a four-year old product to conform to a four-year old standard. (Hint: it takes a while after the standard is published to write the code.)

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.

Compatibility nightmare

[iamacat]

.NET uses it's own C runtime (msvcrt70.dll) and MFC DLLs. Worse, VC6.0-compiled libraries are not compatible with new runtime. Even DLLs that use their own runtime/MFC will not work, because MFC data structures have changed and malloc'ed memory blocks returned by the DLL can not be freed by the application, since there are two different version of heap management code. If you use any third-party component in your program (condmgr.dll anyone?), welcome to hell.

For all this trouble, you get a compiler that isn't much improved. It still tells you to call Microsoft customer support at the first non-trivial use of C++. It still doesn't like non-inline template specialization.

worst book review ever

[NixterAg]

This is, by far, the worst book review ever on Slashdot. The book gets a 2/10 from someone who obviously has no use for Visual C++, which tens of thousands of professionals use daily. His primary gripe seems to be that the cover misrepresented what was inside. What kind of idiot spends $50 on technical book without examining its contents? I'm likely to read at least 20-30 pages of the book before purchasing to make sure it fits my needs and most programmers I know are the same way. I think the primary problem here is that the reviewer wasn't a member of the authors' intended audience and thus it had no value to him. I haven't even heard of the book before seeing this review and the reviewer might be right, it might totally suck. The point is though, noone should take his word for it because he didn't have any use for the book in the first place.

There are dozens of books that are more than suitable for the reviewer and his expectations. When the reviewer fails to properly identify the book's audience and it's value to that audience, they aren't doing anyone any favors. What kind of review do you think a romance novelist would give to Stroustrop's C++ book? They obviously aren't the audience the author intended and as a result, their review isn't worth the paper they wrote it on. If you get a book and find that you aren't in the intended audience, you are doing a severe injustice by providing a review. You won't be able to fully ascertain how useful the book actually is and thus won't be able to provide an insightful review. I don't ask my wife for her opinion on programming books and she doesn't ask for my opinion when it comes to interior decorating. In the same vein, I don't want Chris Thompson's opinion on this book.

Re:Difference between MS and ANSI?

[oliverthered]

string thing.
the string tempaltes are good, but sloooowww as hell.
If you were taught C++ like peeps are taught Java and you've been using std::string in a was that copyies and allocates data all the time then being shown how to use \0 strings will improve you codes memory and speed preformance.

I know people who do C++ 'programming' but wouldn't know how to use structs and function pointers in C to make 'classes'.

Re:Difference between MS and ANSI?

[Antity]

Title: Mike and Phani's Essential C++ Techniques
Authors: Michael Hyman and Phani Vaddadi
Publisher: APress
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.

GCC and 'std' namespace

[Antity]

Perhaps that's because gcc completely ignores the std namespace.

Let's say it did. Current GCC incarnations honor std namespace conventions way too much according to the always-changing standard, IMHO.

Let me explain and give you an example:

(I'm sorry I had to replace spaces at the beginning of lines by dots or Slashdot's <ecode> would simply eat them..)

#include <iostream>
#include <string>
#include <algorithm>
#include <iterator>
#include <map>
#include <cstdlib>

//namespace std {
..std::ostream&
..operator<< (std::ostream& ostr, const std::pair<std::string,int>& mypair) {
....return ostr << mypair.first;
..}
//};

int
main (void) {
..std::map<std::string,int> mymap;
..mymap[std::string("myid1")] = 1;

..std::copy (mymap.begin (), mymap.end (),
....std::ostream_iterator<std::pair<std::stri ng,int> >
....(std::cout, " "));

..return EXIT_SUCCESS;
}

This code won't compile. You're required to put an application-supplied utility function in namespace std (remove the comment markers above) or it just won't compile.

That's GCC 3.2 for you. :-( I'm not sure whether it is to blame because of following strange standard requirements, but IMHO you should not be required to put custom functions into namespace std just to output some data.

I mean: Polluting std namespace because of this?

Any ideas, btw?

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)