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
> > [...]
> > 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
> 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
> > personally like the idea of the policy_mixer and think it *could* work
> > the smart_ptr design - but am *moving* towards the pragmatic view that
> > may not have a usable policy_mixer in place in the time frame needed to
> > 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).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk