Hi everyone. I hope you're enjoying your spring break.
This email is at once a test of the automatic email system thing and an introduction. I'm David Hall, the course leader for CS93SI "Modern C++ Techniques." (I cannot say "instructor" or "teacher", and I don't think I'd want that anyway.) You're getting this email because you signed up for the class on Axess, or because you contacted me directly.
I'm assuming most of you read the relatively dry blurb I put in either the SIC bulletin or online at Axess. I'm going to try to recast it a bit, to get closer to saying what it is I want to get across in this course. Stanford does a great job in teaching its students best practices in C++ through about 1998, when C++ was standardized. A lot's changed in those past 8 years, as the gurus of the language fleshed out old and discovered new techniques to make hard tasks easier and to make impossible tasks possible. Most of this work has been focused in library design, particularly in developing general and easily applicable solutions to complex and common problems. And almost all of this work has been incredibly cool, and so that's what we're going to focus on: the design and implementation of Modern C++ Libraries.
Some of it can be branded as abusing the poor language. For example, it turns out that templates are Turing-complete, which means that we can run arbitrarily complex algorithms at compile time to generate code that's faster (for the end-user), cleaner (for the library's user...), and easier (again, for the library's user.) However, it is not, for the most part, easy on the library's developer. (But that makes the challenge all the more fun right?) Operator overloading can be extended to the same domain. Using Boost's Lambda Library, one can write very expressive and compact code:
std::for_each(v.begin(),v.end(),std::cout << _1 << std::endl;);
No irritating variables, no
vector<MyClass>::iterator nonsense, just simple elegance.
Anyway, I've posted a handout on the course website (cs93si.stanford.edu) called "Questions" . It's 22 questions asking about what you want to get out of this class, and then some things to get a feel for where you are. I'm not expecting you to answer all of them or most, or half or anything. But if you could get back to me about the questions I'm pasting in this email (the first 3 of the handout, plus 1 more), I'd be quite grateful, since it will let me make the class better for you.
1. What made you want to take this class?
2. What do you want to get out of it? (Examples: language lawyering; techniques to improve efficiency, design, and such; ultra-practical knowledge on how to deal with memory management, and the like; a cool new library to call your own)
3. I am required to give you two assignments. At the moment, one is a policy-based smart pointer, and the other will be the design (and partial implementation) of a library of your choosing. Does this sit well with you? (I understand that you may not know what a smart pointer is, or what a policy is. The former is a class that acts like a pointer but handles object lifetime and other things. We will discuss the latter at great length.)
4. What are exceptions? Why are they better than error codes? (This is tentatively the beginning of the first class...)
Thanks, and enjoy your break.
-- David Hall