Idiomatic C++

Federico Ficarelli
http://www.linkedin.com/in/fficarelli






Chapter 1: Design Issues
Chapter 2: Construction/Destruction/Copying
Chapter 3: Namespaces
Appendix: Tools

Federico Ficarelli, Idiomatic C++

2

Herb Sutter and Andrei Alexandrescu, C++
Coding Standards
 Bjarne Stroustrup’s C++ Style and Technique
FAQ [www.stroustrup.com/bs_faq2.html]
 stackoverflow.com, C++faq tag
 Microsoft Channel 9 [http://channel9.msdn.com/]
 Scott Meyers, Effective C++
 cppreference.com
 Bjarne Stroustrup, The C++ Programming
Language



3

Design Issues:
Idioms and Best Practices

void foo ()
{
char* ch = new char[100];
if (...)
if (...)
return;
else if (...)
if (...)
else
throw "ERROR";
// This may not be invoked...
delete [] ch;
}
void bar ()
{
lock.acquire();
if (...)
if (...)
return;
else
throw "ERROR";
// This may not be invoked...
lock.release();
}

In order to guarantee resources
release, we need to keep track of:
 natural return;
 return statements;
 exceptions thrown.
Issues:
 code complexity;
 duplicated code (copy and paste);
 forces to catch and re-throw
(even if we aren’t able to handle it);
 error prone.

5

Exception Safety Rule:
the only code that is guaranteed to be executed after an
exception is thrown are the destructors of objects residing on
the stack.

template <class T>
class AutoDelete
{
public:
AutoDelete (T * p = 0) :
ptr_(p) {}

class ScopedLock
{
public:
ScopedLock (Lock & l) : lock_(l) {
lock_.acquire();
}

~AutoDelete () throw() {
delete ptr_;
}
private:
T *ptr_;
DISALLOW_COPY_AND_ASSIGN(AutoDelete);
};

~ScopedLock () throw () {
lock_.release();
}
private:
Lock& lock_;
DISALLOW_COPY_AND_ASSIGN(ScopedLock);
};

6

RAII:
every time you need to wrap and manage a resource (memory, file,
lock, etc...) in a class, let the constructor acquire and the destructor
release it: the stack semantics will release the resource when it leaves
the scope.
void foo() {
AutoDelete<X> safe_del(new X());
if (...)
if (...)
return;
// No need to call delete here.
// Destructor will delete memory
}
void bar() {
ScopedLock safe_lock(l);
if (...)
if (...)
throw "ERROR";
// No need to call release here.
// Destructor will release the lock
}

7

// Da Stroustrup’s C++ FAQ:
class File_handle {
FILE* p;
public:
File_handle(const char* n, const char* a) {
p = fopen(n,a);
if (p==0) throw errno;
}
File_handle(FILE* pp) {
p = pp;
if (p==0) throw errno;
}
~File_handle() { fclose(p); }
operator FILE*() { return p; }
// ...
};

void f(const char* fn) {
File_handle f(fn,"rw");
// use file through f,
// don't care about release
// ...
}


8

Constructor:
it must acquire the managed resource and, in case of failure,
raise a proper exception. The acquisition process must be RAII
itself (without relying on the destructor).
Destructor:
it starts with a valid and constructed object (guaranteed by
constructor) and must release the resource. It cannot fail.
Single Responsibility Principle:
every class should have a single, clear responsibility and that
responsibility should be entirely encapsulated by the class.

9





Automatic lifetime, tightly bound to stack
semantics;
each resource type needs a proper resource
holder;
strict ownership, resources cannot be (easily
and cleanly) passed around.


10

Ownership Semantics:
an object owns a resource when it has the responsibility to release
that resource.

How can we explicitly express ownership in C++?
// Header file
// ...
// AMAZING documentation about
// the following function.
Resource* get_resource();
// ...

struct Resource {
void foo() { /* ... */}
};
Resource* get_resource() {
return new Resource;
// Ownership implicitly transferred to the caller
}

int main (void) {
get_resource()->foo(); // ?
}

11

Strict ownership, transfer allowed

Strict ownership, transfer not allowed

std::auto_ptr<T>
std::unique_ptr<T>

(C++03)
(C++11)

boost::scoped_ptr<T>
(no std)
const std::auto_ptr<T> (C++03)
std::tr1::scoped_ptr
(C++03)

boost::shared_ptr<T>
(no std)
std::tr1::shared_ptr<T> (TR1)
std::shared_ptr<T>
(C++11)

Shared (multiple) ownership

boost::weak_ptr<T>
std::tr1::weak_ptr<T>
std::weak_ptr<T>

(no std)
(TR1)
(C++11)


12

Strict Ownership, Transfer Allowed:
the auto_ptr has semantics of strict ownership, meaning that there is only one
auto_ptr instance responsible for the object's lifetime. If an auto_ptr is copied, the
source loses the reference.
#include <memory>
int main() {
T* pt1 = new T;

#include <memory>
int main() {
std::auto_ptr<T> pt( new T );
}
// <-- ~T()

// pass ownership to an auto_ptr
std::auto_ptr<T> pt2( pt1 );
*pt2 = 12;
// same as "*pt1 = 12;
pt2->SomeFunc(); // same as "pt1->SomeFunc();




// use get() to see the pointer value
assert( pt1 == pt2.get() );
// use release() to take back ownership
T* pt3 = pt2.release();
// no owner, no auto-delete!
delete pt3;
}



Same semantics as raw ptr;
when the owner goes out of
scope, raw ptr is destroyed
(operator delete);
we can release ownership
and take back the raw ptr.

13

int main() {
auto_ptr<T> pt( new T(1) );
pt.reset( new T(2) );// ~T(1), owns T(2)
} // ~T(2)




int main() {
auto_ptr<T> pt1( new T
auto_ptr<T> pt2;
//
pt1->DoSomething(); //
pt2 = pt1;
//
} // ~T()

); // pt1 owns
pt2 non-owning
ok
pt1 -> pt2
ok
!!!

Ownership can be explicitly dropped and set
on the fly (reset);
a non-owning auto_ptr has the same
semantics as NULL pointer: never
dereference it (check with operator bool).

14






No custom deleter, can manage objects
allocated with operator new only;
copying and assigning changes the owner of
a resource, modifying not only the lhs but
also the rhs, which breaks assignment
semantics;
cannot be used in stl
containers.
std::vector< std::auto_ptr<T> > v;
/* ... */

std::sort( v.begin(), v.end() ); // ?


15

Strict Ownership, Transfer Not Allowed:
the scoped_ptr has semantics of strict ownership, meaning that there is only one
scoped_ptr instance responsible for the object's lifetime. The owning scoped_ptr
cannot be copied, ownership cannot be transferred.







Used to show explicit ownership;
supports custom deleter;
useful for automatic deletion of local objects
or class members (PIMPL, RAII, etc...)
can be “simulated” using the
const auto_ptr Idiom.

const auto_ptr<T> pt1( new T );
auto_ptr<T> pt2( pt1 ); // illegal
auto_ptr<T> pt3;
pt3 = pt1;
// illegal
pt1.release();
// illegal
pt1.reset( new T );
// illegal

16

Shared Ownership:
the shared_ptr has semantics of multiple ownership, meaning that multiple owning
instances are allowed at a time. The instance is reference counted*: it will be destroyed
only when the last owner is released.






Useful when object’s lifetime is complex and
not tied to a particular scope/object;
supports custom deleter;
can be safely used inside stl containers.


17

int main() {
typedef std::tr1::shared_ptr<T> sh_ptr;

Reference count semantics

Custom deleter

sh_ptr p1;
{
sh_ptr p2(new T()); // ref = 1
p1=p2; // ref = 2
} // ref = 1
} // ref = 0 -> ~T()

template <typename T>
class ArrayDeleter {
public:
void operator() (T* d) const {
delete [] d;
}
};
std::tr1::shared_ptr<double>
array (new double[256], ArrayDeleter<double>());


18

template<class T> class decorator {
private:
T * p_;
public:
explicit pointer(T * p): p_(p) {}
shared_ptr<T> operator->() const {
p_->prefix();
return std::tr1::shared_ptr<T>(p_, std::mem_fn(&T::suffix));
}
};

class X {
private:
void prefix();
void suffix();
friend class decorator<X>;
public:
void f();
void g();
};

int main() {
X x;
decorator<X> px(&x);

px->f();
px->g();
}


19






Expresses «weak» (latent) ownership;
must be casted to shared_ptr before actual
use (no operators);
essential to break reference cycles.
typedef std::tr1::weak_ptr<T> wk_ptr;

struct T {
sh_ptr other;
};
void test() {
sh_ptr p1
sh_ptr p2
p1->other
p2->other
} // ?

(new T());
(new T());
= p2; // p1 -> p2
= p1; // p2 -> p1

struct T {
wk_ptr other;
};
void test() {
sh_ptr p1 (new T());
sh_ptr p2 (new T());
if( sh_ptr p = p1->other.lock() ) {
p(p2); // p1 -> p2
}
if( sh_ptr p = p2->other.lock() ) {
p(p1); // p2 -> p1
}
} // ?

20

Resource Return Idiom:
never return raw pointers from within functions; prefer conveying resource ownership
explicitly in the return type.







Makes factory
functions ownership
explicit;
use any type of smart
ptr (depending on your
needs);
improves robustness
dramatically.

// Header file
// ...
// AMAZING documentation about
// the following function.
std::auto_ptr<Resource> get_resource();
// ...
struct Resource {
void foo() { /* ... */}
/* ... */
};

std::auto_ptr<Resource> get_resource() {
return std::auto_ptr<Resource>( new Resource );
// Ownership EXPLICITLY transferred
// to the caller
}
int main (void) {
get_resource()->foo(); // ~Resource()
}

21

Header files should be written to:
 be self-sufficient;
 be portable;
 minimize dependencies;
 avoid pollution of client’s names search
space.


22

#ifndef _DATE_H_
#define _DATE_H_

void set_date(int month, int day, int year) {
month_ = month;
day_ = day;
year_ = year;
}

#include <iostream>
#include <math.h>
#include <muslimdate.h>
using namespace std;

inline void Convert(MuslimDate* other) {
// Some heavy work...
// from math.h:
double res = exp(somevalue);
// ...
*other = MuslimDate(/*...*/)
}

namespace calendar {
class Date
{
private:
int month_, day_, year_;

inline int get_month() { return month_; }
inline get_day() { return day_; }
inline get_year() { return year_; }

friend ostream & operator<<
(ostream &os, const Date& d);
};
public:
Date() {
set_date( 1, 1, 1970 );
}
Date(int month, int day, int year) {
set_date(month, day, year);
}
// ...

ostream & operator<<(ostream &os, const Date& date)
{
return os << day_
<< "/"
<< month_ << "/" << year_;
}
} // namespace calendar
#endif // _DATE_H_


23

// date.h
#ifndef IDIOMATICPP_DATE_H_16032013 // <-#define IDIOMATICPP_DATE_H_16032013
#include <iosfwd> // <--

// ...
// Inline Guard Idiom
#if defined(IDIOMATICCPP_USE_INLINE)
#define INLINE inline
#include <date-inl.h>
#endif

namespace calendar {
} // namespace calendar
class MuslimDate; // <-- Forward
#endif // IDIOMATICPP_DATE_H_16032013
class Date
{
private:
int month_, day_, year_;
friend std::ostream & operator<<
(std::ostream &os, const Date& d);
public:
Date();
Date(int month, int day, int year);
void set_date(int month, int day, int year);
void Convert(MuslimDate* other);
int get_month();
int get_day();
int get_year();
};







Guards: avoid clashes and
reserved identifiers;
prefer forward declarations;
remove unused inclusions;
remove using statements;
be sure that the pure header
is made of declarations only.

24







Collect all inline
definitions in a separate
header;
beware of C std
headers;
no using statements
(qualify all identifiers);
be sure that the inline
header is made of inline
definitions only.

// date-inl.h
#ifndef IDIOMATICPP_DATE_INL_H_16032013 // <-#define IDIOMATICPP_DATE_INL_H_16032013
#include <muslimdate.h>
#include <cmath> // <-#include <date.h>
INLINE void Date::Convert(MuslimDate* other) {
// Some heavy work...
double res = std::exp(somevalue); // <-// ...
*other = MuslimDate(/*...*/)
}
INLINE int Date::get_month() { return month_; }
INLINE int Date::get_day() { return day_; }
INLINE int Date::get_year() { return year_; }
#endif // IDIOMATICPP_DATE_INL_H_16032013


25

#include <date.h>
#if !defined(IDIOMATICCPP_USE_INLINE) // <-#define INLINE
#endif
#include <iostream>

// ...from date.h:
// ...
// Inline Guard Idiom
#if defined(IDIOMATICCPP_USE_INLINE)
#define INLINE inline
#endif
// ...

using namespace std; // <-using namespace calendar;
Date::Date() { set_date( 1, 1, 1970 ); }



Date::Date(int month, int day, int year) {
set_date(month, day, year);
}
void Date::set_date(int month, int day, int year) {
month_ = month;
day_ = day;
year_ = year;
}
ostream & operator<<(ostream &os, const Date& date)
{
return os << day_ << "/"
<< month_ << "/" << year_;
}



Put the Idiom’s flip
side in a single
implementation file;
inlining can be
controlled by a proper
macro definition.

26





The vast majority of header-related idioms
care about decoupling;
the main goal is to reduce dependencies and
build time;
accepted downsides could impact
performance.


27




Classical OO approach to decoupling;
invokes implementation of an abstraction/class
using runtime polymorphism;

Dependency Inversion Principle:
implementation classes should not depend on each other. Instead, they should
depend on common abstraction represented using an interface class.


28

// Abstract base class -> Interface
class Exporter {
public:
virtual std::string
toString(Document* doc) = 0;
};
// Concrete interface implementors (Liskov)
class CSVExporter : public Exporter {
public:
std::string toString(Document* doc)
{ /* ... */ }
};
class XMLExporter : public Exporter {
public:
std::string toString(Document* doc)
{ /* ... */ }
};

// Client (Open Close Principle)
class ExportController {
private:
Exporter* m_exporter; // <-public:
void setExporter(Exporter* exporter);
void runExport();
};
void ExportController::runExport() {
Document* currentDocument =
GetCurrentDocument(); // <-- Factory
// (no ctors)
String exportedString =
m_exporter->toString(currentDocument);
String exportFilePath = GetSaveFilePath();
WriteStringToFile(exporterString, exportFilePath);
}

DIP: ExportController (higher level interface) has no
knowledge of any Exporter subclass (lower level interface);
 both depend on abstract Exporter interface (the common
abstraction).



29






The language makes private members
inaccessible but not invisible;
idiom meant to completely decouple
interface (and clients) from implementation;
implements a true compilation firewall;
consider carefully the advantages (build
time, insulation) and downsides (extra
indirection level).

30

// myclass.h:
class MyClass {
private:
struct MyClassPIMPL;
MyClassPIMPL* pimpl_;

// myclass.cpp:
#include "myclass.h"
// Forward
// Handle

public:
Handle();
Handle(const Handle&);
Handle& operator=(const Handle&);
~Handle();
// Other operations...
};

// myclass.h:
class MyClass {
private:
struct MyClassPIMPL;
shared_ptr<MyClassPIMPL> pimpl_;
public:
// ...
};

struct MyClass::MyClassPIMPL {
int a, b;
};

MyClass::MyClass()
: pimpl_(new MyClassPIMPL()) {
// do nothing
}
MyClass::MyClass(const MyClass& other)
: pimpl_(new MyClassPIMPL(*(other.pimpl_))) {
// do nothing
}
MyClass& MyClass::operator=(const MyClass &other) {
delete pimpl_;
*pimpl_ = *(other.pimpl_);
return *this;
}
MyClass::~MyClass() {
delete pimpl_;
}

31

When implementing functionalities, the common belief
is that OO prefers members.
Function Placement:
when implementing new functionalities, prefer non-member non-friend
functions.





Improves encapsulation by minimizing
dependencies: the function cannot depend nonpublic members (“Don’t give away your
internals”);
breaks apart monolithic classes to liberate
separable functionalities, reducing coupling.

32

class NetworkBuffer {
public:
bool empty() {
return
this->device->get_packets_count() == 0;
}
/* ... */
};
class List {
public:
bool empty() {
return
this->length == 0;
}
/* ... */
};

class NetworkBuffer {
public:
size_t size() {
return
this->device->get_packets_count();
}
/* ... */
};
class List {
public:
size_t size() {
return this->length;
}
/* ... */
};
template<class T>
bool empty( const T& s )
{
return s.size() == 0;
}


33

if (f needs to be virtual)
make f a member function of C;
else if (f is operator>> or operator<<)
{
make f a non-member function;
if (f needs access to non-public members of C)
make f a friend of C;
}
else if (f needs type conversions on its left-most
argument)
{
if (f needs access to non-public members of C)
make f a friend of C;
}
else if (f can be implemented via C's public
interface)
else
make f a member function of C;

Functions: the Meyer’s Algorithm [Effective C++]

34

1.

2.
3.
4.
5.
6.

Ensure resources are owned by objects. Use
explicit RAII and smart pointers to expose
ownership and enforce exception safety.
Give one entity one cohesive responsibility.
Keep your header files clean, don’t harm
clients (nor yourself).
PIMPL and DIP judiciously.
Don’t optimize prematurely:
correctness, simplicity and clarity come first.
Don’t pessimize prematurely.

35

Construction/Destruction/Copying

Design and implementation of the Big Four:
 default construction,
 copy construction;
 copy assignment,
 destruction.
Pay attention:
 compiler can generate them for you;
 the language treats classes with value
semantics by deafult.

37

Failing Constructors:
“You should throw an exception from a constructor whenever you cannot
properly initialize (construct) an object. There is no really satisfactory alternative
to exiting a constructor by a throw”. [Stroustrup’s C++ FAQ]




Throwing from within a constructor is the
most safe and widespread technique;
the «init method» technique is unsafe and
breaks RAII and all the idioms discussed in
this chapter.

38

Warning: the constructor itself must be
exception-safe (without relying on destructor).
class T {
public:
T(std::size_t len = 0) :
array( new int[len] ),
buffer( new char[len]) {} // <-- ?
// Destructor (omitted)
private:
int* array;
char* buffer;
};

class T {
public:
T(std::size_t len = 0) :
array( new int[len] ),
buffer( new char[len]) {} // <-- ?
// Destructor (omitted)
private:
std::shared_array<int> array;
std::shared_array<char> buffer;
};


39

Rule Of Three:
if you need to explicitly declare either the destructor, copy constructor or copy
assignment operator yourself, you probably need to explicitly declare all three
of them.
class dumb_string {
public:
dumb_string(std::size_t size = 0) : // conversion/default
mSize(size),
mArray(mSize ? new char[mSize]() : 0) {}
dumb_string(const dumb_string& other) : // copy
mSize(other.mSize),
mArray(mSize ? new char[mSize]() : 0) {
std::copy(other.mArray, other.mArray + mSize, mArray);
}
virtual ~dumb_string() { // destructor
delete [] mArray;
}
private:
std::size_t mSize;
char* mArray;
};

int main() {
dumb_string a(10);
dumb_string b(a);
dumb_string c;
c = a; // ?
}

40

Disable Copying:
whenever it makes sense, explicitly disable copy by construction and by
assignment. This prevents the language from treating types with
unwanted/erratic value semantics.

#define DISALLOW_COPY_AND_ASSIGN(TypeName)
TypeName(const TypeName&);

void operator=(const TypeName&)
// ...
private:
DISALLOW_COPY_AND_ASSIGN(T);
};

template <class T>
class NonCopyable
{
protected:
NonCopyable () {}
~NonCopyable () {} // Protected non-virtual
private:
NonCopyable (const NonCopyable &);
NonCopyable & operator = (const NonCopyable &);
};
class CantCopy : private NonCopyable <CantCopy> {};

CRTP Mixin: enables Empty Base Optimization

41





We need to implement the copy-assignment
operator in order to have a correct value
semantics;
operator= is much more hard to implement
in a robust way than the copy constructor:
 must handle an already constructed object;
 in case of failure, it must leave the object in the

previous consistent state (rollback).
The copy-assignment operator must be transactional.

42

dumb_string& operator=(const dumb_string& other)
{
if (this != &other) // <-{
// Tear down object’s state…
delete [] mArray; // <-mArray = 0; // avoid double-deletion in case of RAII
// ...and setup the new one...
mSize = other.mSize; // <-mArray = mSize ? new int[mSize] : 0;
std::copy(other.mArray, other.mArray + mSize, mArray); // <-}
return *this;
}

Issues:
 self assignment test: a symptom of non-robust
implementation; usually very rare (performance
waste);
 non exception-safe.

43

{
if (this != &pOther) // <-{
// setup the new data ready before we teardown the old
std::size_t newSize = other.mSize;
int* newArray = newSize ? new int[newSize]() : 0; // <-std::copy(other.mArray, other.mArray + newSize, newArray);

// replace the old data (all are nothrow)
delete [] mArray;
mSize = newSize;
mArray = newArray;
}
return *this;
}

Issues:
 code duplication.

44

friend void swap(dumb_string& first, dumb_string& second) throw()
{
std::swap(first.mSize, second.mSize); // throw()
std::swap(first.mArray, second.mArray); // throw()
}
{
dumb_array temp(other);
swap(*this, temp); // <-return *this;
}

dumb_string& operator=(dumb_string other) // <-{
swap(*this, other); // <-return *this;
}

Pass by Value: enables Copy Elision Optimization

Rule-of-Three-and-a-half:
whenever it makes sense, provide a no-fail swap.

Enables strong exception-guarantee (especially the RVO
version);
 enables type to be used with a large number of idioms.



45

Foundations Never Fail:
everything that destructor, deallocation (e.g.: operator delete)
and swap functions attempt shall succeed: never allow an error to be
reported from within them. They are the foundation of transactional
programming: without their resilience, no-fail rollback is impossible to
implement.


46

When writing a class, consider:
 Rule-of-three(and-a-half) to obtain correct
and robust value semantics for complex
types;
 «None-of-three» for POD/aggregates (let the
compiler generate them for you);
 explicitly disable copy-construction and copy
assignment.

47

Interface Principle:
for a class T, all functions (including non-member) that both "mention" T
and are "supplied with" T in the same namespace are logically part of
T, because they form part of T's interface.



The language is explicitly designed to enforce
the Interface Principle, ADL/Koenig Lookup
was added for this reason.

49



Only occurs if the normal lookup of an unqualified
name fails to find a matching class member
function.

“The set of declarations [...] considered for resolution of the
function name is the union of the declarations found by normal
lookup with the declarations found by looking in the set of
namespaces associated with the types of the function
arguments”. [C++03, 3.4.2]
// using namespace std;
std::cout << "hello" << std::endl;


50

namespace type {
class T {
public:
void f();
};
}
namespace ops {
T operator+( const T&, const T& );
}
int main() {
// using ops::operator+;
type::T a, b;
a.f();
type::T c = ops::operator+(a, b);
}

namespace ns {

class T {
public:
void f();
};
T operator+( const T&, const T& );
}

int main() {
ns::T a, b;
a.f();
ns::T c = a + b;
}

Interface Principle, corollary:
keep a type and its non-member function interfaces in the same namespace.


51

#include <vector>
namespace N {
struct X {};
template <typename T> int* operator+( T, unsigned )
{ /* do something */ }
}
int main() {
std::vector<N::X> v(5);
v[0]; // <-- v.begin() + 0
}

Depending on std implementation, ADL may
choose:
 std::operator+
 N::operator+ (pulled in the name search by
vector<N::X>)

52

«Dual» Interface Principle:
avoid putting non-member functions that are not part of the interface of
a type T into the same namespace as T, and especially never put
templated functions or operators into the same namespace as a userdefined type.

Help prevent name-lookup accidents: protect
types from unwanted ADL.


53

// f1.h
namespace A {
int f(double);
}
// g.h
namespace B {
using A::f;
void g();
}
// f2.h
namespace A {
int f(int);
}

Beware: B::g resolution (and
semantics) depends on the
headers inclusion order.

Namespace Using Principle:

// g.cpp
B::g() {
f(1); // <-- ?
}

avoid putting using namespace directives before any inclusion
directive. Since the inclusion ordering is out of implementor’s control and
depends on client’s implementation, never put using namespace
directives inside header files.

54







Clang Static Analyzer
Mozilla dehydra
vera++
cppcheck
Google cpplint


56

Idiomatic C++

More Related Content

What's hot (20)

Viewers also liked (19)

Similar to Idiomatic C++ (20)

Recently uploaded (20)

Idiomatic C++