Your SlideShare is downloading. ×
Idiomatic C++
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Idiomatic C++

654
views

Published on

A minimal collection of most wanted and widely accepted idioms and coding conventions for C++ development presented with examples and explanations. The lecture targets performance oriented codes so …

A minimal collection of most wanted and widely accepted idioms and coding conventions for C++ development presented with examples and explanations. The lecture targets performance oriented codes so emphasis is on performance-friendly techiques.

Topics covered:
1) Design issues: idioms and best practices
- Resource Aquisition Is Initialization (RAII)
- Ownership semantics and smart pointers
- Header files: dependencies and decoupling
2) Objects Construction/Destruction/Copying
- Designing constructors
- Rule Of Three
- Transactional programming
3) Namespaces
- ADL/Koenig Lookup
4) Static analyzers

Published in: Technology

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
654
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
1
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Federico Ficarelli http://www.linkedin.com/in/fficarelli
  • 2.     Chapter 1: Design Issues Chapter 2: Construction/Destruction/Copying Chapter 3: Namespaces Appendix: Tools Federico Ficarelli, Idiomatic C++ 2
  • 3. 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  Federico Ficarelli, Idiomatic C++ 3
  • 4. Design Issues: Idioms and Best Practices
  • 5. 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. Federico Ficarelli, Idiomatic C++ 5
  • 6. 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); }; Federico Ficarelli, Idiomatic C++ 6
  • 7. 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 } Federico Ficarelli, Idiomatic C++ 7
  • 8. // 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 // ... } Federico Ficarelli, Idiomatic C++ 8
  • 9. 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. Federico Ficarelli, Idiomatic C++ 9
  • 10.    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. Federico Ficarelli, Idiomatic C++ 10
  • 11. 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(); // ? } Federico Ficarelli, Idiomatic C++ 11
  • 12. 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) Federico Ficarelli, Idiomatic C++ 12
  • 13. 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. Federico Ficarelli, Idiomatic C++ 13
  • 14. 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; // pt2->DoSomething(); // pt1->DoSomething(); // } // ~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). Federico Ficarelli, Idiomatic C++ 14
  • 15.    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() ); // ? Federico Ficarelli, Idiomatic C++ 15
  • 16. 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 Federico Ficarelli, Idiomatic C++ 16
  • 17. 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. Federico Ficarelli, Idiomatic C++ 17
  • 18. 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>()); Federico Ficarelli, Idiomatic C++ 18
  • 19. 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(); } Federico Ficarelli, Idiomatic C++ 19
  • 20.    Expresses «weak» (latent) ownership; must be casted to shared_ptr before actual use (no operators); essential to break reference cycles. typedef std::tr1::shared_ptr<T> sh_ptr; typedef std::tr1::weak_ptr<T> wk_ptr; typedef std::tr1::shared_ptr<T> sh_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 } } // ? Federico Ficarelli, Idiomatic C++ 20
  • 21. 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() } Federico Ficarelli, Idiomatic C++ 21
  • 22. Header files should be written to:  be self-sufficient;  be portable;  minimize dependencies;  avoid pollution of client’s names search space. Federico Ficarelli, Idiomatic C++ 22
  • 23. #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_ Federico Ficarelli, Idiomatic C++ 23
  • 24. // 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. Federico Ficarelli, Idiomatic C++ 24
  • 25.     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 Federico Ficarelli, Idiomatic C++ 25
  • 26. #include <date.h> #if !defined(IDIOMATICCPP_USE_INLINE) // <-#define INLINE #include <date-inl.h> #endif #include <iostream> // ...from date.h: // ... // Inline Guard Idiom #if defined(IDIOMATICCPP_USE_INLINE) #define INLINE inline #include <date-inl.h> #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. Federico Ficarelli, Idiomatic C++ 26
  • 27.    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. Federico Ficarelli, Idiomatic C++ 27
  • 28.   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. Federico Ficarelli, Idiomatic C++ 28
  • 29. // 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).  Federico Ficarelli, Idiomatic C++ 29
  • 30.     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). Federico Ficarelli, Idiomatic C++ 30
  • 31. // 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_; } Federico Ficarelli, Idiomatic C++ 31
  • 32. 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. Federico Ficarelli, Idiomatic C++ 32
  • 33. 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; } Federico Ficarelli, Idiomatic C++ 33
  • 34. 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) { 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 can be implemented via C's public interface) make f a non-member function; else make f a member function of C; Functions: the Meyer’s Algorithm [Effective C++] Federico Ficarelli, Idiomatic C++ 34
  • 35. 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. Federico Ficarelli, Idiomatic C++ 35
  • 36. Construction/Destruction/Copying
  • 37. 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. Federico Ficarelli, Idiomatic C++ 37
  • 38. 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. Federico Ficarelli, Idiomatic C++ 38
  • 39. 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; }; Federico Ficarelli, Idiomatic C++ 39
  • 40. 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; // ? } Federico Ficarelli, Idiomatic C++ 40
  • 41. 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 Federico Ficarelli, Idiomatic C++ 41
  • 42.   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. Federico Ficarelli, Idiomatic C++ 42
  • 43. 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. Federico Ficarelli, Idiomatic C++ 43
  • 44. dumb_string& operator=(const dumb_string& other) { 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. Federico Ficarelli, Idiomatic C++ 44
  • 45. 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_string& operator=(const dumb_string& other) { 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.  Federico Ficarelli, Idiomatic C++ 45
  • 46. 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. Federico Ficarelli, Idiomatic C++ 46
  • 47. 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. Federico Ficarelli, Idiomatic C++ 47
  • 48. Namespaces
  • 49. 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. Federico Ficarelli, Idiomatic C++ 49
  • 50.  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; Federico Ficarelli, Idiomatic C++ 50
  • 51. 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. Federico Ficarelli, Idiomatic C++ 51
  • 52. #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>) Federico Ficarelli, Idiomatic C++ 52
  • 53. «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. Federico Ficarelli, Idiomatic C++ 53
  • 54. // 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. Federico Ficarelli, Idiomatic C++ 54
  • 55. Tools
  • 56.      Clang Static Analyzer Mozilla dehydra vera++ cppcheck Google cpplint Federico Ficarelli, Idiomatic C++ 56