Re: [boost] [Boost-users] [switch_] Compound Cases [was Case Concept]
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. 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... In Christ, Steven Watanabe
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
AMDG Joel de Guzman wrote:
Steven Watanabe wrote:
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.
Great.
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.
No, thank you. mpl set is buggy and slow. Also, one thing that needs to be nailed down is: What Is I? Tobias was using it as the index into the list of labels: mpl::int_<0>, mpl::int_<1>, mpl::int_<2>, ... In my original interface and as you seem to be using it I is one of: mpl::at_c<labels, 0>::type, mpl::at_c<labels, 1>::type, mpl::at_c<labels, 2>::type In Christ, Steven Watanabe
Steven Watanabe wrote:
* hmmm.... maybe labels should be an mpl set.
No, thank you. mpl set is buggy and slow.
:-) Ok.
Also, one thing that needs to be nailed down is: What Is I? Tobias was using it as the index into the list of labels: mpl::int_<0>, mpl::int_<1>, mpl::int_<2>, ... In my original interface and as you seem to be using it I is one of: mpl::at_c<labels, 0>::type, mpl::at_c<labels, 1>::type, mpl::at_c<labels, 2>::type
It's in the concept I presented: I An MPL Integral Constant type Here: http://boost.org/libs/mpl/doc/refmanual/integral-constant.html Anything special I am missing? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
AMDG Joel de Guzman wrote:
Steven Watanabe wrote:
Also, one thing that needs to be nailed down is: What Is I? Tobias was using it as the index into the list of labels: mpl::int_<0>, mpl::int_<1>, mpl::int_<2>, ... In my original interface and as you seem to be using it I is one of: mpl::at_c<labels, 0>::type, mpl::at_c<labels, 1>::type, mpl::at_c<labels, 2>::type
It's in the concept I presented:
I An MPL Integral Constant type
Here:
http://boost.org/libs/mpl/doc/refmanual/integral-constant.html
Anything special I am missing?
What I meant was where they come from and thus how they should be interpreted. If you have mpl::vector_c<int, 4,2, 7> do you get mpl::int_<0>, mpl::int_<1>, and mpl::int_<2> or mpl::int_<4>, mpl::int_<2>, and mpl::int_<7>? In Christ, Steven Watanabe
participants (2)
-
Joel de Guzman -
Steven Watanabe