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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-09-28 11:30:28

From: "Asger Mangaard" <tmb_at_[hidden]>
> 
> I'm sorry, but I'm really having a hard time figuring out if you're
> strickly ironic in your answer or not?

The only thing remotely ironic in what I wrote was WRT the
one-versus-two-line declaration.  That is, your scheme avoids a
separate line for the declaration of the impl type, and I was
noting that it was only marginally better.

> Do you like the idea or not?

It seems as if it could be quite useful.

> > From: "Asger Mangaard" <tmb_at_[hidden]>
> >> From: Martin Bonner <martin.bonner_at_[hidden]>
> > [don't snip attributions to text you quote]

This wasn't irony.  I was being prescriptive.

> >> > 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.

I'd still like to hear what you have in mind here.

> >> >> easy way of accessing the data.
> >> >>
> >> >> .hpp
> >> >>
> >> >> boost::pimpl<struct CMyData> m_MyData;
> >
> > No forward declaration on a separate line is helpful, I suppose.

Here's where I was acknowledging a marginal benefit.

> >> 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."

What do you think of this?

> >> advantages are:
> >>
> >> * Correct copying of pimpl data members. Eg.
> >
> > That's helpful.

That's not irony.  I was noting that your approach was helpful on
this point.

> >> .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.

Clearly, there's no irony here.  There was a tiny bit of sarcasm
in that few would copy the pointer as shown.

> >> I hope this answers your questions.
> >
> > It would have been helpful to have listed these things in your
> > original post.

Here I was pointing out that your initial points omitted a great
many details that were necessary for us to understand your
proposal and took many replies to extract.  This, too, was
prescriptive so that your future messages will be more helpful up
front.

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