Slashdot Mirror
Review:Effective C++ CD-ROM
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:
- "Exception Handling: A False Sense of Security" by Tom Cargill, from C++ Report Nov-Dec 1994.
- "Coping With Exceptions" by Jack W. Reeves, from C++ Report Mar 1996.
- "Exception-Safe Generic Containers" by Herb Sutter, from C++ Report Sep 1997, Nov-Dec 1997.
- "Counting Objects in C++" by Scott Meyers, from C/C++ Users Journal Apr 1998.
- "A First Look at C++ Program Analyzers" by Scott Meyers and Martin Klaus, from Dr. Dobb's Journal Feb 1997.
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
if (efficcient && c++) {
cout } else {
cout }
-- NoWonder of WonderWorks/OmegaProject
"Effective C++" is subtitled "85 Specific Ways to Improve Your Programs and Designs".
Way #1: Dump C++ and use C instead.
Depart hence thou vile VB programmer!!!
eheh...
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.
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.
Good abstraction, maintainibility and structure is a big part of it too. C++ can help the programmer in these areas.
But sure, C++ goes by the same slogan as C - "We provide rope". Bad programmers are bad programmers in all languages (but VB? :). It is probably easier to screw up a C++ project.
Of those big projects that failed due to the choice of language, nothing says that C would do any better. It's like saying "Lots of Formula 1 crashes leads to death". Sure they do, but noone drives a station wagon at those speeds.
(Yeah I know, speed isn't a good choice of likening, but it still gives an idea of what I want to say)
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.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
I'm looking to buy a book on straight C, NOT C++. Any single one that stands out from the pack? I've got some C experience, so don't need basic this-is-a-function stuff, but would like va_args, details of structs, pointers, etc to be heavily covered. Ideally, I'd only need to buy this one book, which would serve as an advanced tutorial, and later, a reference.
Any suggestions?
The lower levels of the BeOS are written in C. The framework is written in C++.
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.
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)
The Kernighan and Ritchie book "The C Programming Language" is, without a doubt, the absolute best C book I have ever read. For the first time, I fully understood the difference between a character array and a character pointer.
C++ is a nightmare of language. Well actually C++ is many languages scraped into a big pile.
People wanting something more powerful and productive than C++ or Java, should check out Dylan, the high-performance dynamic language.
* open-source Unix implementation of Dylan: http://www.gwydiondylan.org/
* free Win32 implementation of Dylan: http://www.harlequin.com/products/ads/dylan/
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.
"My Opinion is My Opinion and Another person has not easily a right to it" F. Nietzsche
And most of the time it't this guy Anonymous Coward that tries to bash C++...
Click here
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?
Ooh, a sarcasm detector. Oh, that's a real useful invention.
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!
Why argue? Why guess? Just ask them. Simple.
If you have only one book on C, then "C: A Reference Manual" by Harbison and Steele (ISBN 0133262243) is the one to have.
However, note that it's a great reference - it might not be the book to learn C from.
It's not perfect (e.g., there are quite a few typos) but the content is excellent and there are tons of exercises and well explained examples. This book is a great start! (I find it a useful complement to my Java course's book as well, as Java syntax is similar to 'C').
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).
> But all of those problems are programming errors
> and don't reflect on the "abstraction facilities"
> of C++.
All the programming errors that I pointed out (pointer errors, memory errors, undetected array bounds errors) do in fact represent the lack of abstraction facilities of C++. In more advanced languages, these errors are not even possible.
>
> They dont know c++ so they bash it.
>
Not true. The designers and implementors of more modern object-oriented languages often have a very good understanding of C++ and the issues involved in object-oriented langauges. That is why they feel so strongly that we need a better tool than than C++.
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...
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
Advanced like VB?
No, advanced like CLOS.
The problem with language that do not let you make mistakes is that you lose a noticable amount of power. I'll take some of teh power please.
Yeah, power like a metaobject protocol and first-class procedures -- oh wait, C++ doesn't have any of those. I guess I'll have to stick with a wimpy languages like Common Lisp; after all, only wimpy hackers like Steele and Minsky and Stallman like it.
(You are free to read as much sarcasm as you like into that last paragraph, as long as you infer "lots of sarcasm.")
Point-by-point: /. is rather cheap. I would suspect that project failure is fairly constant irrespective of language. For programming in the large, C++, and indeed, Java would be better choices than C. Take GTK+ and the GNOMIES - the contortionate code that gets written just to emulate late binding / polymorphism. Features of the language like templates and exception handle *ARE* boons to development. Generic programming with C requires all kinds of macro hackery (still type unsafe, though) and exceptions - well, there's setjmp and longjmp - hahahahah! In fact if there is one thing to say about C++ is that it suffers from its C ancestory. That said, C is a nice, uncomplicated language that really requires a lot of care and attention from programmers. Those pointers and the swizzling that goes along with them *CAN* be hidden in C++ behind auto_ptr. Oh, yes, I think you mean Flounder. But what do you mean by "lack of contributions"?
#1 Please supply some numbers of here - anecdotal evidence on
#2. Compiler efficiency. By this you are obviously referring to local efficiency. Since some of the constructs that are offered by C++ and not in C (exceptions/virtual fns) - these need to specifically coded for (cf. GTK+) and it is most likely that the generated code is not as efficient as the compiler code (which may exploit machine features unavailable to C since the semantic content is hidden behind a load of pointer trickery). C++, quite rightly, concentrates on global efficiency. No function return value checking - replaced with exceptions (no, we're not talking assertions here). No hand coded look-ups - virtual functions (who knows what advantages your compiler and the SuperDuper6000 CPU can do with this). And lets talk about programmer efficiency. STL is a fantastic tool and with the current crop of free and commercial c++ compilers, template code generation just gets better and better. No, lets stop here, if you haven't gotten the picture by now, I am wasting my time.
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.
Everything should be made as simple as possible, but not simpler. -- A.E.
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.
--
Marc A. Lepage
Software Developer
Harbison & Steele is an excellent reference - particularly if you need nitty gritty info on C syntax & issues regarding compilation - if you are a desigining a compiler, particularly. it took me a some bit of time to get used to the notation they used to specify syntax, however: all the damn brackets and recursion...
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.
Need a Python, C++, Unix, Linux develop
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.
--
Marc A. Lepage
Software Developer
If you can't stand flames and badmouthing, don't :-)
release a free software package.
However, for every flamer there are 10 lurkers
that appreciate the software. You just have to
have thick skin.
> 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?
Brian Fundakowski Feldman
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.
--
Marc A. Lepage
Software Developer
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.
He said "cleaner" not "more efficient", so produced object code is irrelevant to the
argument
Get C:A Reference Manual by Harbison & Steele. If it's not in there, it's probably not true.