Re: [boost] [Boost-users] [switch_] Compound Cases [was Case Concept]

From: Joel de Guzman (joel_at_[hidden])
Date: 2008-01-14 18:53:31

Steven Watanabe wrote:
> AMDG
> 
> Joel de Guzman wrote:
>> Tobias Schwinger wrote:
>>
>>   
>>>>> (c0,c1,...,cN) being just another 'Case' rather than a 'Sequence'.
>>>>>         
>>>> o..k... Hmm.. so how would the resulting case object for this
>>>> expression look like:
>>>>
>>>>      case_c<1>(f1), case_c<2>(f2)
>>>>
>>>> ?
>>>>       
>>>      template< class SeqCases >
>>>      struct sequenced_case
>>>      {
>>> <snip>
>>>     
>> Sounds good to me! I like it. So, this involves the variation where
>> a case has an MPL sequence of labels. I knew there's something in
>> that that I like. Intuition, I guess. That is also why I use the
>> name case_ regardless of number. A compound case is just another
>> case anyway. Does not matter how many labels it serves.
>>
>> Not sure how, implementation-wise, this works for Steven. Steven?
>> If this pans out, I'll refine the concept one more time.
>>   
> 
> It's trivial to implement:
> 
> #define BOOST_SWITCH_CASE(z, n, data)\
>     case mpl::at_c<typename C::labels, n>::type::value: 
> return(c.apply<R>(mpl::int_<n>()));
> 
> My concern is
> 1) fall-through can't easily be added to the interface.

I have an idea I'd like to post in another update to the
case concept.

> 2) It seems like just another interface for a fusion sequence.
>     Is sequenced_case to be public?  If so, we need another
>     concept for its interface...

The point is that it is just another case. Whatever the
sequenced_case is, it's just a model of the case concept.
Sure it still has to be documented, but not as a separate
concept, but as a model of it.

Also, to me, it's most trivial to just make it an ET
tree:

      template< class CaseL, class CaseR >
      struct binary_case
      {
          CaseL l;
          CaseR r;

          binary_case(CaseL const& l, CaseR const& r)
             : l(l), r(r) {}

          typedef mpl::joint_view<
            typename CaseL::labels, typename CaseR::labels
          > labels;

          template< typename Result, class I >
          Result apply(I);
      };

Key points:

* apply is part of the concept. In this case, it dispatches
   to l or r depending on I

* hmmm.... maybe labels should be an mpl set.

* Building this using operator, is trivial.

* l and r could be held by reference to allow for the zero overhead
   when used in one expression.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net