Re: [boost] Re: Re: Re: RFC: Inheritance alternatives for policy-based smart_ptr

From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2002-05-01 20:28:52

> "Phil Nash" <phil.nash.lists_at_[hidden]> wrote in message
> news:007701c1f123$de32dff0$cb54883e_at_TimeMachine...
> > [...]
> > Yes that's right. I believe the two comments go hand in hand. If my
> > argument is that "the complexity encapsulated up in the policy_mixer
> > we don't introduce too much more into the design", then a policy_mixer
> > design that seems "daunting in comparison with MI solution" is not yet a
> > good fit.
>
> All I can say is...look at iterator_adaptor. ;)  Complexity certainly
didn't
> prevent it from getting accepted. ;)

Good point. That's reassuring. But in the context of the smart_ptr
discussion we have to contend with an existing design that uses straight MI
with virtually no complexity.
Don't worry I haven't dropped the bastion of policy_mixers just yet ;-) ...
just trying to be realistic too...

> > [...]
> > Just to summarise, before you pull me up again for being inconsistent
:-)
> I
> > personally like the idea of the policy_mixer and think it *could* work
for
> > the smart_ptr design - but am *moving* towards the pragmatic view that
we
> > may not have a usable policy_mixer in place in the time frame needed to
> get
> > smart_ptr accepted into boost.
> > [...]
>
> Well, unless I'm mistaken, it will probably be a very cold day in a
> characteristically warm place before a new smart pointer gets reviewed,
> let alone accepted into boost. ;)  I think we have plenty of time.

It could be me that is mistaken, but I was under the impression that we
wanted to move quickly to get a policy-based smart_ptr into boost as the LWG
have specifically requested it. It seems to me that we need something fairly
stable in boost before the october meeting, and we have a lot of things to
get through yet...
I would like to be persuaded that we have a chance of getting a policy_mixer
proposal for smart_ptr taken seriously. If so it would likely be a simple,
specialised, variant for the purposes of smart_ptr (but in that case I would
hope that it could be done in such a way that a more general implementation
could be substituted at a later date).

Regards,

[)o
IhIL..