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

From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2002-05-01 09:21:26

> "Phil Nash" <phil.nash.lists_at_[hidden]> wrote in message
> news:006501c1f0ab$d2d5def0$7eb187d9_at_TimeMachine...
> > (1) We started out with that "good reason" - to allow for compilers that
> > don't do EBO (or don't do a good job of it - David's analysis seems to
> > suggest there are middling degrees).
>
> I do not think that compilers deficiency should drive our design

Fair comment. But I am not sure there is total consensus on that.

> > (2) I argued that, with the complexity encapsulated up in the
policy_mixer
> > we don't introduce too much more into the design
>
> It seems that in some other post you named amount of code used to present
> only sketch "daunting in comparison with MI solution".

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.
David's suggestion was just a starting point. There does seem to be interest
in a policy_mixer, but it is becoming increasingly apparent that this is
non-trivial in itself, and we would probably need a more mature proposal
before it can realistically be suggested as a solution to the smart_ptr
policy relationship issue.
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.

Of course, I'm not in start disagreement with your comments.
I think I've probably said as much as I can on the policy_mixer for now -
until I have time to invest in  proposed implementation myself (or someone
else does).

Regards,

[)o
IhIL..