[boost] Re: Re: Proposal: Efficient Pointers

From: David B. Held (dheld_at_[hidden])
Date: 2002-07-17 19:28:22

"Philippe A. Bouchard" <philippeb_at_[hidden]> wrote in message
news:ah4vks$7nh$1_at_main.gmane.org...
>
> "David B. Held" <dheld_at_[hidden]> wrote in message
> news:ah4sgt$il$1_at_main.gmane.org...
> >
> >     template <typename P1>
> >     count_wrapper(P1 const& p1)
> >     { new (m_buffer) value_type(p1); }
> >
> >     template <typename P1, typename P2>
> >     count_wrapper(P1 const& p1, P2 const& p2)
> >     { new (m_buffer) value_type(p1, p2); }
>
> One little thing: the parameters P1, P2, ... will be copied.  This will
> remove some optimizations with the copy constructor.

Umm...are you sure?  Why won't they just get passed to the value_type
c'tor as is?

> Currently A(A(A(A(A(1, 2, 3))))) is equivalent to A(1, 2, 3) (of course
> A(A(A... will never happen but you may have a series of r-values).  Now
> I'm not sure if template <> count_wrapper(A const &) will start creating
> temporaries (?).

I'm not sure what this has to do with what I wrote.  I never even defined a
count_wrapper(value_type const&), because that is what results in a copy.

> [...]
> I haven't checked intrusive_ptr<> in depth yet but before,

Which is a good deal of the problem.  Boost is generally loathe to have
overlapping libraries, and your library overlaps intrusive_ptr<>
considerably.
I only mention it to save you some time.

> what do you think of:
> {
>     squad_ptr<A> p = squad_ptr<A>::reinterpret(new (new
> squad_ptr<A>::element_type) A(1, 2, 3));
> }

Personally, I think it is an abomination. ;)  I would never use a pointer
that
required that type of invokation, unless it also guaranteed wealth, power,
and a lifetime supply of Twinkies(TM).

> Or:
> #define SQUAD_PTR(_Tp, _Constructor)        \
>  squad_ptr<_Tp>::reinterpret(new (new squad_ptr<_Tp>::element_type)
> _Constructor)
>
> {
>     squad_ptr<A> p = SQUAD_PTR(A, A(1, 2, 3));
> }

Better, but having to resort to the preprocessor always makes me
nervous.  While the idea of an automatic count wrapper is nice (and I
tried to design one for quite a while), it seems to me that the general
consensus is that you can either afford to embed the count in your
object (derive from counted_base or whatever you like), or you can't.
We currently have pointers to handle both of those cases, that do what
you are suggesting, and more.  I can see the utility in making a count
wrapper, to assist with classes that you cannot directly touch, and where
you do not want a separate count pointer.  However, I think you will find
a lot of resistance to introducing an entire pointer class to handle this
case, when it can almost as easily be handled with the existing pointers.
Not many other people seem to want to toss in their opinion, but if you
search the archives, you'll see there has been quite a bit of discussion
on smart pointers in general over the last several months.  It might be
helpful to check out those discussions to get some history on what
issues people have covered.

Dave