STL and Its Design Principles Alexander Stepanov 1

STL and Its Design Principles Alexander Stepanov 1

Outline of the Talk q Genesis of STL q Fundamental principles q Language requirements q Industrialized software engineering q Assessment 2

Genesis of STL q Original intuition: associating algorithms with mathematical theories – 1976 q Specification language Tecton (with Dave Musser and Deepak Kapur) – 1979 to 1983 q Higher-order programming in Scheme (with Aaron Kershenbaum and Dave Musser) – 1984 to 1986 q Ada Generic Library (with Dave Musser) – 1986 q UKL Standard Components – 1987 to 1988 q STL (with Meng Lee and Dave Musser) – 1993 to 1994 q SGI STL (with Matt Austern and Hans Boehm) – 1995 to 1998 3

Fundamental Principles q Systematically identifying and organizing useful algorithms and data structures q Finding the most general representations of algorithms q Using whole-part value semantics for data structures q Using abstractions of addresses as the interface between algorithms and data structures 4

Identification and Organization 1. Find algorithms and data structures 2. Implement them 3. Create usable taxonomy 5

Finding software components q Books, papers q Other libraries q Real codes 6

Implementing Components q Specify correct interfaces q Implement q Validate q Measure 7

Organizing Components q Fill the gaps q Define orthogonal structure based on functionality q Document 8

Generic Programming 1. 2. 3. 4. Take a piece of code Write specifications Replace actual types with formal types Derive requirements for the formal types that imply these specifications 9

Whole-part semantics q Data structures extend the semantics of structures q Copy of the whole copies the parts q When the whole is destroyed, all the parts are destroyed q Two things are equal when they have the same number of parts and their corresponding parts are equal 10

Addresses / Iterators q Fast access to the data q Fast equality on iterators q Fast traversal operations – different for different categories 11

Iterator Categories q q q q Input Output Forward Bidirectional Random-access Two-dimensional … 12

Abstraction Mechanisms in C++ q Object Oriented Programming q Inheritance q Virtual functions q Generic Programming q Overloading q Templates Both use classes, but in a rather different way 13

Object Oriented Programming q q Separation of interface and implementation Late or early binding Slow Limited expressability q Single variable type q Variance only in the first position 14

Generic Programming q Implementation is the interface q Terrible error messages q Syntax errors could survive for years q Early binding only q Could be very fast q But potential abstraction penalty q Unlimited expressability 15

Reduction operator template <class Input. Iterator, class Binary. Operation> typename iterator_traits<Input. Iterator>: : value_type reduce(Input. Iterator first, Input. Iterator last, Binary. Operation op) { if (first == last) return identity_element(op); typename iterator_traits<Input. Iterator>: : value_type result = *first; while (++first != last) result = op(result, *first); return result; } 16

Reduction operator with a bug template <class Input. Iterator, class Binary. Operation> typename iterator_traits<Input. Iterator>: : value_type reduce(Input. Iterator first, Input. Iterator last, Binary. Operation op) { if (first == last) return identity_element(op); typename iterator_traits<Input. Iterator>: : value_type result = *first; while (++first < last) result = op(result, *first); return result; } 17

We need to be able to define what Input. Iterator is in the language in which we program, not in English 18

Concepts concept Semi. Regular : Assignable, Default. Constructible{}; concept Regular : Semi. Regular, Equality. Comparable {}; concept Input. Iterator : Regular, Incrementable { Semi. Regular value_type; Integral distance_type; const value_type& operator*(); }; 19

Reduction done with Concepts value_type(Input. Iterator) reduce(Input. Iterator first, Input. Iterator last, Binary. Operation op) (value_type(Input. Iterator) == argument_type(Binary. Operation)) { if (first == last) return identity_element(op); value_type(Input. Iterator) result = *first; while (++first != last) result = op(result, *first); return result; } 20

Signature of merge Output. Iterator merge(Input. Iterator[1] first 1, Input. Iterator[1] last 1, Input. Iterator[2] first 2, Input. Iterator[2] last 2, Output. Iterator result) (bool operator<(value_type(Input. Iterator[1]), value_type(Input. Iterator[2])), output_type(Output. Iterator) == value_type(Input. Iterator[1]), output_type(Output. Iterator) == value_type(Input. Iterator[2])); 21

Virtual Table for Input. Iterator q type of the iterator q q q copy constructor default constructor destructor operator== operator++ q value type q distance type q operator* 22

Unifying OOP and GP q Pointers to concepts q Late or early binding q Well defined interfaces q Simple core language 23

Industrial Revolution in Software q Large, systematic catalogs q Validated, efficient, generic components q Component engineers (few) q System engineers (many) 24

Changes in Industry q Code is a liability q Internal code tax q Continuous professional education q Government q Tax support for the fundamental infrastructure q Legal framework q Academia 25

Is STL successful? q Millions of copies out q Everybody (Microsoft, IBM, Sun …) ships it q A dozen books q Very few extensions q No language progress q No effect on software engineering 26