Re: Conversion policies

Daniel Wallin <[email protected]> writes:

> At 03:34 2003-08-26, David Abrahams wrote:
>
>> > One important thing here is that we can't have any additional layers in
>> > conversion process; the result from the converter must go directly to
>> > the wrapped function. If it isn't obvious this is because we want to be
>> > able to return temporaries when the function expects a const&.
>> > This is also why it can be useful to deduce the T from const T&
>> > in the converter function.
>>
>>Well, there *is* another way: you can use in-place construction in the
>>converter object and always return a T const& instead of a T.  I
>>believe that's exactly what happens in Boost.Python.
>
> Yeah, but that does complicate the converter a bit. You'd need to
> supply something that is called post-call. 

Nope.  The converter itself can destroy the object in its destructor.
We simply check to see if its object pointer refers to its internal
storage, and only destroy the object in that case.  This is part of
what lets lvalue converters qualify for const& arguments.

> This also gives us some trouble when using the converter in a
> context where there is more than one call layer:
>
> std::string s = object_cast<const std::string&>(my_lua_object,
> my_policy(result));
>
> Obviously you could just remove the reference here, but it's just
> an example. ;)

I don't understand the problem here.

> One thing that would be cool is if you would be able to chain
> compile time selected converters with runtime dispatch
> converters.. Something like:
>
> chain(my_policy(result), default_policy)
>
> So that several converters can be tried even if you use a policy. Am I
> making sense here?

Not yet.

> I remember there being some discussion on string conversions on the
> C++Sig list, unicode -> const char* or something like that..

Yep, Lijun Qin posted something.

> I don't remember the solution to the problem in question but I remember
> you talking about extending the runtime conversion system to enable
> some type of runtime-dispatch post-call, correct? 

Yep.

> Anyway, in many cases this sort of problem could be solved with a
> converter policy instead of introducing the additional expensive
> virtual call at runtime.

1. Not expensive, because there's just one check for a non-null chain
   of postcall actions registered in the whole policies wad.

2. That requires lots of user intervention and attention to each
   function being wrapped.  Some people want to register converters
   with postcall actions which will take effect automatically

>> > How would we use the BOOST_TT_BROKEN_COMPILER_SPEC macro
>> > to provide specializations?
>>
>>We'd tell the user to write
>>
>>      BOOST_TT_BROKEN_COMPILER_SPEC(X)
>>
>>for any type X for which we need to be able to get
>>remove_reference<X>::type
>
> Ah, so the user would in this case specialize the type traits classes
> rather than the converters directly?

That's the idea.  It's possible to issue instructions to do the
specialization embedded in error messages.

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



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0