Merge pull request #950 from cubbimew/pimpl

New rule: I.27 Pimpl
This commit is contained in:
Andrew Pardoe 2017-06-12 11:20:56 -07:00 committed by GitHub
commit 19da9a1d03
2 changed files with 56 additions and 4 deletions

View File

@ -1202,6 +1202,7 @@ Interface rule summary:
* [I.24: Avoid adjacent unrelated parameters of the same type](#Ri-unrelated)
* [I.25: Prefer abstract classes as interfaces to class hierarchies](#Ri-abstract)
* [I.26: If you want a cross-compiler ABI, use a C-style subset](#Ri-abi)
* [I.27: For stable library ABI, consider the Pimpl idiom](#Ri-pimpl)
* [I.30: Encapsulate rule violations](#Ri-encapsulate)
See also
@ -2139,6 +2140,53 @@ If you use a single compiler, you can use full C++ in interfaces. That may requi
(Not enforceable) It is difficult to reliably identify where an interface forms part of an ABI.
### <a name="Ri-pimpl"></a>I.27: For stable library ABI, consider the Pimpl idiom
##### Reason
Because private data members participate in class layout and private member functions participate in overload resolution, changes to those
implementation details require recompilation of all users of a class that uses them. A non-polymorphic interface class holding a pointer to
implementation (Pimpl) can isolate the users of a class from changes in its implementation at the cost of an indirection.
##### Example
interface (widget.h)
class widget {
class impl;
std::unique_ptr<impl> pimpl;
public:
void draw(); // public API that will be forwarded to the implementation
widget(int); // defined in the implementation file
~widget(); // defined in the implementation file, where impl is a complete type
widget(widget&&) = default;
widget(const widget&) = delete;
widget& operator=(widget&&); // defined in the implementation file
widget& operator=(const widget&) = delete;
};
implementation (widget.cpp)
class widget::impl {
int n; // private data
public:
void draw(const widget& w) { /* ... */ }
impl(int n) : n(n) {}
};
void widget::draw() { pimpl->draw(*this); }
widget::widget(int n) : pimpl{std::make_unique<impl>(n)} {}
widget::~widget() = default;
widget& widget::operator=(widget&&) = default;
##### Notes
See [GOTW #100](https://herbsutter.com/gotw/_100/) and [cppreference](http://en.cppreference.com/w/cpp/language/pimpl) for the trade-offs and additional implementation details associated with this idiom.
##### Enforcement
(Not enforceable) It is difficult to reliably identify where an interface forms part of an ABI.
### <a name="Ri-encapsulate"></a>I.30: Encapsulate rule violations
##### Reason
@ -6851,7 +6899,7 @@ Since each implementation derived from its interface as well as its implementati
As mentioned, this is just one way to construct a dual hierarchy.
Another (related) technique for separating interface and implementation is [PIMPL](#???).
Another (related) technique for separating interface and implementation is [Pimpl](#Ri-pimpl).
##### Note
@ -15563,7 +15611,7 @@ through non-`const` pointers.
It is the job of the class to ensure such mutation is done only when it makes sense according to the semantics (invariants)
it offers to its users.
See also [PIMPL](#???).
See also [Pimpl](#Ri-pimpl).
##### Enforcement
@ -17354,7 +17402,7 @@ The `Link` and `List` classes do nothing but type manipulation.
Instead of using a separate "base" type, another common technique is to specialize for `void` or `void*` and have the general template for `T` be just the safely-encapsulated casts to and from the core `void` implementation.
**Alternative**: Use a [PIMPL](#???) implementation.
**Alternative**: Use a [Pimpl](#Ri-pimpl) implementation.
##### Enforcement

View File

@ -101,6 +101,7 @@ CplusplusCS
cpp
cpp98
CppCon
cppreference
CRTP
cst
cstdarg
@ -193,6 +194,7 @@ GFM
Girou
github
GitHub
GOTW
gp
GPLv3
gsl
@ -219,6 +221,7 @@ ifdef
iff
ifstream
impactful
impl
Impl
incompleat
increment1
@ -366,7 +369,8 @@ pb2
pc
performant
pessimization
PIMPL
pimpl
Pimpl
Pirkelbauer
PL4
PLDI