Course 689-???

Advanced programming techniques

Bjarne Stroustrup (bs [at] cs.tamu.edu)
Problems
This is the official course description:
This course presents the design and programming techniques necessary
for writing code to be used and maintained by others than its
implementers. The focus is on techniques for partitioning programs and
composing programs from separately developed parts. The course will
primarily but not exclusively use C++. The final project will be a group
project aimed at designing and implementing a maintainable system.
Students will be required to read about two papers on programming
techniques, design techniques, tools, etc. a week and to give a one-hour
presentation of such a paper once or twice during the course.

So what does that mean?

We are often reminded that there is more to computer science than programming.
Indeed, but much of what we do as computer scientists and computers professionals
involves code. Code that has to be designed, implemented, tested, and - horror of horrors
maintained, improved, ported, tuned, etc. This is a course focusing on the techniques
for writing code meant for the use of others, code meant to be worked on by more than
one individual, and maintainable by others. In other words, the kind of code wed like to
inherit from our predecessors on a project but rarely does. It is a sad fact that people
who hire graduates often complain bitterly about the system design and programming
skills of students: They cant program their way out of a paper bag!, They have no
idea of testing!, The Ph.D.s are the worst!, etc., etc. This is sad because the students
are typically bright and hard working, but often students are somehow expected to
acquire all but the most basic programming skills by osmosis: We teach computer
science, not programming a professor of a famous university (not in Texas) proudly told
me.

The snag is that such skills are useful both in research and industrial contexts, but not all
that easy to learn. There is little suitable reading material and program design involves
many tradeoffs that are not well documented (e.g. simplicity of language use vs. use of
advanced features, performance vs. regular structure, modularity vs. simple access). This
is not a new problem. Famous books have been written as attempts to address aspects of
this, such as:

Kernighan&Plauger: The Elements of Programming Style. 1982.

Gamma et al: Design Patterns. 1994.
Kernighan&Pike: The Practice of Programming. 1999.

In addition there is an infinite amount of confusing, unsupported, hyperbolic, mutually

contradictory information out there vying for attention. I say infinite because new
material, trends, fashions, etc., appear faster than we can read whats already there.
This is not a course in language design and it is not a course in classical software
engineering. It is too closely focused on code and programming techniques for that.
The (tentative) list of topics is:
Basics: functions, classes, interfaces, invariants
Object-oriented programming
Generic programming
Library design
Design, programming, and project management
patterns
concurrency
Scripting
Final project presentations
These are themes that will be visited and re-visited. Obviously,

Aims
To improve the students ability of produce quality software, particularly as that relates to
the design, implementation, and use of libraries. Develop the students ability to
articulate ideals and design rationales together with the ability to articulate those verbally
and in writing.

Prerequisites
I will assume a basic knowledge of C++, including class design, use of class hierarchies,
and the use of templates for generic programming. We will discuss many such issues in
class, but I dont plan to explain the basic language features. Read the TC++PL language
sections (Part I-II) or equivalent in advance.

Overview
The course will consist of three parts
Lectures and discussions: twice a week; opening presentation (about 40 minutes)
followed by discussion; about half of the introductions by B. Stroustrup half by
students.
Experiments: each student will conduct one relatively small experiment relating to
library design, flexibility of programming styles, or performance of programming
styles every two weeks
A project: much of the last month will be devoted to group projects (ideally 3person projects) on projects aimed at a thorough analysis (complete with
experimental data) of a library or a programming style, or a comparative study. It
is expected that project ideas will emerge from the work on the experiments. The
results will be presented both in writing and as a half-hour presentation.
Ambitious students will aim for projects with a hope of later publication.

Reading
Youll read about two papers or chapters a week. I will make some suggestions and give
about half of the presentations. Students will be expected to suggest more papers and
present papers (after agreement with B. Stroustrup).
Here is a list of papers that we might discuss:

Language features and basic techniques:

o Stroustrup: The C++ Programming Language Part IV: Design using
C++
o B. Stroustrup: Learning Standard C++ as a New Language. C/C++ Users
Journal. May 1999. http://public.research.att.com/~bs/new_learning.pdf A
paper that illustrates how C++ departs from C at a very fundamental level.
o B. Stroustrup: Why C++ isn't just an Object-Oriented Programming
Language. Addendum to OOPSLA'95 Proceedings. OOPS Messenger.
October 1995. http://public.research.att.com/~bs/oopsla.pdf The title says
it all: classification of paradigms.
o B. Stroustrup: Abstraction and the C++ machine model. Proc. ICESS'04.
http://public.research.att.com/~bs/abstraction-andDecember
2004.
machine.pdf Embedded systems programming fundamentals.
o B. Stroustrup: Exception Safety: Concepts and Techniques. In "Advances
in Exception Handling Techniques", editors: Christophe Dony, Joergen
Lindskov Knudsen, Alexander Romanovsky, and Anand Tripathi.
Springer Verlag Lecture Notes in Computer Science, LNCS-2022. ISSN
0302-9743. ISBN 3-540-41952-7. April 2001. Not just the exceptions
handling mechanisms and language features.
o Bill
Venners
interview
with
Bjarne
Stroustrup:
http://www.artima.com/intv/goldilocks.html (all three parts).
Patterns and design techniques:

o Kevlin
Henney:
Excecute
around
patterns.
http://hillside.net/europlop/HillsideEurope/Papers/EuroPLoP2000/2000_H
enney_ExecutingAroundSequences.pdf
o Kevlin
Henney:
Reference
accounting.
http://hillside.net/europlop/HillsideEurope/Papers/EuroPLoP2001/2001_H
enney_ReferenceAccounting.pdf
o A. Stepanov and D. Musser: Algorithm-oriented Generic Libraries.
http://www.stepanovpapers.com/musser94algorithmoriented.pdf The first
paper on what became the STL.
o E. Gamma et al: The visitor pattern. Design Patterns. Addison-Wesley.
1994 To get an idea of what design patterns can be good for.
o Todd Veldhuizen: Template Metaprograms. The C++ Report. May 1995.
http://osl.iu.edu/~tveldhui/papers/Template-Metaprograms/meta-art.html
o "C++ Templates as Partial Evaluation". Todd Veldhuizen. ACM
SIGPLAN, 1999 http://ubiety.uwaterloo.ca/~tveldhui/papers/pepm99/
o "STL and OO Don't Easily Mix". Dietmar Khl Workshop on C++
Template Programming. http://www.oonumerics.org/tmpw00/kuehl.html
o "Valued Conversions" Kevlin Henney. C++ Report, July 2000
http://www.twosdg.demon.co.uk/curbralan/papers/ValuedConversions.pdf
o "Promoting Polymorphism" Kevlin Henney Application Development
http://www.twoAdvisor,
October
2001
sdg.demon.co.uk/curbralan/papers/PromotingPolymorphism.pdf
o Todd L. Veldhuizen: Parsimony Principles for Software Components and
Metalanguages:
http://arxiv.org/PS_cache/arxiv/pdf/0707/0707.4166v1.pdf
o Richard A. De Millo, Richard J. Lipton and Alan J. Perlis: Social
Processes and Proofs of Theorems and Programs. CACM:
http://www1.cs.columbia.edu/~angelos/Misc/p271-de_millo.pdf
o D. J. Wheeler. The use of sub-routines in programmes. In ACM 52:
Proceedings of the 1952 ACM national meeting (Pittsburgh), pages. 235
236. ACM Press, 1952.
Examples of libraries and systems:
o STL
o Matt Austern, Bjarne Stroustrup, Mikkel Thorup, and John Wilkinson:
Untangling the Balancing and Searching of Balanced Binary Search
Trees. Software - Practice & Experience. Vol 33, Issue 13. November
2003. pp 1273-1298. A case study in (small) library design.
o Todd Veldhuizen: Expression templates. C++ Report, June 1995,
http://osl.iu.edu/~tveldhui/papers/Expression-Templates/exprtmpl.html
o A GUI library
o Plan 9
o Unix

Please note that this is a list of plausible examples. but most definitely not the final list.
The final selection will be guided by our interests and what the experiments turn up.

We will have presentations of

a source control system
a unit test frame work
why scripting?
simple project management
Preferably some of these will be given by students sharing their experiences.

Experiments
Discussions about programming style often get religious because it is just about
impossible to get relevant hard data. Here we will try to conduct a series of small (twoweek) experiments with anything we can find that is measurable: Performance and ease
of change are the obvious candidates. These experiments will be small and focused the
aim is not to scale to real-world applications or to reach general conclusions. Here is a list
of ideas:

visitor pattern vs. multi-methods

static vs. dynamic polymorphism
list vs. vector
memory-mapped I/O vs. stream I/O
garbage collection vs. (semi) manual resource management
iteration methods: loops, function objects, lambdas
error handling with and without exceptions
what abstraction penalties are there?

Students are encouraged to find their own areas for experimentation. Since time and
space are the easiest to quantify, I expect most experiments will involve measurements of
size or run time.

Projects
It will be the students job to organize themselves into groups and to suggest a topic.
Both groups and topics are subject to approval. It is expected that most projects will be
much larger and systematic examination of topics examined in articles and through
experiments.