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

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:
>> >
>> >>I think we need to stop using the term "policy" without qualification.
>> >>It gets too confusing.  Every time I do it, I mean CallPolicy (as in
>> >>Boost.Python).  I think when you do it you mean ConversionPolicy.  In
>> >>fact, why don't we say "[argument|result] [to|from]_xxx converter
>> >>generator" for what I called ConversionPolicy?
>> >
>> > Agreed. We still need to settle what a CallPolicy and converter generator
>> > actually is though. :)
>>
>>
>>I think a FromXXXConverterGenerator is a mixed compile-time/runtime
>>function object which produces a converter type.
>
> Hm ok, what would it do at runtime?

Produce a converter object.

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

>>AFAICT, too many concepts are getting collapsed together here.  Can
>>we try to draw more distinctions?
>
> Absolutely. I'm not sure where to start though. :)

I learned a lot from my attempt to do injected constructors.  I will
try to make a followup post in the next hour.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



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