C++ Design Patterns Advanced C++ Programming Seminar, Summer Term 2009

C++ Design PatternsAdvanced C++ Programming Seminar, Summer Term 2009

Georg Altmann

University Erlangen-Nuremberg – System Simulation

June 4th 2009

Georg Altmann (LSS Erlangen) C++ Design Patterns 6/4/2009 1 / 48

Outline

Introduction

The Singleton Pattern

The Monostate Pattern

The Bridge Pattern

What is a Design Pattern?

Design Patterns are descriptions of communicating objects and classes thatare customized to solve a general design problem in a particular context.a

aErich Gamma [et al.], Design Patterns, Addison Wesley, 1994

Why use Design Patterns?

Design Patterns are proven solutions to re-occurring software designproblems

Don’t “re-invent the wheel”!

Outline

Introduction

The Bridge Pattern

The Problem

Ensure a class has only one instance with global access

Motivation

For some classes it is important, that only one instance exists:

program configuration classes

classes representing unique system devices

logging classes

singleton.h

class Singleton {public:

// Unique global point of accessstatic Singleton* getInstance();

private:static Singleton* instance_;

singleton.cpp

Singleton* Singleton::instance_ = 0;

Singleton* Singleton::getInstance() {if(instance_ == 0)

instance_ = new Singleton();return instance_;

Singleton?

static Singleton* getInstance();private:

static Singleton* instance_;};

Default constructor public:It is possible to create multiple instances!

Singleton?

static Singleton* instance_;};

Default constructor public:It is possible to create multiple instances!

Singleton?

Singleton();static Singleton* instance_;

Copy constructor and copy assignment operator public:It is still possible to create multiple instances by copying!

Singleton myCopy(*Singleton::getInstance());

Singleton?

Singleton();static Singleton* instance_;

Copy constructor and copy assignment operator public:It is still possible to create multiple instances by copying!

Singleton myCopy(*Singleton::getInstance());

Singleton!

Singleton();Singleton(const Singleton&); // non-Singleton& operator=(const Singleton&); // copyablestatic Singleton* instance_;

Singleton gone. . .

Singleton *s = Singleton::getInstance();delete s; // Oops!

Destructor is public:Clients can destroy the Singleton.

Singleton gone. . .

Singleton *s = Singleton::getInstance();delete s; // Oops!

Destructor is public:Clients can destroy the Singleton.

A simple Singleton

static Singleton& getInstance(); // return referenceprivate:

Singleton();Singleton(const Singleton&); // non-Singleton& operator=(const Singleton&); // copyable~Singleton(); // indestructiblestatic Singleton* instance_;

Resource leak: ˜Singleton() is never called!

Resources held by the Singleton are never freed

May be acceptable for dynamically allocated memory

OS-wide mutexes, IPC, CORBA/COM → problematic!

How can the resource leak be avoided?

Use a local static variable instead of a static data membera

aMeyers, More Effective C++, Addison-Wesley, 1996

The Meyers Singleton

static Singleton& getInstance();private:

Singleton();Singleton(const Singleton&); // non-Singleton& Singleton(const Singleton&); // copyable~Singleton();// no static instance pointer!

Singleton& Singleton::getInstance() {static Singleton instance;return instance;

Meyers Singleton Consequences

instance initialized when getInstance() is called the first time

instance ist destroyed automatically (std::atexit())

Order of destruction of static objects is arbitrary!Problematic if static objects are interdependent→ Dead reference problem

Order of destruction of static objects is arbitrary!

Problematic if static objects are interdependent→ Dead reference problem

Detecting Dead Reference Access

// singleton.hclass Singleton {

// ... as beforeprivate:

static bool destroyed_;};

// singleton.cppSingleton::destroyed_ = false;

Singleton::~Singleton() {destroyed_ = true;

Detecting Dead Reference Access

// singleton.cppSingleton& Singleton::getInstance() {

static Singleton instance;if(destroyed_)

throw std::runtime_error("Singleton: Dead Reference Access");

elsereturn instance;

The Phoenix Singleton

Phoenix from the ashes

Dead reference access now correctly throws an exception

Situation unsatisfactory if dependency cannot be avoided

Idea: Re-create the destroyed Singleton after it’s destruction:→Phoenix Singletona

aAlexandrescu, Modern C++ Design, Addison-Wesley, 2001

// singleton.cppSingleton* Singleton::pkill_ = 0;Singleton& Singleton::getInstance() {

static Singleton instance;if(destroyed_) {

new(&instance) Singleton; // placement newpkill_ = &instance; // init kill pointerstd::atexit(kill); // register destructiondestroyed_ = false;

}return instance;

}void Singleton::kill() {

pkill_->~Singleton()}

Phoenix Disadvantages

If the Singleton keeps state, it is lost after destruction

Use of atexit is a low level “hack”

Longevity Patterns

More advanced patterns for controlling the lifetime of objects can befound inAlexandrescu, Modern C++ Design, Addison-Wesley, 2001

Phoenix Disadvantages

If the Singleton keeps state, it is lost after destruction

Use of atexit is a low level “hack”

Longevity Patterns

More advanced patterns for controlling the lifetime of objects can befound inAlexandrescu, Modern C++ Design, Addison-Wesley, 2001

Outline

Introduction

The Bridge Pattern

Singleton

Ensures only one class object exists

Data is encapsulated in the class object

Monostate

Data members static and private - class level encapsulation

Class objects are stateless - any number of instances may exist

config.h

class Config {public:

Config();Color getFavoriteColor() const;/* ... */

private:static bool initialized_;static Color favoriteColor_;/* ... */

config.cpp

bool Config::initialized_ = false;Color Config::favoriteColor_;

Config::Config() {if(!initialized_) {

/* ... initialize from file/registry/etc. ... */initialized_ = true;

Color Config::getFavoriteColor() const {return favoriteColor_;

Monostate vs. Singleton

Config as Singleton

Config &conf = Config::getInstance(); // get Config objectColor col = conf.getFavoriteColor();

Config as Monostate

Config conf = Config(); // create new Config objectColor col = conf.getFavoriteColor();

Config as Singleton

Config &conf = Config::getInstance(); // get Config objectColor col = conf.getFavoriteColor();

Config as Monostate

Config conf = Config(); // create new Config objectColor col = conf.getFavoriteColor();

Singleton

Meyers Singleton offers initialization and destruction

Ensuring single instance is difficult and error-prone

Single instance explicit in interface

Monostate

Does not handle destruction→ leaks dynamic resources

Objects are stateless→ no copy-construction problem

Data sharing invisible in interface (“implementation detail”)

Singleton

Meyers Singleton offers initialization and destruction

Ensuring single instance is difficult and error-prone

Single instance explicit in interface

Monostate

Does not handle destruction→ leaks dynamic resources

Objects are stateless→ no copy-construction problem

Data sharing invisible in interface (“implementation detail”)

Outline

Introduction

The Bridge Pattern - Pimpl

The Bridge Pattern

The Problem

C++ mixes class interface and implementation (header files)

Leads to strong compile time dependencies

Long compile times slow down development process

The Solution

Manually decouple interface and implementation:

Pimpl idiom (pointer to implementation)

Abstract Interface classes

The Bridge Pattern

The Problem

The Solution

The Bridge Pattern

The Problem

The Solution

The Bridge Pattern

The Problem

The Solution

The Bridge Pattern

The Problem

The Solution

person.h

class Person {public:

Person(const std::string& name);std::string name() const;

private:std::string name_; //implementation detail

person.cpp

Person::Person(const std::string& name): name_(name) {}

std::string Person::name() const {return name_;

person.h

private:std::string name_; //implementation detail

person.cpp

Person::Person(const std::string& name): name_(name) {}

std::string Person::name() const {return name_;

Pimpl version person.h

class PersonImpl; // forward declaration of impl

private:std::tr1::shared_ptr<PersonImpl> p_; //pointer to impl

Pimpl version person.cpp

Person::Person(const std::string& name): p_(new PersonImpl(name)) // create impl instance

std::string Person::name() const {return p_->name(); // delegate call to impl

personimpl.h

class PersonImpl {public:

PersonImpl(const std::string& name);std::string name() const;

private:std::string name_;

personimpl.cpp

PersonImpl::PersonImpl(const std::string& name): name_(name) {}

std::string PersonImpl::name() const {return name_;

personimpl.h

class PersonImpl {public:

PersonImpl(const std::string& name);std::string name() const;

personimpl.cpp

PersonImpl::PersonImpl(const std::string& name): name_(name) {}

std::string PersonImpl::name() const {return name_;

}Georg Altmann (LSS Erlangen) C++ Design Patterns 6/4/2009 33 / 48

Result

person.h has no dependency on personimpl.h (forward declaration)→ No need to recompile client code if personimpl.h changes

Add Write Access

void Person::setName(const std::string& name) {p_->setName(name);

}void PersonImpl::setName(const std::string& name) {

name_ = name;}

Person p("Peter");Person pc(p);

cout << "p.name(): " << p.name() << endl;cout << "pc.name(): " << pc.name() << endl;cout << "pc.setName(\"Hans\");" << endl;pc.setName("Hans");cout << "p.name(): " << p.name() << endl;cout << "pc.name(): " << pc.name() << endl;

Result

p.name(): Peterpc.name(): Peterpc.setName("Hans");

p.name(): Hans // Oops!pc.name(): Hans

Result

p.name(): Peterpc.name(): Peterpc.setName("Hans");

p.name(): Hans // Oops!pc.name(): Hans

Person p("Peter");Person pc(p); // (1)

What happened?

Compiler-generated Copy-Constructor is called (1)

p and pc share the same PersonImpl object!

Copying behavior

Implement Copy-Constructor and copy assignment operator and make surethe PersonImpl object is (deep-)copiedorimplement copy-on-write. . .

Copy-on-Write

void Person::makeUnique() {if(!p_.unique()) {

std::tr1::shared_ptr<PersonImpl> np(new PersonImpl(*p_));

p_ = np;}

}void Person::setName(const std::string& name) {

makeUnique();p_->setName(name);

cout << "p.name(): " << p.name() << endl;cout << "pc.name(): " << pc.name() << endl;cout << "pc.setName(\"Hans\");" << endl;pc.setName("Hans");cout << "p.name(): " << p.name() << endl;cout << "pc.name(): " << pc.name() << endl;

Copy-on-Write Result

p.name(): Peterpc.name(): Peterpc.setName("Hans");p.name(): Peterpc.name(): Hans

Drawbacks of Pimpl

Performance penalty of impl allocation and memory fragmentation

Performance penalty due to pointer dereferencing

Copying behavior has to be taken care of

Source code bloat

Sometimes a “back-pointer” to the interface object is needed (e.g.for virtual function calls)

Drawbacks of Pimpl

Source code bloat

Drawbacks of Pimpl

Source code bloat

Drawbacks of Pimpl

Source code bloat

Drawbacks of Pimpl

Source code bloat

Outline

Introduction

The Bridge Pattern - Abstract Interface Classes

Abstract Interface Class

// person.hclass Person {public:

virtual ~Person();virtual std::string name() const = 0;

// factory function - "virtual constructor"static std::tr1::shared_ptr<Person>

create(const std::string& name);};

Concrete Class

// realperson.hclass RealPerson : public Person {public:

RealPerson(const std::string& name):name_(name)

{}std::string name() const;

person.cpp

#include "person.h"#include "realperson.h"

std::tr1::shared_ptr<Person>Person::create(const std::string& name) {

return std::tr1::shared_ptr<Person>(new RealPerson(name));

create() may choose between different implementations of the InterfaceClass at run-time.

Result

Clients only depend on person.h

Link between Person and RealPerson hidden in person.cpp

realperson.h can be changed without needing to recompile client code

Multiple concrete classes with different implementations

No interface to implemenation “glue code”

Cost of Interface Classes

All function calls are virtual (performance)

Additional virtual function table pointer per object (memory)

Result

Questions?

C++ Design Patterns Advanced C++ Programming Seminar, Summer Term 2009

Documents

Transcript of C++ Design Patterns Advanced C++ Programming Seminar, Summer Term 2009