Joel de Guzman wrote:
Joel de Guzman wrote:
I'll try to come up with a complete interface proposal that will encompass all use cases. It will be lightweight (no need for extra infrastructure) and efficient. I believe it can be done.
Ok, here's what I have for draft of the Case concept. I believe this is most crucial in the design of the switch_ as I proposed in a recent post. Comments, feedback, suggestions welcome.
AFAICT it looks very good. Here come some more thoughts:
Case Concept: Specialization of unary Polymorphic Function Object that, in addition to the requirements defined in Polymorphic Function Object, encodes a list of labels in its type necessary for switch dispatch.
Notation:
c, c0, c1, ... cN Case objects C A Case type I An MPL Integral Constant type i An MPL Integral Constant object N, First, Last Integral constants N0, N1, ...NN A list of integral constants f A unary function case_c, case_range_c, case_, default Case factories
Valid Expressions:
Expression Semantics ---------- -------------------------------------------------------- C::labels An MPL Sequence of Integral Constants
c(i) Function application
seemingly equivalent to c(I()) Function application (note: constant encoded in type). Maybe should be c.template apply<ResultType>(I()) instead (note: Passing in the result type).
case_<I>(f) Returns a Case object with supplied MPL Sequence of Integral Constants. forwarding to the encapsulated function object f.
I think this one should be called 'cases' and 'case_' should take a single MPL constant, for consistency.
case_c<N>(f) Returns a Case object with a single label N forwarding to the encapsulated function object f. Equivalent to: case_<mpl::vector_c<int, N> >(f) case_c< N0, N1, ...NN>(f) Returns a Case object with a list of labels forwarding to the encapsulated function object f. Equivalent to: case_<mpl::vector_c< int, N0, N1, ...NN> >(f) case_range_c< First, Last>(f) Returns a Case object with a range of labels forwarding to the encapsulated function object f. Equivalent to: case_<mpl::range_c< int, First, Last> >(f)
default_(f) Returns a Case object with an empty labels list. forwarding to the encapsulated function object f.
c0, c1, ... cN Returns a fusion sequence of Case objects
seemingly equivalent to (c0, c1, ... cN) (note: Application of comma operator ;-)). ?! Why doesn't it just return another (compound) Case object and leave the Sequence an unspecified implementation detail...
Notes:
* While c0, c1, ... cN returns a fusion sequence, it does not have to use Fusion. It can be a very simple cons list of references to the actual arguments similar to the zero overhead Proto expression tree. It must be compatible with Fusion though, but that can be abstracted away.
...this way we'd have that abstraction specified, already.
* case_c and case_range_c are simple shortcuts. The type of integral constant is int. The actual type can be casted to the actual switch parameter. I think this is safe, but a variation is to have case_c and case_range_c expect the actual type (like mpl::vector_c and mpl::range_c.). E.g.: case_c<int, N>.
I prefer the former.
* case_<I>(f) is equivalent to the original Steven interface.
We could have this case swallow the index during function invocation, as for manual application we probably don't want to have it. I think it's typical and easy enough to just model the Case concept directly... Regards, Tobias