Boost logo

Boost :

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-05-12 18:47:12


Joel de Guzman wrote:
> Tobias Schwinger wrote:
>
>
>>2. Fusion and MPL placeholder expressions
>>
>> MPL placeholder expressions are very convenient for specifying the result
>> because of their lazy nature (see lines 267, 312). Of course, this approach
>> trades compile time for syntactic sugar. The syntactic sugar might not be
>> entirely irrelevant, because it allows us to emphasize even complex problems
>> with little code.
>
>
> Sure.
>
>
>> So, I still wonder, whether it is a good idea to use MPL lambda for the
>> result computation or not. Is it?
>
>
> I think so, yes.
>
>
>> If so (even occasionanlly), it would be necessary to have at least accessors
>> for pair members (they are needed to keep the evaluation lazy, see line 211)
>> or, ideally, if there would be a normalization between the STL and the MPL
>> pair concepts (then MPL's accessors, 'first' and 'second', could be borrowed).
>
>
> If my suggestion to make mpl/fusion pair fully conforming mpl/fusion
> sequences is accepted, then you can use code like mpl::begin<_> or
> mpl::at<_, N>.
>

It's a very cool suggestion, IMO (just for the protocol: seems 'mpl::begin' was
supposed to read 'mpl::front').

But it seems we're still talking about different pairs of shoes (shoes of pairs?):

Given the (actually) unspecified type members of 'mpl::pair' get "_type"-suffixes, any pair would just work with MPL *as a pair*. That is, the 'first' and 'second' metafunctions are trivial and (unlike all sequence-stuff) not tag-dispatched, so their instantiation is very lightweight and especially nice for within iteration...

>
>> (It would also be cool if one could just typedef the lambda expression to nested
>> result or inherit from a wrapper. I don't know whether it's possible and a good
>> idea - this part is just loud thinking)...
>
>
> Hmmm... can you elaborate. I lost you here.
>

OK. I believe it works best with some imaginary code:

// rtc stands for runtime code
// rmf stands for result metafunctions

   struct a_func
     : result< munch< _1, tweak<_2> > >
   {
      template<typename A, typename B>
      typename result<A,B>::type operator()(A const & a, B const & b) const
      {
        return rtc::munch(a,rtc::tweak(b));
      }
   };

-------------

   namespace rmf
   {
      typedef result< munch<_1,tweak<_2> > > a_func;
   }

   namespace rtc
   {
      struct a_func
        : rmf:: a_func
      {
         template<typename A, typename B>
         typename result<A,B>::type operator()(A const & a, B const & b) const
         {
            return munch(a,tweak(b));
         }
      };
   }

Regards,

Tobias


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk