Static and Metaprogramming Patterns and Static Frameworks A Catalog. An Application Philipp Bachmann Institute for Medical Informatics and Biostatistics Clarastrasse 12 CH–4058 Basel, BS Switzerland [email protected] ABSTRACT Windows NT, UNIX The classic UNIX principle to write code that generates code instead of writing this code yourself [48, Chapters 1,9] is General Terms experiencing a revival. Much research was done, the tech- Design niques are better understood now, and the generation tools were refined. This pattern catalog consists of adaptations of the Gang of Keywords Four design patterns [27] Abstract Factory, Adapter, Strat- Design pattern, generative programming, generic program- egy, and Visitor to the metaprogramming level. It shows ming, metaprogramming, portability, software product lines, that replacing runtime polymorphism by static polymor- static polymorphism, template, template specialization phism helps to lift variation from the code level up to the meta level, where it might more naturally belong to. Some of the patterns proposed are especially useful for facilitating 1. OVERVIEW portable code. Code generation can help to assemble a series of applica- The patterns shown can be used to build static Frame- tions from the same set of separate parts at compile time, to works [50]. A simple example is also presented. explicitly represent the construction plan in the generation For all patterns proposed we identified usage examples in software, and to allow for future adaptations by changing the popular existing applications or libraries. construction plan. Generative programming [17] provides Each pattern presentation is accompanied with an exam- another way to deal with variation additionally to patterns ple. These examples show sample code in C++. The tem- based on runtime polymorphism. Domain specific languages plate metaprogramming capabilities of C++ [2, 17, 65] allow (DSLs) describe how a system should be generated. If gener- us to express both the program and the meta program in the ative programming is available and understood, some points same programming language. of variation can be moved up from the generated software into the DSL. This often leads to better optimization oppor- tunities. Categories and Subject Descriptors The author identified patterns on the metaprogramming C.4 [Computer Systems Organization]: Performance level. His goal was to centralize the configuration and to of Systems—Modeling techniques; D.2.11 [Software En- reduce the need for conditional compilation. gineering]: Software Architectures—Domain–specific ar- Table 1 lists the patterns proposed. chitectures, Patterns; D.3.2 [Programming Languages]: With generative programming at hand the recurring prob- Language Classifications—C++, Multiparadigm languages; lem of software portability can be solved in an appropriate D.3.3 [Programming Languages]: Language Constructs and more elegant way than without. The patterns Static and Features—Abstract Data Types, Frameworks, Polymor- Adapter and Static Abstract Type Factory especially aim at phism; D.4.0 [Operating Systems]: General—Microsoft portability. Usually portability means cross–platform porta- bility. Portability also has a temporal aspect. The availabil- A preliminary version of this paper was workshopped at the 13th Pattern ity of a product for many platforms and for long periods Languages of Programs (PLoP) conference 2006. Permission to make digital or hard copies of all or part of this work for of time can provide a significant competitive advantage. So personal or classroom use is granted without fee provided that copies are this pattern catalog also assists you in both understanding not made or distributed for profit or commercial advantage and that copies variability necessary for portable applications and filling the bear this notice and the full citation on the first page. To copy otherwise, to gaps where supportive libraries are not available or cannot republish, to post on servers or to redistribute to lists, requires prior specific be used. permission. Copyright 2006, 2007 is held by the author and the Institute for The presentation of each pattern follows the style well Medical Informatics and Biostatistics. PLoP ’06, October 21–23, 2006, Portland, OR, USA. known from [13] and [54]. Additionally, each pattern de- ACM 978-1-60558-151-4/06/10. scription contains a twofold statement: Table 1: Pattern–Thumbnails of Static and Metaprogramming Patterns Section Title Intent 3 Static Strategy Delegate certain tasks an object needs to perform to another object. Allow the delegation to be chosen statically. 4 Static Visitor Encapsulate operations that should be applied to all elements of an object structure in a separate object. Adding new operations becomes easier then. Different from the Visitor pattern the Static Visitor pattern does not depend on runtime polymorphism at all. It shifts the dependency cycle present in the original Visitor design pattern from the program to the meta program. 5 Static Adapter Adapt a series of different interfaces to a common interface. The choice of which interface is actually to be adapted can be done at compile time. 6 Static Abstract Type The Static Abstract Type Factory provides an extensible means to associate Factory expressions in the domain specific language with application data types. 7 Static Framework Portable code must meet performance requirements on each platform. Static Frameworks assist you in writing code that can be adapted more easily to multiple platforms while making sure that on each platform the application can fulfill its original purpose. 1. It presents a pattern on the meta level and 3.2 Intent 2. it shows how to move variation from the program to Delegate certain tasks an object needs to perform to an- the meta program. other object. Allow the delegation to be chosen statically. The overall pattern descriptions are such that they point 3.3 Example to the first statement, whereas contrasting the motivating Suppose that you need to implement a stack. The stack example with the respective implementation section points abstract data type itself does not depend on how exactly you to the second statement. memory is allocated. Suppose this independence should be The code examples are in the C++ programming lan- reflected by the design of the stack data structure to allow for guage, because its generative programming capabilities al- plugging in different allocation strategies, for example one low us to use it at both the base and meta levels. using allocation on the heap, one using allocation in shared memory segments, and another one allocating memory in 2. METAPROGRAMMING PATTERNS terms of memory mapped files. Traditionally such allocation code would be dynamically What can be said at all can be said clearly. added by means of the Strategy [32] design pattern as sketch- ed in Listing 1. Ludwig Josef Johann Wittgenstein: Preface of Tractatus logico–philosophicus [71] Listing 1: Dynamically injecting an allocator into a stack struct AllocatorIf { The following four Sections 3 to 6 propose the use of gen- virtual ~AllocatorIf () {} erative and template metaprogramming techniques [2, 17, virtual void *allocate (std::size_t) =0; 65] to express classic patterns by the Gang of Four [27] on virtual void deallocate (void *) =0; the metaprogramming level. }; After reading these sections the reader will know how to struct NewAllocator : public AllocatorIf { refactor code to move points of variation from the base level void *allocate (std::size_t n) { to the metaprogramming level. return operator new(n); As domain specific languages (DSLs) statically describe a } system, using metaprogramming patterns can help with the void deallocate (void *p) throw() { design of portable code the same way as patterns help with operator delete(p); the design of the concrete implementation for one platform. } }; The Static Strategy (see Section 3) idea has been pub- lished as an implementation option of the Strategy design class IntStack { pattern before in [32]. We repeat it here in more detail be- AllocatorIf *allocator_ ; cause it is a good introduction to static and metaprogram- ... ming patterns. Metaprogramming variants of other Gang of public: Four patterns can be found e.g. in [17, pp 224–234]. explicit IntStack(AllocatorIf &a} : allocator_ (&a), ... {} ... 3. STATIC STRATEGY void pop() throw() { An instance or class based bahavioral pattern // Calls "allocator_->deallocate()" ... 3.1 Alsoknownas } void push(int data) { Policy [5, pp 27–51], [66, pp 429–436] // Calls "allocator_->allocate()" Strategy [32, pp 378–379] ... } • The decomposition into several parts should not result int top() const { in runtime overhead. // Returns topmost element, but don’t // remove it from the stack • The implementation details itself should be general ... enough to be reused in the context of other abstract } data types. }; The details of IntStack do not matter here. They are sim- 3.7 Solution ilar to the implementation shown below in Listing 3. An Separate an abstract data type into its essence and an implementation of the AllocatorIf interface is injected into exchangeable class or instance of another class to which it IntStack on construction. Note that different instances us- delegates implementation details. Define a concept for the ing different allocators do not differ in type. classes that represent these implementation details. Stat- Listing 2 shows how the parts proposed above work to- ically configure the abstract data type with the type of a gether to instantiate