Re: [boost] Re: Boostifying Loki::SmartPtr

From: Phil Nash (phil.nash.lists_at_[hidden])
Date: 2002-04-30 18:06:20

> "Phil Nash" <phil.nash.lists_at_[hidden]> wrote in message
> news:007801c1efe5$20b9c7c0$10b387d9_at_TimeMachine...
> > [...]
> > I think we all are (including Andrea,
>
> Umm...I hope you didn't just misspell "Andrei". ;)  I wasn't aware of an
> "Andrea" in this thread. ;)

Um.... err, she didn't stay long :-)
(ok, sorry Andrei, it was nothing personal - honest!)
Note to self: I must not post to boost *after* an evening at the pub with
colleagues. Uh-oh too late for this evening... I'll try harder next time :*)

> > > > Could the decision as to whether we use a linear inheritance
> > > > hierarchy or MI be deferred to yet another policy? (YAP?).

[..]

> In working on the chained policy version, I have decided that a policy
> mixer is indeed a good thing, although I'm not convinced that it needs
> MI.  However, your statement later on about using Typelist is right on,
> and I hope that Alexsey or Dave A. will help me understand enough
> MPL to implement this mixer idea.  I didn't want to let it out of the bag
> until I had gotten something working, but at this point, it's clear that
I'm
> not going to get anything working. ;)
>
> Ok, my idea for a linear chained policy mixer looks like this:

Cool! You've actually come up with an example implementation - which is much
more than I did. I'm not sure it is quite how I would do it, but until I
have some time to spend on this myself I can't really say too much... maybe
this weekend...
Thanks to your efforts we do at least have a start of a reference
implementation to discuss and pull apart now.
My biggest concern with what you present, however, is it's dependency on the
MPL library. I think this would hinder its acceptance as an idiom and as a
reasonable design decision within the context of smart_ptr. Of course if
using MPL is the simplest option by a significant degree then perhaps this
is not worth pursuing (at least not in this context). Do correct me if I am
wrong here, please.
I have a feeling it is not the only option, and will promise to try and
knock up an implementation at the weekend if you don't beat me to it.

Also, I have not analysed your code in great depth yet (for the same
reasons), just browsed through it, but I couldn't find the direct evidence
of your comment:

> P.S.  I guess I did need a little MI after all, huh? :(

... unless the MPL typelist stuff generates it (at this point in time I'm
familiar with the concept of MPL but not the specific usage). When I
mentioned typelists (indirectly) before I had in mind Andrei's
GenLinearHierarchy implementation. I don't know if there is a direct
equivalent in MPL (this is going to be a long weekend!)

Other than that, my only other comment is that the amount of code looks a
bit daunting, at least where this is specific to smart_ptr and is being
compared to the elegance of the direct MI approach. Perhaps a rattled out
generic solution would make this a redundant point. I hope so because I like
the idea in general (no pun intended).

> Usage:
>
> typedef smart_ptr<int,
>     policy_builder<ref_counted_mt, no_checking>::impl<int>
> > my_ptr;

This usuage looks reassuringly similar to my original,
off-the-top-of-my-head suggested usage. As you go on to say, even this can
be simplified to remove the redundant second <int> using TTP.
I'm still trying to think if we can reach the holy grail of being able to
typedef away the policies independantly of the type without template
typedefs, although I suspect not, at least not without significantly
complicating things even further... maybe I'll take a long weekend....

> The nice thing is that this works with any class that has a simple
> Policy template parameter.  You could make it even nicer by
> making the Policy parameter a template template param, and
> then you wouldn't have to specify T twice.  It's also nice because
> it works with a traditional hand-built policy chain as well.

Yup, you have nicely demonstrated the counter to Gennadiy's reservation that
the policies for a linear chain would need to be different from the same
policies for a MI arrangement (unless I mistook your example in haste).
Using some sort of policy mixer idiom we should be able to literally mix the
policies in any custom way (linear chained, MI, hybrid etc) independantly of
the policies themselves (except the policy_mixer policy, of course).

Overall, excellent job David! It's a great starting point. Whether it is
enough to help the case with smart_ptr remains to be seen. It may be that
the concept needs enough time to mature before it is acceptible as a serious
proposal to solving the linear vs MI trade-offs issue - time which we
probably do not have with smart_ptr (and maybe the trade-offs in question
are not big enough to justify the extra effort at this stage). I'm behind
it, though, and more so now I have seen a first attempt at a possible
implementation.

[)o
IhIL..