Re: [Boost-users] formal review of Switch library ends tomorrow (Wednesday, January 9th) - reviews needed

10 Jan 2008

      AMDG

Tobias Schwinger  writes:
...
...
To be honest, I really don't see your point. I still don't see why
you'd want to build A on top of B.
1. As a thought experiment to figure out which of the two variants is 
the more basic one, and
2. for parameterizing a single function with compile time information 
looked up by index (it's quite common and -as you can probably guess- 
the index can be very handy inside the metaprogram).
Now that I have figured out that your interface accepts sequences, we 
can actually express the transforms between the two:
A ---> B: function := L(I): functions[I]()
     B ---> A: transform(cases, L(I): make_pair<I>(bind(function,I())))
// Notation:
     // =========
     // uppercase - types
     // lowercase - objects
     // L(args):  - lambda composition
I don't expect us to a reach consensus, but hopefully we do understand 
each other's points now.
How about:

switch(n, Cases, f, default?)

Make Cases a fusion sequence the types of which must have
a nested ::value.

Then, make each case look like:

typedef fusion::result_of::value_at_c::type case_n;
case case_n::value:
    if(returns()) return(f(fusion::at_c<n>(cases)));
    else f(fusion::at_c<n>(cases));

If Cases is an MPL sequence this becomes equivalent to A.

By using

  template
  struct case_t {
      static const int value = N;
      F impl;
  };

  template
  struct returns > : mpl::false_ {};

in Cases and

  template<class R>
  struct call_function {
      template<class T>
      R operator()(T t) {
          return(t());
      }
  };

for f it becomes B.

Just a thought...

In Christ,
Steven Watanabe