[boost] Re: Re: Proposal: Efficient Pointers

From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2002-07-17 20:34:23

"David B. Held" <dheld_at_[hidden]> wrote in message
news:ah51tf$ce3$1_at_main.gmane.org...
> "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?

No sorry; I've just tested it.  Even though:

1) you cannot match the same number of arguments in every situations;
2) you won't be able to construct a constant object.

[...]

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

Ha ha ha.

I must warn you I'm a former assembler programmer and I'll do everything in
favor of speed optimization (then memory)... even if it requires some
oddities...  And Boost shouldn't discriminate assembler programmers ! :)

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

It's not that bad if you use them for code simplifications (but never for
functionnality).  Here is another good looking macro taking advantage of gcc
extensions:

#define squad_target(_Constructor)        \
 squad_ptr<typeof(_Constructor)>::reinterpret(new (new
squad_ptr<typeof(_Constructor)>::element_type) _Constructor)

{
    squad_ptr<A> p = squad_target(A(1, 2, 3));
}

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

The main problem resides mostly at construction time: deriving classes,
wrappers, copy constructor usages, deprecated compound literals, ... not too
many options are left now.

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

Philippe A. Bouchard