Cargill's C++ Programming Style is another book I frequently see referenced in the press, and since PC-Lint was programmed to suggest styles this book prescribes, when I was learning C++ in the mid-90s I used this book frequently.

todo: look for the two books called "enhanced c++" or something like that, with the many rules for improving programming. was referred to in the pclint book. scott meyers?


LaFore's Object-Oriented Programming in C++ was a book I used frequently when learning C++. I assume it has been revised since my edition, because even when I bought it, it was quite out of date. It is more of a 'pop' book than the other C++ books in this serious, in that it's easier, and less content-filled. Nonetheless, I found it useful, because it covered simpler topics no other book did, and that was helpful (eg: code examples of inherited classes, that I could copy & paste from to make my own).



Murray's C++ Strategies and Tactics is another frequently recommended book. It features some fairly sophisticated C++ techniques, that are intellectually challenging at first, but seem like they might be useful, if the opportunity presented itself. Personally, I have never had cause to use anything in this book, mostly because I follow the KISS (keep it simple) rule of programming: if people I hire to read my code have to read this book to understand my code, then my company is doomed. Also, it's probably a factor of the problem domain I go after with the software I write: sophisticated C++ doesn't frequently enter in, and when it does, I prefer to buy someone else's fancy C++, so that I don't have to write it (examples: STL, ObjectSpace's libraries, RogueWave's libraries)



Ruminations on C++ is one of those programmer books a professional programmer feels they just has to have on their bookshelf: the ramblings of an emminent practictioner. I have yet to set aside the time to read this, what with more practical things to read.



Some people use Stroustrup's The C++ Programming Language as a tutorial for learning C++. I can see the logic this idea: after all, I learned both Perl and Tcl from books written by the language's authors. However, this book is very dense, and doesn't really explain why things are the way they are. It reads more like an Internet RFC, and as such, is useful as a reference guide when you need to know exactly how this should be. But reading this straight through, cover to cover? Wow.


Bruce Eckel's C++ Inside & Out is a useful overview of C++, which I enjoyed when I was first learning C++. This book is considered a classic, which is why it hsa endured.


Ellis & Stroustrup's Annoted C++ Reference Manual is useful when you want to know how somethins is supposed to work. Unfortunately, when you're confused about something, and what you're working on doesn't work right, it's usually because your compiler vendor is doing something funny, and not because the standard is weird. I rarely refer to this book, but occasionally I need to, and in those cases (once every 6 months, probably) it's very valuable.


PC-Lint is a software program (and book) that taught me how to write good C++. Essentially, PC lint is the persistent grammar school teacher, who harps about every little thing you do "wrong". What's interesting about PC-Lint is that "wrong" is defined as something like "what the experts of C++ have said is bad, in these well-respected books". The key selling point for me, what that every time PC-Lint finds something it doesn't like in your code, it refers you to an annotation in the manual, and the majority of the stylistic (ie: debatable) points refer directly to one of the canonical C++ books (eg, Meyers, Eckel, Lippman, Murray, Cargill) and to a specific chapter and section where they talk about this. Since so many C++ books contains way more information than you could hold in your head and consistently apply, this "nag you when you screw up" technique works remarkably well. PC-Lint finds so many lurking bugs in my software, that I find it useful enough to make all the nitpicky, often annoying, little changes it asks for (example: possibly ambiguous operator overload with STL iterators, so it asks you specify exactly which operator you mean). Note that PC-Lint is a console mode application, running on most PC platforms, and that they also have a more expensive version that runs on Unix.


SmartHeap is a software program that replaces malloc and new in your C++ programs. It comes in two versions: debug and release. The debug version finds just about every memory-related error, and finds it when it occurs, since it has replaces the default memory allocator. The release version is suppsed to be faster than the OS memory allocator, and facts on the MicroQuill web site try to back this up.

On the PC, there is HeapAgent, which is essentially SmartHeap's debug version, but with a nice GUI attached to it. HeapAgent is fast enough that you can leave it linked in to your application during all development operations, so it finds bugs as you create them, not later in a bug finding stage.

I've used Bounds Checker, a competing program, but found it farely useles because it so slows down your application (so you can't run it all the time) and more importantly, it registers tons of false positives, because it doesn't replace your memory allocator, but uses heuristics to find problems. Since I use the STL extensively, Bounds Checker just goes nuts and claims leaks all over the place (the STL does a lot of its own fancy internal memory allocating). I found Bounds Checker useful for finding Windows API mistakes (passing invalid parameters to API functions) but that's about it.

I've had similar problems with Purify, which is probably the most famous debugging program (at least on Unix).

SmartHeap is available on most Unix platforms, and was extremely useful to me in porting multithreaded applications. This was so because most multithreading bugs show up as memory errors (usually writing to freed memory) and since SmartHeap would find the error when it occured (not later!) I could tell exactly what functions had multithreading problems on that OS. Since no Unix (except Solaris) documents the thread safety of their system functions, this was incredibly useful.

Also, since SmartHeap/HeapAgent replace your memory allocator, when your program exits it will tell you with 100% accuracy whether you've freed all your memory, and if you had leaks, exactly what lines of code allocated the memory that wasn't freed.
I have not had good luck with the release version of SmartHeap. I shipped two versions of our Lyris ListManager on Solaris with it linked in, and we consistently found that our application took about twice as memory with SmartHeap linked in. So, while it might have been a faster allocator, programs ran slower because the large memory use often resulted in disk swapping.

If you program on Unix, you need SmartHeap. If you're a Windows programmer, go buy HeapAgent now. They're made by Microquill.

---

Real World Speed Tests with the STL and SmartHeap

Curious as to which STL containers are fastest at handling large numbers of inserts & erasures of strings, I did some timing tests on Windows NT 4.0 and MSVC 4 (this in 1996).

The ObjectSpace STL manual indicated that deques were the fastest, but I wanted to see how much faster. Also, this was a good opportunity to see if SmartHeap sped things up.

I did 200,000 string inserts into each container, and the 2nd test
inserts 200,000 then pops 200,000, and finally 200,000 push & pop & push. A deque is fastest in all cases, and SmartHeap really makes a difference (20% to 30% faster). I was suprised that pop() had no speed impact on vectors (probably because there's an optimization in there, that just shortens the size number, and does nothing else), and that the 2nd set of vector push_back() calls were very fast. The Vector was probably fastest because the memory was already allocated from the previous pushes, so it was just replacing the data in already allocated memory. This indicates that pre-allocated vectors are very fast, so if you know how large something is going to be ahead of time, use a vector.

push_back w/o smartheap
vector: 17 seconds
deque: 6 seconds
list: 10 seconds

push_back with smartheap
vector: 12 seconds
deque: 4 seconds
list: 8 seconds

push_back & pop_back with smartheap
vector: 17 seconds
deque: 9 seconds
list: 18 seconds

push_back & pop_back w/o smartheap
vector: 18 seconds
deque: 9 seconds
list: 19 seconds

push_back & pop_back & push_back with smartheap
vector: 20 seconds
deque: 13 seconds
list: 22 seconds

push_back & pop_back & push_back w/o smartheap
vector: 24 seconds
deque: 15 seconds
list: 28 seconds


Stroustrup's Design and Evolution of C++ is an interesting book explaining the history of the language: why things were done certain ways, and why changes were made. It's not as much a useful book for learning C++, but useful for understanding the "Whys" and also for seeing how a large software project evolved over time (especially something as personal to so many people as a language)


Stanley Lippman's C++ Primer is a solid introduction to the C++ language, often recommended in magazines as one of the standard texts. I read it, because the PC Lint software folks had it listed in their bibliography, and it seemed like every "recommended books" list included it. At the time I didn't find it all that useful (because my level of knowledge more or less included what it covered, thanks mostly to the Master C++ book, but I did recognize that it was a good overview book, and that others would probably find it useful.



In Black Belt C++, you'll find a few enlightening articles, a few gems, and mostly stuff that isn't that useful. Reading this book, which is a collection of articles from various authors, is much like reading the C++ report magazine: everything is well written, authoritative, but most of it just isn't relevant to what you're doing. My recommendation: flip through the book at a bookstore, check out the articles, and if there's someting relevent to you, it's probably worth getting.



The computer-based learning course Master C++ is what initiially (in 1995) taught me C++. At the time, the program was DOS based, while current editions of the book are Windows based. I recently purchased the Windows version for a coworked, and found that I preferred the DOS based version -- the windows version has so much going on around the screen, that it's harder to focus on the task at hand. Still, Master C++
is a very good way for someone who knows nothing about C++ (or C, for that matter) to get their feet wet. The exercises are excellent: you have to write small programs in C++, the program analyzes your mistakes, and suggests new content for you to read when you haven't understood. It's difficult to proceed in the chapters without thoroughly understanding the content you just read, because the program constantly questions and re-questions you. I found this persistence in the software very useful, because when I get tired I find I still continue reading a technical book, but am missing a great deal of the knowledge, which can later come back to bite me.


The STL Primer is a useful overview of the C++ Sg itndard Template Library. I was disappointed, however, upon receiving it, because the entire text of this book is the same as the manual for the Objectspace version of the STL, what they call Standards<Toolkit>. However, the ObjectSpace STL is now available at no cost at www.objectspace.com (I paid for it back in 1996 when there were no thread-safe STL versions), and since the free version doesn't include printed docs (obviously) you can just purchase this book to go along with it.


The C++ FAQs is a useful book for newbies to C++, who need lots of random small questions answered (example: how do I make my C++ code accessible to a C function?) . It has a sense of humor, and gets right to the point.



Carroll and Ellis' Designing and Coding Reusable C++ is an often ackowledged classic, and when I was feeling my way through C++, was a book I enjoyed. Lots of little tips, and I had read chunks of their knowledge in the now defunct magazine C++ Report, in articles that were helpful.



I have not yet read Schild'ts C++ Programmer's Reference