[boost] Re: [mpl] Advice on usage

From: David B. Held (dheld_at_[hidden])
Date: 2002-10-08 21:01:02

"Aleksey Gurtovoy" <agurtovoy_at_[hidden]> wrote in message
news:4034600A4760D411B8720001031D84FB010964AD_at_postoffice.office.meta...
> David B. Held wrote:
> [...]
> mpl::identity?

Nice.

> [...]
> Fixing a missing typename

Technically, my version wasn't missing a typename, because I was using
is_same<>::value with if_c. ;)

> and style a little bit, here's an "approved" version :)

But I do like your version better.  Thanks for the tip.  I see that apply_if
combines an if_ with a dereference, which happens to be the same as
an apply.  I wouldn't have figured that out on my own. ;)  Now, I notice
that
you don't bother to hide "private metavariables", but just make everything
struct.  Is that simply because it would be silly to try to use any of the
the
intermediate results, and thus there's no point to try to hide any of the
implementation details?

> [...]
> A question - why BOOST_STORAGE_POLICY et al. instead of, let's say,
>
>     typename get_storage_policy<policies_,T>::type
>
> ?

Good question.  Two reasons.  One, repetition.  They appear twice, and
something as complex as this isn't something I want to spend time on
synchronizing whenever I make a minor change (this is the kind of thing
I'd spend an hour on diagnosing).  Two, what I didn't show is the template
template version (which I left in for historical reasons).  The usage is
controlled by BOOST_SMART_POINTER_LEGACY_INTERFACE, but
ironically, only works on a few compilers.  Nonetheless, I felt that the
library
should retain this interface, and it doesn't impose a great burden on it
(though I haven't tested it with the older interface in a while...probably
should see what I've broken ;).

> I don't have any complexes about preprocessor usage (MPL is a living
> prove of it :), but those BOOST_XXX_POLICY #define-s make me
> wince ;).

I agree.  I'd rather not have any macros at all, but conditional compilation
leaves me no choice.

> [...]
> Probably to have an associative container in MPL, but not now :). Feel
> free to contribute, of course.

Hmm...so if I understand correctly, I would add all the defaults to the
container, then add the specified policies according to their categories,
overwriting the default values.  Then iterate over the container to get
the final policies?  I might be able to hack a cheeseball metamap, though
not a tree implementation (yet).

> [...]
> In one or another form 'apply_lambda<>' is going to end up in the library
> itself, so don't bother to merge that :).

Ah.  Thanks for the tip.

> [...]
> Does it answer your question?
> [...]

Yes, exactly.  Thanks.

Dave