Re: [boost] Are there any interest in a pimpl library?

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-09-28 08:34:06

From: "Asger Mangaard" <tmb_at_[hidden]>
> From: Martin Bonner <martin.bonner_at_[hidden]>
[don't snip attributions to text you quote]
> > From: Asger Mangaard [mailto:tmb_at_[hidden]]
> >
> >> The only thing my library does is to initialize the forward declared
> >> class, using heap or static memory through policies. Also, provides an

What about pimpl types with non-default constructors?  I can see
an assignment operator taking an impl *, making your proposed
class like a reseatable smart pointer.  That would permit the
client to construct the impl any way necessary and then just hand
it off to your class.

> >> easy way of accessing the data.
> >>
> >> .hpp
> >>
> >> boost::pimpl<struct CMyData> m_MyData;

No forward declaration on a separate line is helpful, I suppose.

> >> The CMyData will be initialized the first time its data members are
> >> accessed.
> >
> > That means each use of m_MyData operator ->() has got to check whether the
> > structure is initialized or not, and initialize it if so.  Isn't it much
> > easier to initialize the pimpl struct in the constructor of the outer
> > class?
> 
> The 'already initialized' check is optimal through a policy. The main

I take it you mean that your policy can construct the impl
instance when the pimpl is instantiated and then opt to not check
in the member selection operator?  If so, that should probably be
the default mechanism.  The policy you describe should be called
something like, "lazy_creation."

> advantages are:
> 
> * Correct copying of pimpl data members. Eg.

That's helpful.

> .hpp
> struct STest
> {
>   STest& operator = (const STest& _copy);
> 
>   boost::pimpl<struct CMyData> m_MyData;
> };
> 
> .cpp
> STest& STest::operator = (const STest& _copy)
> {
>   m_MyData = _copy.m_MyData;
>   return *this;
> }

Actually, you'd just let the compiler generate the copy
assignment operator in this case, which is quite useful.

> would work, where as the raw way would be something like:
> 
> .hpp
> struct STest
> {
>   STest& operator = (const STest& _copy);
> 
>   struct CMyData* m_MyData;
> };
> 
> .cpp
> STest& STest::operator = (const STest& _copy)
> {
>   m_MyData = _copy.m_MyData;
>   return *this;
> }
> 
> and would cause the CMyData pointer to be copied around.

...so of course you'd manage the memory yourself.  This *is* an
advantage to your proposal.

> This is probably the reason to why pimpl idioms are mostly used by
> singleton-like classes (managers, components, etc.) With this new library
> one can easily apply the pimpl idiom to all kinds of classes (game
> objects, etc.)

I don't limit my use to such types.

> · The new/delete/static calls are handled automatically. Eg. actually no
> need for a con/destructor.

...unless needed by the impl type.

> I hope this answers your questions.

It would have been helpful to have listed these things in your
original post.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;