[boost] Re: rebind<> bad; template template good

From: David B. Held (dheld_at_[hidden])
Date: 2002-10-03 13:10:12

"Aleksey Gurtovoy" <agurtovoy_at_[hidden]> wrote in message
news:4034600A4760D411B8720001031D84FB01096490_at_postoffice.office.meta...
> [...]
> 2) after:
>
>     struct ownership_policy1
>     {
>         template< typename T > struct apply
>         {
>             //...
>         };
>     };
> [...]

Ahh...it's all starting to clear up.  Nothing like a motivating example to
understand metaprogramming a bit better.  Now it's obvious to me why
everything should be a class.

> the third, not-really-working way has been chosen:
>
>  3) a don't-go-there way:

LOL!  Touche!

> [...]
> You have seen for yourself where it leads to :).

Indeed.  If only std::allocator<> could have been so fortunate...or were
member template classes available then?

> If you choose 2) then your 'smart_static_cast' example would be at least
as
> good as a version that uses template template parameters:
>
>     template <
>         typename T,
>         BOOST_SMART_POINTER_PARAMETERS,
>         typename U
>     >
>     inline smart_ptr<T,BOOST_SMART_POINTER_PARAMETERS>
>         smart_static_cast(
>             smart_ptr<U, BOOST_SMART_POINTER_POLICIES> const& p
>         )
>     {
>         return smart_ptr<T,BOOST_SMART_POINTER_POLICIES>(
>               p, detail::static_cast_tag()
>             );
>     }

Ok, this alone would be a compelling argument against template templates,
in my opinion.  But this...

> Of course, the fourth way would be this:
>
> 4)
>     // policies are still ordinary class templates, but with
>     // arbitrary number and order of template parameters
>
>     template< typename T >
>     struct ownership_policy1
>     {
>         //...
>     };
>
>     template< typename P1, typename T, typename P2 > // here
>     struct ownership_policy2
>     {
>         //...
>     };
>
>     template< typename T >
>     struct conversion_policy2
>     {
>         //...
>     };
>
>     // use MPL's lambda:
>
>     typedef smart_ptr< my
>         , ownership_policy1<_>
>         , conversion_policy1<_>
>         , ...
>         > my_ptr;
>
>     typedef smart_ptr< my
>         , ownership_policy2<param1,_,param2> // here!
>         , conversion_policy1<_>
>         , ...
>         > my_ptr2;
>
> The 'smart_static_cast' implementation still would be the same as above
> (the sane one!).

...needs some explaining!  I have a vague notion that MPL::lambda is
"currying a metafunction"?  It is producing a unary metafunction class?
You lost me on how this gets implemented.  In fact, that code looks like
pure magic to me...I have no idea how to go from what you wrote to
something my compiler will recognize. ;)  Before I go converting everything
to canonical template form or whatever, I could really use a bit of a
tutorial
on what's going on above.

Dave