Boost logo

Boost :

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2008-01-12 06:24:05

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...


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