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

From: David B. Held (dheld_at_[hidden])
Date: 2002-05-01 11:56:42

"Phil Nash" <phil.nash.lists_at_[hidden]> wrote in message
news:006201c1f0ab$cc8b2730$7eb187d9_at_TimeMachine...
> [...]
> Cool! You've actually come up with an example implementation -
> which is much more than I did.

Well it is completely untested code, so it probably isn't even fair to call
it an
"implementation" yet.  I would just call it a "sketch".  In particular, I
failed to
take into account MPL's iterators.  I don't think I "dereferenced" properly
in
all cases.

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

Yes, I'd love to see someone else try it. ;)  I have no particular love for
wracking my brain over some tedious metaprogramming. ;)

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

Well, I chose MPL for a few reasons.  First, I wanted to try it out!  It
seemed cool, and it was finally an excuse to try to use it.  Second, I knew
that it had STL-like semantics, and so I tried to leverage that to get a
quick handle on it.  Hopefully, Alexsey isn't too embarrassed at the way
I butchered it. ;)  Third, even though I understand Andrei's typelists in
vague, theoretical terms, I knew it would take quite a while for me to
actually write a Loki::Typelist solution.  However, I also thought this
would
be an interesting opportunity to compare MPL with Loki::Typelist in a
more or less "real-world" situation. ;)  I'd love for Andrei or you or
someone to write up a comparable Loki::Typelist implementation.

> 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 no idea if MPL is the simplest option or not.  It seemed simple
enough to write.  I spent about an hour checking out the MPL docs to
write the hacked-up pseudocode that I did.

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

There's no race. ;)  I'm looking at trying to port boost::loki::smart_ptr
to VC6, but quickly discovered that it doesn't support template template
params. :(  How frustrating!

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

Another thing I observed is that a policy mixer *could* use MI instead
of linear chaining.  There are a few reasons you might want to do this.
First, it allows you to specify a partial policy list in any order (the
mixer
detects missing policies, and fills in defaults for you).  Second, the
smart_ptr implementation can do some more things if it can name the
policies explicitly (which it cannot do in a chain).  Third, it simplifies
the policy interfaces.  Note also that you never need to include the policy
mixer in the smart_ptr header.  For those that want lean-n-mean, they
just go with the defaults, or specify policies "the hard way".  For those
that want some help, they just #include the policy mixer, and plug-n-play.

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

Actually, Gennadiy is right.  The policies *are* a bit different between
the two, and short of some template metaprogramming magic, you
probably wouldn't want to try to "autodetect" which usage was in effect
for each template (they still take one template param each, so it's
theoretically possible).

Dave