What You Learn When You Read
5 August, 2009 § 1 Comment
It is pretty discouraging to learn that most programmers don’t read books. I’ve taken it upon myself to buck the trend and try to read as many books as possible this summer while I take a break from my graduate courses. Over the summer, I’ve read the following books:
- Effective C++
- More Effective C++
- Test-Driven Development: By Example
- The Pragmatic Programmer: From Journeyman to Master
- Peopleware: Productive Products and Teams
- Best Kept Secrets of Peer Code Reviews
The following books I’ve read bits and pieces of:
- Effective STL (I’ve read about half of the book)
- C++ Template Metaprogramming (I read the first 60-70 pages)
- The C++ Programming Language: 3rd Edition (I read about 2/3 of the book)
- Le Ton beau de Marot: In Praise of the Music Of Language (the first couple of chapters)
I’ve stopped reading the above books for different reasons. Effective STL was very interesting, but my day-to-day work doesn’t use much from the STL and I found it hard to think of applications where I could play with what I was learning (although I must admit I am now able to think about those applications when refactoring/fixing bugs/implementing new features). C++ Template Metaprogramming was genius in the way that you can get so much computed at compile-time, yet the syntax and obscure corners made it hard to write good demo and test programs. The C++ Programming Language is an all-around great book! I highly recommend it. The book walks you through all of the C++ (and some C) language, yet I stopped reading it to pick up another book (which I’ll get to later). Le Ton beau de Marot is an interesting book about a French poet and the work done to translate his poems to other languages. I picked it up to read as a somewhat abstract reading on the side effects of translating software from one programming language to another (or maybe even just working between two branches of a code base that start to diverge).
The book that I’m currently reading and hope to have finished in the next week or so is called The Design and Evolution of C++, written by Bjarne Stroustup. In the book, Stroustrup talks about many of the design decisions that had to be made when creating C++ and lots of background in the syntax that I’ve wondered about ever since first learning C++. I plan to make a full post in a week or so about all the topics that I’ve learned about while reading the book, but right now I hope to cover just a sampling of the book.
C++ gets most of its roots from Simula
When Bjarne was working on C with Classes, he had just come off of working on a project in BCPL and hoped to obtain the speed of C with the object oriented paradigm of classes found in Simula. It is helpful to know where most of the syntax ideas come from. If you’ve ever wondered by C++ uses
this as a pointer and not
self, it’s because of Simula. Smalltalk uses
self. The only artifact from BCPL is the single line comment
The first C++ compiler was written as a precompiler for C
When the syntax for C++ was defined, it was too complicated/costly to use software like Lex and Yacc to create the grammar rules. In the idea of time savings, Cfront was developed as a C code generator which read in C++ syntax and converted it to C code. I found this as an interesting take on compiler design and a simple way to introduce language rules and enforce them without building your own compiler. Over time, commercial compiler companies have created their own C++ compiler, reducing the need to parse the code on two passes.
Ever wanted to write a class that could not be allocated on the free store? Simply declare a
operator new() for the class. While C required that the user allocate memory on the free store (through
malloc) and then initialize the memory, C++ combines both of those operations in
operator new. If
operator new is inaccessible, then the memory allocation for that object will fail. This will generate a compile-time error. (The obvious way around this is to continue using malloc, but if a developer is malicious then it will be impossible for a compiler to stop them).
I am really excited about this book! There are some really cool historical facts about the language and also some great code examples. If you’ve got the time and a library card, I suggest you go check out a copy of the book. You’ll thank yourself that you did.