Boost logo

Boost :

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

Steven Watanabe wrote:
> 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

      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.


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at