(ref.doc)spe 25S4

Foundations for Native C++ Styles
by Andrew Koenig (Note:
 Koenig) and Bjarne Stroustrup (Note:
 Stroustrup)

1 Introduction
2 Extending C's Model of Systems Programming
3 Efficient User-Defined Types
 3.1 Defining member functions
 3.2 Helper functions
 3.3 Overloaded operators
 3.4 The significance of concrete classes
   We call such simple user-defined types concrete types [...] They
   have also been called 'value types', and their use called
   'value-oriented programming'. Their model of use and the 'philosophy'
   behind their design are quite different from what is often
   advertised as 'object-oriented programming'.
   [...]
   In particular, concrete types are not intended to display
   polymorphic behaviour [...]
   If you want to 're-use' a concrete type you use it in the
   implementation of your new type [...]
4 Containers and Generic Programming
 4.1 An elementary data structure
  4.1.1 Library support for predicates
 4.2 Another elementary data structure
   Interestingly, although the expression is the same, many of its
   components have different types [ compile-time type inference MG ]
 4.3 Function templates and compile-time polymorphism
   Object-oriented programming is built on top of run-time polymorphism
   [...]. In addition, C++ has function templates, which offer a kind
   of compile-time polymorphism [...]
  4.3.1 Iterator categories
 4.4 Strategy, style, and interface conversion
  4.4.1 Minimizing run-time resolution
  4.4.2 Templates for interface conversion
5 Design of Class Hierarchies
   [...] C++ borrowed the idea for system design that classes should be
   used to model concepts in the programmer's and the application's
   world.
 5.1 Class hierarchies
 5.2 A traditional class hierarchy
  5.2.1 Critique
    Better still, data should be in the derived classes where they can
    be defined to match requirements exactly [...]
 5.3 Abstract classes
    The ival_box should contain no data
    Gone too is the constructor
  5.3.1 Critique
 5.4 Localizing object creation
    [...] the creation of objects must be done using implementation
    specific names [...] We would like to minimize the number of places
    such specific names occur [...]
    The technique appears [...] as the abstract factory pattern.
6 C++ Style
    Naturally, this is just our view.
    Clearly, by 'style' we just do not mean rules for indentation of
    code, [...]
    [...] make it possible to program at as high a level as in many
    more 'advanced' languages.
    [...]
    This kind of purely language-driven thinking makes no sense to us.
    [...] we must design first and keep our programming-language
    technical concerns secondary. On the other hand, we do not consider
    totally language independent design practical. [...] In particular,
    a design for a C++ program that tries to subvert C++'s static type
    system will be ugly, unpleasant to implement, and hard to maintain.
7 Sociological Observations
 7.1 The best language possible
 7.2 C++ and C
 7.3 C++ and other languages
 7.4 Learning to use C++
8 Conclusions