Visit to Fisherman's Wharf

Keynote: Object-oriented programming and generic programming and what else?

Bjarne Stroustrup

Programming styles

OOP and GP and Concurrency

We must evaluate programming styles/paradigms against a set of ideals.

Aims for
· For developers
· For programmers
· Etc

Programming languages are a means for expressing solutions; they still matter!

Classic OOP problems
· Double dispatch: intersection amon two objects
· Eternal polymorphism: adding operations to something
· Etc

Classic GP
Advantages
· Regularity and generality of code
· Shared implementation
· Composability
· Performance

Ex:
list lst;
int s1 = accumulate(lst.begin(), lst.end(),0)
int p1 = accumulate(lst.begin(), lst.end(),1,multiply());
vector v;
Matrix s2 accumulate(v.begin(), v.end(),0);

C++ GP: run-time efficiency with a high-level of abstraction
Classic template ex: prime # calculation by the compiler

Classic GP problems
· Irregularities of argument types
· No support for defining new types

OOP vs. GP

OOP: Ad-hoc polymorphism
GP: Parametric polymorphism

OOP: focus on design and use of hierarchies
GP: focus on design and use of algorithms

OOP: Dynamic (run-time) resolution of calls
GP: Static (compile-time) resolution of calls

OOP: Easy to add new type
GP: Hard to add new type

OOP: Hard to add new operation
GP: Easy to add new algorithm

There are solutions in the space that involves the combinations of these two styles.

Can we combine/extend these two styles to minimize problems? Bjarne’s guess: the convergence will hinge on concurrency

C++0x Concepts and Concept maps push GP support to more mainstream.

Concept maps help fix separately developed libraries together provided they are somewhat similar in semantics.

GP: runtime concepts (currently research)

References
· Design Patterns, 1994
· Concepts: Linguistics Support for Generic Programming in C++, OOPSLA ‘04
· Run-time concepts for the C++ standard library, SAC ‘08
· The C++ Programming Language, 2000

Move over svn, git, ...

Move over svn, git, ...

Tips on Use Cases

Terry Quatrani

Uses Cases: a way to communicate requirements

Requirements
· Functionally
· Usability
· Reliability
· Performance
· Supportability

Non-functional Requirements
· Design constraints: OS, Environment, Compatibly
· Legal and Regulatory

Use cases deal with Functional Requirements only! Other requirements are gathered at the same time but put into separate documents.

Uses cases
· enable communication.
· provide links to stake holders.
· identify who/what interact with system
· are a planning instrument
· drive analysis, design, and testing

Notation
· Actor
· Action
· System

What should NOT be in a use case
· implementation details
· user interface requirements
o gather at same time, but put into separate document
· non-functional requirements
o same thing
· business rules
o same thing

What should be IN a use case
· Brief Description
· Flow of Events
o Basic flow
o Alternate flow(s)
· Special Requirements
· Pre-conditions
· Post-conditions
· Extension Points

“Provide only the necessary details about the interactions between a system and its uses.”

Use case development: Iterative!
1. Discovery
2. Briefly Describe
3. Bulleted Outline
4. Essential Outline
5. Detail Description
6. Fully Describe

CRUD uses cases should be combined into one use case. CRUD = Create, Read, Update, Delete.

Avoid putting in too much detail, remember that a use case is for communication. Use case is for requirements, not design.

More Q&A with Bjarne Stroustrup and Herb Sutter

More discussion on boost/format.hpp.

The history of template exports and why no compiler implents them.

Bjarne is giving a talk soon at BoostCon on a “wish list” for the C++ standard library. He would like suggestions emailed (bs at cs.tamu.edu or bs at research.att.com) to him on the community’s thoughts.

As it is now, ~10% of boost will be in the C++0x standard library.

Stroustrup’s new book: “Programming – Principles and Practice using C++” (due Aug 2008)

Sutter’s new book: “Effective Concurrency” (due Dec 2008)

Bjarne has respect for the Boost libraries. Boost has no special standing, but they try to have portable libraries that could be candidates for the standards. Not every boost library can, or should, be in the standard.

boost/format.hpp is cool

get the correctness of iostreams with the ease of printf

ex: cout << format(str) % “info”;

Concepts and Generic Programming in C++0x

Bjarne Stroustrup and Herb Sutter

Background
C++ Templates: high-level of abstraction and close to the hardware
Spectacularly bad error messages
Classic example: Primer number calculation during compilation

C++0x: Concepts
“A type system for C++ types”
Combinations of types

Aims and Ideals
Direct expression of intent
Separate checking of template definitions and template uses
No performance degradation
Current templates remain valid
Usable in current toolchain

Status
A design
Implementation of design: ConceptGCC (search ‘WG21’)
Lots of examples, papers, etc

Next: Correctness, Performance, Maintainability, Flexibility/Generality, Compensability

Language features are there to support ways of thinking; shouldn’t/can’t define a programming style simply as using a language feature.
Generic programming is sometimes referred to as “algorithm oriented” as opposed to “object oriented.”

An example, going from concrete to abstract, and how Concepts aim to helps.

Discussion on coding concepts. C++98 STL type traits (documented in the standard in English) are now codified using Concepts.