Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
News Books Media Book Reviews

Review:Effective C++ CD-ROM 47

Posted by Hemos from the taking-it-digital dept.
A name that all the book reviewers know SEGV has sent in a review of Scott Meyers' CD work Effective C++ CD. This is a stray from our normal book reviews, but figured people would appreciate seeing Scott Meyers' newest effort.
Effective C++ CD
author Scott Meyers
pages
publisher Addison Wesley
rating 10
reviewer SEGV
ISBN 0-201-60615-1
summary More than the sum of its hardcopy contents, this electronic resource earns a place on the programmer's bookshelf.

What to Expect?

I wasn't sure exactly what to expect. Subtitled "85 Specific Ways to Improve Your Programs and Designs," I knew this CD was an electronic version of Scott Meyers' already-published books, which I had previously reviewed for Slashdot:

So I knew a priori that the content was excellent, but how would it be packaged and presented? Would it be Windows-only, forcing me to use it only at work as I run Linux at home? Would it be awkward to read onscreen? Would it be easily searchable? Could I annotate and print portions of it?

A Pleasant Surprise

I was pleasantly surprised when the package contained only a CDROM with these instructions printed on it:

To start, open INDEX.HTM
System requirements: Netscape Navigator 4.0+ (on Unix, Mac, or Win32) or Microsoft Internet Explorer 4.0+ (on Win32 only).

So far so good! I had no problems using the CD with Communicator 4.5 on NT 4.0, and Communicator 4.04 on Debian GNU/Linux 2.0. Pretty much any modern browser with Java and JavaScript support should work. If you experience browser problems, the publisher provides helpful advice.

Initial Impressions

The CD has a nice look and feel to it. A navigation area is always present, acting as a control and providing a colour indication of where you are in the CD.

The text is decent to read and is true HTML, not merely raw text. It seems Meyers is conscious of the fact that an electronic version must add value to complement a printed version, otherwise it is not useful for its target audience.

Overall, I'd say this offering is a well though out and put together product, and not just a cheap knock-off.

Content

The CD (which itself has a printing number) contains the latest printings of the two books. It also boasts five magazine articles chosen by Meyers to augment the material in the books:

The first three are highly recommended for anyone dealing with exceptions. And of course, since any function may throw an exception, that means anyone writing C++! The object counting article elaborates on an idea from Effective C++ Item 14, illustrating some subtle language issues along the way. The final article outlines the state of the art in commercial static C++ analysis tools in September 1996.

Hyperlinks

The CD has links everywhere. Let me repeat: everywhere. In addition to hyperlinking existing references, Meyers added many cross references to the books and articles to further solidify the material.

Links to the internet at large are redirected through Addison Wesley Longman's online site so that they may stay current. And every single paragraph on the CD is anchored and hyperlinked, to facilitate electronic referencing and bookmarking.

Search Facilities

The CD provides two alternatives to your browser's "find in page" search facility. The first is a comprehensive merged index of the two books. The second is a search applet, modified from the Design Patterns CD search applet. It displays the resulting hits, with their enclosing paragraph for context if you select it. I found it easy to scan through hits until I found an interesting paragraph, then to jump to that document.

Although the search applet is aware of the entire CD, it appears that it can search only for one keyword. I'd really prefer more sophisticated search string options, such as multiple keywords, boolean operations, and perhaps even full regular expressions.

Configuration Facilities

For a set of web pages, the CD is impressively configurable. You can choose between five navigation area sizes, and five image sizes. You can view the books by item, by chapter, or in their entirety. And of course you can change text size in your browser.

Performance and Licensing

To implement the configurability options, there are actually five copies of each image and three copies of each book on the CD. Still, the total data size is a mere 16MB, which easily fits on a hard drive for greater performance and frees a CDROM drive for other use. This is also important because, given technology, actually altering the HTML files is really the only viable way of annotating the CD.

The CD comes with a single user license. You must contact the publisher for additional network license options. The short story is: you can make the CD available on a non-internet-accessible server to as many users as you have licenses, and you can purchase additional network licenses more cheaply the more you buy.

Summary

I've been using the CD both at work and at home for a couple of weeks, and I continue to find it a valuable resource. It easily subs in for my absent printed books, although of course I can't use it without a computer. The articles are useful, and the index and search applet allow me to quickly find what I am looking for.

Really, I have only three complaints:

  • the search applet is somewhat limited
  • there could be more magazine articles
  • Scott's author photo is starting to look less like Eddie Van Halen and more like Gene Simmons

However, I don't think any of those detracts from the CD enough to reduce its 10/10 rating. In the worst case, since the CD is composed of text HTML files, you could apply other search utilities (eg, grep) to it.

The CD's online site has a demo, which I recommend trying if you want to get a feel for the CD before you purchase it. In addition to the general look and feel, navigation area, and search applet, it includes all of the magazine articles and a few of the books' items.

I'm happy with the CD, and recommend it as a professional resource.

To pick this up and help Slashdot, head over to Computer Literacy.

TABLE OF CONTENTS

Introduction
Effective C++ Second Edition
More Effective C++
Magazine Articles
Search the CD

This discussion has been archived. No new comments can be posted.

Review:Effective C++ CD-ROM More

Review:Effective C++ CD-ROM

Comments Filter:
  • if (efficcient && c++) {
    cout } else {
    cout }
  • Depart hence thou vile VB programmer!!!
    eheh...
  • Any time C++ is mentioned on Slashdot, some weenie will come in and say how C is better. Whether this is based on their inability to grok C++, on fear of learning anything new, on limitations of older implementations of C++ compilers, or on a few reasonable objections to C++ is unclear. Usually, however, their lack of correct arguments implies it is not the last reason.
  • Harbison and Steele - "C - A Reference Manual", Published by Prentice Hall. If I could have only one C book, this would be it. Get at least the 3rd edition for ANSI C, but I think the 4th edition is out. Amazon has it.

    Having said that, I'd hate to live without Plauger's "The Standard C Library" and K&R II.

  • Take a look at the web-site version. (Score:1)

    by Anonymous Coward
    This is one of the best uses of hypertext I have ever seen. It's awesome. I hope more books will be converted like this one. As far as content goes, I already have both books, and I can say that they are the the most-referenced C++ books that I have.
    --
    booch (no cookies at work)
  • Everytime I see one of these C Bigots trash C++ I wonder what their experience with large projects (250K+ LOC) is. The OO extensions added into C by Strousstup (spelling?) are there for a reason to allow us to abstract complexity. I also wonder what the level of Cyclomatic Complexity for two projects with the same requirements written in C and C++ respectively would be. Given that the C programmer would have to track all those layers of complexity himself instead of relying on the OO mechanisms naturally provided in C++ the C program would likely introduce many unnecessary layers of complexity. This of course can be reduced with the design process but how much time will you spend in design reinventing the abstraction mechanisms that C++ and other OO languages naturally provide for.

    Common people OO exists for a reason and it is not consequential that many brilliant minds have written and expanded on OO (i.e. Design Patterns). If you don't like the technology then by all means shut up and go the way of the dinosaur. If you can't grasp it I feel for you, work harder, email me and I'll try to answer your questions if I can.
  • And most of the time it't this guy Anonymous Coward that tries to bash C++...
  • Yes, but we are comparing to C here.

    "In true sound..." -Agents of Good Root
  • But all of those problems are programming errors and don't reflect on the "abstraction facilities" of C++. You are correct that those problems abound in poorly designed or poorly thought-out C++ projects, but they can be engineered away. C++ gives you the power to shoot yourself in the foot, but you will avoid these problems if you approach the problem you are solving with a clear idea of what you are solving. Not to say that the other languages you mention can't solve the same problems, but at least bash C++ for it's true shortcomings.
  • Given that C is effectively a subset of C++, C++ works fine for this too.

    I can see virtues in Eiffel, Ada95, Java, etc., not the least of which is garbage collection. However, you'll probably find your pool of contributors is smaller with any of those except Java, and the performance issue still hasn't been quite worked out for Java. And I don't know that any of them are good for system-level programming, which you can do with C++.

    Isn't the Linux source close to being compilable with the GNU C++ compiler?
  • Follow the link to the "Effective C++" web page (I followed the one about exceptions). Notice how few of the problems he's attempting to work around occur in Java...
  • Well, for an example of an OS written entirely in C++, look to Epoc32, the operating system created by Symbian/Psion for 32-bit multitasking palmtop computers, smartphones etc.

    I don't think they would have chosen C++ if it produced bloated, inefficient code; the OS runs on palmtop computers with strict processing and memory limitations.

    You just have to know how to use the language, that's all!
  • Wow, some examples of either of your points would be appreciated. But I will jump you with some couterpoints first.

    1) C++ reduces programmer efficiency by being hard to read/understand. Proof: Look at the number of C++ projects that founder for lack of contributions.

    Your proof is not. I'm sure you can find numerous C projects that failed from a lack of contributions.

    C++ is not harder to understand than any other language that you already understand. In fact, learning C++ is the best way to become a better C programmer. The languages constructs in C++ are well designed and teach you a means to structure a program even in their absence.

    With capacity to use overloaded operators and type conversions, you can make code that is fundamentally more readable than with a C program. For example, the STL (often considered strange looking by those who have only glanced at it) has a standard syntax for iterating over the members of a container (lets say the type is Container):

    Container c;
    for ( Container::iterator iter = c.begin ( ); iter != c.end; ++ iter ) iter->value; ....

    This will work whether the container is a vector, list, stack, map (associative list), set (indexed list).

    In C, there would be separate functions for each type of collection (and conversions for the generic pointer). But the best part is that the semantics mimic efficient iteration of a C array.

    struct s[20];
    for ( struct s *iter = s; iter != s + 20; ++ iter ) s->value; ....

    In the case of the vector container, that is the typical implementation.

    Given that C++ can mimic C semantics while encapsulating more complex behavior makes the language easier to read than an equivalent C project.

    2) C++ reduces program efficiency by being hard (if not impossible) to compile into an efficient executable. Proof: OS's and other high-performance programs are written in C.

    This is one of those statements that is never backed up with fact. Some people seem to think that the size and speed of your program is proportional to the number of keywords in the language.

    Given that C++ is a superset of C (with the semantics of struct being slightly different). There is no reason that a C++ compiler will implicitely produce inferior code.

    When is not often stated is that the keyword in C++ can produce better code given the opportunity.

    I will review two language features that are often accused of causing inefficiency: dynamically bound functions, and exception handling.

    The key thing to remember is that to reproduce the equivalent behavior is C for using these features the only difference is that you are writing the code yourself. In every case, the compiler would have done a better job itself.

    Virtual function are often implemented as a virtual table of function calls. This means that a virtual function call requires a table index before the function call. This is one more instruction (some processors do this for you) in a function call that may be hundreds -- before you even get to the function.

    The equivalent switch statement introduces a lot more code because it has to compare against all of the values. If you get fancy and make a similar lookup table ... why didn't you just let the compiler do that for in the first place?

    The estimate for exceptions is often estimated at a 5-10% overhead:

    "This is huge." the C programmers cry.

    But it's not so bad after you realize that your code if free from all of the error code checks. The ones where after every method call, you have to check whether it was successful before using the return value.

    Freed of that burden, you can actaully use your return values. For example the C code:

    Foo *pFoo = GetChickenFoo ( );
    if ( pFoo != NULL ) pFoo->layLotsOfEggs ( );

    If under C++, we define GetChickenFoo to return a valid pointer or throw an exception (give me foos or give me death!) we have:

    GetChickenFoo ( )->layLotsOfEggs ( );

    Which one would you rather write. Even better, this second code is more efficient because: there is no check (already done), there's no jump (pipelined processors hate those), and no early return (more code generated).

    Over an entire project, you get your 5-10% back pretty quick (and possibly then some) all without you having to write more code.

    There are more constructs like inlining, templates and (gasp!) template meta-programs (where you trick the compiler into generating the perfect source code for you depending on the context) which can improve code efficiency further.

    For those who want to know how C++ can be used inefficiently, here are some things to look for: excessive duplicating of objects (through pass-by-value parameters and returns), excessive reallocations, excessive data type conversions, and the streams library (which has yet to have a fast implementation).

  • The Java Security model and web browsers are brain damaged and make writing a good search applet way harder than it should be.

    A security exception is raised when an applet attempts to open a file for read only RandomAccess (even if it is in a subdirectory of the directory that the applet resides in). You can only open a file for sequential access. This sucks, badly.

    A way around this would be to open a file for sequential access and use the skipBytes method to mimic RandomAccess this works and is fast on IE but is DEAD SLOW under netscape.

  • Was it written in Java?

    Is this the sign of things to come - a truly cross-platform interactive book-on-CD that is not platform dependent?

    Seems like a good use of Java technology to me - interactive publishing...
  • of course, java has its own problems to work around.
    how do you handle 'instantiation is allocation', i.e., having the constructor of a stack-allocated
    object grab a resource, and the destructor deallocate it when it goes out of scope?
    routine in C++, impossible in Java, but highly desirable nonetheless.
  • Actually, one of the biggest issues he tries to solve (at least in the printed version) is run-time efficiency.
    I think that one has still yet to be solved in Java.
  • First off, language wars are pointless.

    Second, if you are going to offer your comments, perhaps you should offer your credentials.

    I am a professional software developer. I've been in the industry for several years and have worked on shipping products.

    There is a major difference between a homework assignment or tic-tac-toe program, and large-scale projects.

    C, C++, and Java all have their place. I myself had a Java renaissance for awhile, but have come to recognize that it doesn't come close to C++ in many ways. Since then, I've learned more about C++ and come to appreciate it more.

    In my experience, if Java code is better than C++ code, it is because it is *newer* code and the people writing it know better what they are doing these days, than when they wrote C++ code a few years earlier.

    In my experience, people are hard on C++ because it is not a trivial language to pick up. Not all of my co-workers understand the code they are working on. That will always be true to some extent, but I believe it is more of a deficiency in skill than a language deficiency.

    In my experience, C++ has advantages over C that make it preferable. I can bundle concepts up into types, express idioms (dynamic binding, error handling, etc.) at the language level, and have better type checking.

    In my experience, people have problems with C++ because they haven't applied themselves to its study. As with any language, you have to read more than the "primer" to be proficient at it, to not get into trouble, and to know when you are getting into trouble. Otherwise you remain blissfully ignorant.

    C++ is more complex because it was designed for more complex tasks. How many have read "The Design and Evolution of C++?" How many have read "The C++ Programming Language?"

    You can argue that you should be shielded from that complexity, but there remain programmers who have to face it, even if you don't. So pick your language and put your code where your mouth is, and leave the C++ coders to do the same.

  • I want to release under LGPL a C++ communications transport library based on the UNIX pipes concept that I've spent a lot of time developing, but I'm worried about the response of the OSS community. It would be highly disappointing to release it and have it fall flat.

    This library could only have reasonably been written in an OO language. The only OO language with the speed I want, the type safety I want, and the access to low level OS facilities that I want is C++.

    Some of the posts to this group are not very encouraging, and some are. Does anybody have any suggestions or advice? And no, it CAN'T be ported to C. I might consider a Java port, but that would co-exist with the C++ library, not replace it.

  • C: A Reference Manual by Samuel P. Harbison, Guy L. Steele. (Many say this is the true bible... better than K&R). Its 455 pages and $35 on Amazon.

    Practical C Programming (Nutshell) by Steve Oualline and Andy Oram. 480 pages and $27 on Amazon.
  • Seconds on Stroustrup's excellence. For someone so modest with his skill of English, he manages to pull off excellent puns.

    And yes I've found him to be an excellent source of design knowledge, as well as the GoF and Three Amigos.

    Shouldn't be surprising as his area of study is large-scale systems.
  • > struct s[20];
    > for ( struct s *iter = s; iter != s + 20; ++ iter ) s->value; ....

    You know you cannot do that in C, don't you?

  • People would be much better off using a language such as Dylan, Smalltalk, or Eiffel that
    were well thought out.


    Contrary to the above statement, C++ was in fact very well thought out. If you feel differently, I suggest reading The Design and Evolution of C++.

    Given the set of design goals Stroustroup sought to meet and the tradeoffs he needed to consider in designing c++, I would say he did a very good job.

    As for Dylan, Smalltalk, Eiffel, Java, etc, a major issue to take into consideration is that none of these were designed with backward compatibility to C as a constraint. Freedom from this is part of what makes Java a "safer" language to program in.

    Someone else mentioned that C++ is like multiple languages wrapped up into one. Well...it is. As I understand, Stroustroup seems to believe that programming need not follow only one paradigm. C++ supports multiple forms of programming, including Abstract Data Types, Object Oriented Programming (there's a difference between the two!), and Generic Programming (through templates). And that's not to mention C, which is also encapsulated in C++ (remember, every program in Kernighan and Ritchie is a C++ program).

    Even when I program in C-style, I still tend to program in C++ insofar as I use c++ style comments and I prefer to declare variables close to where they are used (given a large program, this increases my comprehension). Not to mention I prefer C++ strong typing to ensure my code uses the correct parameters.
  • > References are a thing that should be avoided (why use them when there are much cleaner pointers)

    Hmm... just one thing: with a LOT of code, whether you use pointers or references, it produces EXACTLY the same assembly code... interesting, hmm?
  • References are a thing that should be avoided (why use them when there are much cleaner pointers)
    Well they are needed for overloading operators, like operator +.

    overloaded operators should do what they were originally meant to do
    Um, I don't quite follow you here. Are you advocating completely avoiding operator overloading? I hate having to write crap like ((Integer)(myVector.elementAt[i])).intValue() in Java where as in C++ I can simply write myVector[i] (well part of the problem is that Java doesn't have templates). Anyway the point is that operator overloading as used in the STL makes it possible to write much more readable code.

    the standard c++ library is a horrible kludge and an example of bad code
    Well I thought the STL is a library specification rather than an implementation, so it doesn't make sense to call it bad code. Do you think it is designed badly? I know it bloats my code horribly but I'm kinda hoping that's because C++ compilers are still immature.
  • > He has a syntax error, but the following is definitely legal C:
    > char data[20];
    > for ( char* iter = data; iter != data+20; ++iter )
    >;

    You obviously don't know C.

    You can't declare a variable in the for arguments. Declarations must come before statements.
  • I've been playing with the search applet a little further. I found its help page. :-)

    I see now that it does search for more than one term, but for some unknown reason it may only highlight one in the search results. That was why I was confused and thought it only searched for one term, an especially easy mistake to make if the other term is elsewhere in the paragraph.

    It also takes wildcards, although not regular expressions. I'm not as convinced now that regular expressions are really necessary for the search applet to be useful. However, it would be nice to have AND, OR, NOT, etc.

    In summary, I'm happier with the search applet now and glad that I didn't dock a point off the CD because of my perceived shortcomings with it.
  • Let's not start another one.

    If you want to play with the best of machinery for a couple of decades and get paid big bucks for it, you learn and use whatever best suits the problems the real world provides to you.

    Sometimes you need C++. I just ordered the CD. After all, it's just another computer program and using them gets me all sorts of neat toys.

Slashdot Top Deals

Those who can, do; those who can't, write. Those who can't write work for the Bell Labs Record.

Close