| I l@ve RuBoard |
Item 30. The "Fast Pimpl" IdiomDifficulty: 6 It's sometimes tempting to cut corners in the name of "reducing dependencies" or in the name of "efficiency," but it may not always be a good idea. Here's an excellent idiom to accomplish both objectives simultaneously and safely. Standard malloc and new calls are relatively expensive.[5] In the code below, the programmer originally has a data member of type X in class Y.
// Attempt #1
//
// file y.h
#include "x.h"
class Y
{
/*...*/
X x_;
};
// file y.cpp
Y::Y() {}
This declaration of class Y requires the declaration of class X to be visible (from x.h). To avoid this, the programmer first tries to write: // Attempt #2
//
// file y.h
class X;
class Y
{
/*...*/
X* px_;
};
// file y.cpp
#include "x.h"
Y::Y() : px_( new X ) {}
Y::~Y() { delete px_; px_ = 0; }
This nicely hides X, but it turns out that Y is used very widely and the dynamic allocation overhead is degrading performance. Finally, our fearless programmer hits on the "perfect" solution that requires neither including x.h in y.h nor the inefficiency of dynamic allocation (and not even a forward declaration). // Attempt #3
//
// file y.h
class Y
{
/*...*/
static const size_t sizeofx = /*some value*/;
char x_[sizeofx];
};
// file y.cpp
#include "x.h"
Y::Y()
{
assert( sizeofx >= sizeof(X) );
new (&x_[0]) X;
}
Y::~Y()
{
(reinterpret_cast<X*>(&x_[0]))->~X();
}
Note: See Item 29 for more about the Pimpl Idiom. |
| I l@ve RuBoard |
| I l@ve RuBoard |
SolutionLet's answer the Item questions one at a time.
What the programmer almost certainly wants is something else, namely the Fast Pimpl idiom. The second part of the third question was: Can you think of a better way to get around the overhead? The main performance issue here is that space for the Pimpl objects is being allocated from the free store. In general, the right way to address allocation performance for a specific class is to provide a class-specific operator new() for that class and use a fixed-size allocator, because fixed-size allocators can be made much more efficient than general-purpose allocators. // file x.h
class X
{
/*...*/
struct XImpl;
XImpl* pimpl_;
};
// file x.cpp
#include "x.h"
struct X::XImpl
{
/*...private stuff here...*/
static void* operator new( size_t ) { /*...*/ }
static void operator delete( void* ) { /*...*/ }
};
X::X() : pimpl_( new XImpl ) {}
X::~X() { delete pimpl_; pimpl_ = 0; }
"Aha!" you say. "We've found the holy grail梩he Fast Pimpl!" you say. Well, yes, but hold on a minute and think about how this will work and what it will cost you. Your favorite advanced C++ or general-purpose programming textbook has the details about how to write efficient fixed-size [de]allocation functions, so I won't cover that again here. I will talk about usability. One technique is to put the [de]allocation functions in a generic fixed-size allocator template, perhaps something like this: template<size_t S>
class FixedAllocator
{
public:
void* Allocate( /*requested size is always S*/ );
void Deallocate( void* );
private:
/*...implemented using statics?...*/
};
Because the private details are likely to use statics, however, there could be problems if Deallocate is ever called from a static object's destructor. Probably safer is a singleton that manages a separate free list for each request size (or, as an efficiency tradeoff, a separate free list for each request size "bucket"梖or example, one list for blocks of size 0-8, another for blocks of size 9-16, and so forth). class FixedAllocator
{
public:
static FixedAllocator& Instance();
void* Allocate( size_t );
void Deallocate( void* );
private:
/*...singleton implementation, typically
with easier-to-manage statics than
the templated alternative above...*/
};
Let's throw in a helper base class to encapsulate the calls. This works because derived classes "inherit" these overloaded base operators. struct FastArenaObject
{
static void* operator new( size_t s )
{
return FixedAllocator::Instance()->Allocate(s);
}
static void operator delete( void* p )
{
FixedAllocator::Instance()->Deallocate(p);
}
};
Now, you can easily write as many Fast Pimpls as you like: // Want this one to be a Fast Pimpl?
// Easy, then just inherit...
struct X::XImpl : FastArenaObject
{
/*...private stuff here...*/
};
Applying this technique to the original problem, we get a variant of Attempt #2: // file y.h
class X;
class Y
{
/*...*/
X* px_;
};
// file y.cpp
#include "x.h" // X now inherits from FastArenaObject
Y::Y() : px_( new X ) {}
Y::~Y() { delete px_; px_ = 0; }
But beware! This is nice, but don't use the Fast Pimpl willy nilly. You're getting extra allocation speed, but as usual you should never forget the cost. Managing separate free lists for objects of specific sizes usually means incurring a space efficiency penalty, because any free space is fragmented (more than usual) across several lists. A final reminder: As with any other optimization, use Pimpls in general and Fast Pimpls in particular only after profiling and experience prove that the extra performance boost is really needed in your situation. Guideline
|
| I l@ve RuBoard |
1102
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
