Re: smart pointer clarifications
On Aug 21, 8:40 am, "Phil Bouchard" <p...@fornux.com> wrote:
"mlimber" <mlim...@gmail.com> wrote in message
news:2e3e012e-a35c-43e2-9fe0-f3678e88a417@d77g2000hsb.googlegroups.com...
On Aug 20, 12:57 pm, "Phil Bouchard" <p...@fornux.com> wrote:
[...]
Either we do it this way or we share the allocator across the contain=
er
and
smart pointer so that the smart pointer uses deallocate(void *):
1)
std::vector<shifted_ptr<int>, shifted_allocator<shifted_ptr<int> > > =
c1;
2)
std::vector<shifted_ptr<int, shifted_allocator<int> >,
shifted_allocator<shifted_ptr<int, shifted_allocator<int> > > > c2;
I don't even think option 2) is implementable.
I may just be dense, but I still don't see what you're getting at.
Can't you just use the deleter parameter to indicate special deletion?
Something like this (untested):
class C { /*...*/ };
template<class Alloc>
class MyDeleter
{
Alloc& m_alloc;
typedef typename Alloc::value_type T;
public:
MyDeleter( Alloc& alloc ) : m_alloc( alloc ) {}
// Might want a const T* version also
void operator()( T* const ptr )
{
m_alloc.destroy( ptr );
m_alloc.deallocate( ptr, sizeof(T) );
}
};
void Foo( MyAllocator<C>& alloc, const C& initVal )
{
typedef std::vector< std::tr1::shared_ptr<C> > VSPC;
VSPC v( 10 );
for( VSPC::iterator it=v.begin(); it != v.end(); ++it )
{
// Could hide these next lines in a factory function
C* const c = alloc.allocate( sizeof(C) );
alloc.construct( c, initVal );
it->reset( c, MyDeleter( m_alloc ) );
}
// ...
}
Now, when the vector "v" goes out of scope, the shared_ptrs use the
"alloc" object to deallocate their pointees.
What you are suggesting is very similar to option 2) I was anteriorly
explaining. In my case I was using the allocator passed in as a templa=
te
parameter as a deleter so that there is no need to repeatedly call the
overloaded constructor shared_ptr(T *, D *). I can't imagine calling t=
his
special constructor for each node pointer inside a container in a flexibl=
e
way. If I forget calling it for one pointer the compiler will not repo=
rt
any compilation error.
You said your option 2 was not implementable (perhaps it isn't; my
attempt was a little different). Have I presented a working
implementation supported by the standard and the approved extensions
in TR1 that accomplishes your goal of not having a smart pointer
expose itself for the sake of custom allocators? If so, it seems to me
that no change in the standard libraries is necessary, and authors of
smart pointers just need to model their own smart pointer design on
the standard one (cf. Scott Meyers's explanation of custom deleters:
http://www.artima.com/cppsource/top_cpp_aha_moments.html).
Moreover, use of custom allocators is rather rare in my experience,
but those who need them will need to be diligent in their use. Calling
an alternate constructor/reset function doesn't seem like a heavy
burden for that small number of advanced users, particularly when it
is combined with RAII techniques for proper destruction.
Compare also the discussion of memory pools in the FAQs:
http://www.parashift.com/c++-faq-lite/dtors.html#faq-11.14
Cheers! --M