Re: Re: [C++-sig] [Implementation] Calling wrapped functions, converters, policies

At 22:26 2003-09-18, David Abrahams wrote:
>Daniel Wallin <[email protected]> writes:
>
> > At 22:43 2003-09-17, David Abrahams wrote:
> >>Daniel Wallin <[email protected]> writes:
> >>
> >> > At 18:39 2003-09-17, David Abrahams wrote:
> >> >>As a matter of fact I think many static from_xxx converter types will
> >> >>want to wrap the default converter with additional behavior, so their
> >> >>state will need to include the postcall chain anyway.
> >> >
> >> > Yeah, I don't know how that would work. :|
> >>
> >>Derivation or aggregation are obvious approaches.
> >
> > Right. I was referring to the state object though, and how that could be
> > shared even by converters that are aggregated by other converters.
>
>I understand now.  I think the answer is simple: there is one state
>object for the call.  It is related by inheritance to the state
>object(s) needed by each converter.  In case you don't understand what
>I mean, see Modern C++ Design for a discussion of how that's done and
>http://tinyurl.com/nuur, http://tinyurl.com/nuux for examples.  To
>build the composite type, we'll use mpl::fold to traverse the sequence
>of converter generators.  Each converter generator will have a
>metafunction which gets an opportunity to modify the composite type
>being built.  It can check to see if the state type(s) it needs are
>already in the composite, and if not, add an extra inheritance layer
>[better, it can contain a nested type sequence of state elements and
>modifications to the composite type being constructed can happen in
>one place].  Since the entire state object gets passed to each
>converter, derived-to-base conversion can take care of getting the
>neccessary state elements.  A converter which needs two state elements
>just uses a templated reference argument for the state and dispatches
>it twice to an inner state-handler:
>
>    struct fancy_converter
>    {
>       template <class State>
>       fancy_converter(..., State& s)
>       {
>           initialize(s, s);
>       }
>
>       initialize(state_t1&, statet2&);
>    };
>
>The way to get sharing is simply to break down the state elements
>at a fine-enough level of granuarity.

Sounds good. I actually wrote something like this yesterday morning, except
I used the ConverterGenerator type instead of a nested type and I didn't
think about passing the entire state tuple to the converters.

   typename context_type<Policies>::type context(policies);

   typedef typename find_converter_generator<Policies, 1>::type c1_gt;
   typename c1_gt::template apply<T0, xxx_to_cpp>::type c1;

   typedef typename find_converter_generator<Policies, 2>::type c2_gt;
   typename c2_gt::template apply<T1, xxx_to_cpp>::type c2;

   context.precall(params);

   c1.convert(params[0], context.get((c1_gt*)0));
   c2.convert(params[1], context.get((c2_gt*)0));
                         ^^^^^^^^^^^^^^^^^
   context.postcall(params);

Anyway, this seems great. Perhaps the requirements on 
ConverterGenerators/CallPolicies
can be quite loose too;

   May or may not contain a 'state' typedef.
       - has_xxx

   The state typedef may or may not be a mpl sequence.
       - is_sequence

---
Daniel Wallin



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf