[boost] Re: CopyPtr and ClonePtr

From: Kevin Atkinson (kevinatk_at_[hidden])
Date: 2000-03-06 06:41:00

Dave Abrahams wrote:
> 
> on 3/6/00 6:12 AM, Kevin Atkinson at kevinatk_at_[hidden] wrote:
> 
> > Simple example.
> >
> > // foo.hh
> >
> > #include "copy_ptr.hh"
> >
> > class Bar1;
> > class Bar2;
> >
> > class Foo {
> > int x_;
> > int y_;
> > autil::CopyPtr<Bar1> bar1_;
> > autil::CopyPtr<Bar2> bar2_;
> > public:
> > // other methods.
> > };
> >
> > //foo.cc
> >
> > #include "bar1.hh"
> > #include "bar2.hh"
> > #include "copy_ptr-t.hh"
> >
> > namespace autil {
> > template class CopyPtr<Bar1>;
> > template class CopyPtr<Bar2>;
> > }
> >
> > And that is ALL that is needed.  No need to write any copy constructors,
> > assignment constructors, or destructors.  This is why I think it makes
> > like simpler.  If no one else agrees than so be it.  I do not have time
> > to endlessly argue with you.
> 
> Patience, my son. Some ideas need time to gain understanding and acceptance.
> This is an intruiguing approach; I never thought to use explicit
> instantiation... but I still don't see what prevents some other client of
> foo from getting a compiler error here:
> 
> // client.cc
> #include "foo.hh"
> void f(Foo);
> void g(const Foo& foo) {
>     f(foo); // <-- illegal use of incomplete type 'Bar1'
> }

No that's ok.  I took GREAT pain to make sure that the code in
copy_ptr.hh never requires the complete definition of Bar1.  The worst
thing that will happen is undefined references which the explicit
installation takes care of.  For compilers with export support that may
not even be needed as copy_ptr-t.hh could be copy_ptr.cc but sense I
don't have access to such a compiler I do not know for sure.  I know my
code works with modern versions of gcc and egcs which is a pretty good,
except for the stdlib, as far as standard compliance goes.

Sorry If i sound implatent I just get annoyed when people can't read my
mind. :)

> 
> >>>> 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?
> >
> > All over the place in my Aspell program (http://aspell.sourceforge.net/)
> > for the very reason as demonstrated above.
> 
> Sorry, I _really_ must be missing something. How have you demonstrated the
> need for non-owning CopyPtr above?

What do you mean my non-owning.  The point of the CopyPtr that it ALWAYS
owns its object.  The own flag is for the very special case when it
doesn't and I don't even think I use it. It should be removed before
includes in boost as it just confuses things.  

-- 
Kevin Atkinson
kevinatk_at_[hidden]
http://metalab.unc.edu/kevina/