[boost] Re: CopyPtr and ClonePtr

From: Dave Abrahams (abrahams_at_[hidden])
Date: 2000-03-06 05:48:33

on 3/6/00 5:40 AM, Kevin Atkinson at kevinatk_at_[hidden] wrote:

> No.  Just don't include the "*-t.hh" header files.  Include them
> elsewhere where the definition of Pimpl is known and if nessary
> instanstae the copy ptr for Pimpl.

I don't believe in writing header files which, to be correctly compiled,
require other headers to be manually included. This is simply too confusing
and too much work for clients of an interface. With your technique it is
valid to use Foo until you try to copy it. At that point you suddenly get
compiler errors. That doesn't seem like a kind way to treat clients.

>> Comparing these with what's required if auto_ptr<> is used instead of
>> CopyPtr, I don't see much savings.
>> 
>> Foo::Foo(const Foo& rhs)
>> : pimpl_(new Pimpl(*rhs.pimpl_))
>> 
>> Foo& Foo::operator=(const Foo& rhs)
>> {
>> //assign bases, other members here
>> pimpl_ = std::auto_ptr<Pimpl>(new Pimpl(*rhs.pimpl_));
>> }
> 
> Here you are unessary makeing a new copy with new.  This is unnessearly
> expensive. When
> a *pimpl_ = *other.pimpl_ will do if there were pure pointers and in
> fact this is what CopyPtr does with the assignment method.

Er, right, of course. You're just proving my point though:
pimpl_ = rhs.pimpl_ vs. *pimpl_ = *rhs.pimpl_ doesn't seem like a big win.

>> Okay, I'll concede that the incantation for assignment is simpler, but the
>> swap-based version is actually identical.
> 
> No its not.

Okay, you're right again: it differs by two '*' characters, just like the
above. But where's the big advantage?

>> Also, the idea that some CopyPtrs can own their target while others do not
>> is worrisome to me. It certainly seems like an unneccessary complication and
>> a good hole to drive bugs through.
> 
> Well it works VERY well for me.  Perhapes not for others.

What do you use it for?

-Dave