Re: Conversion policies

Daniel Wallin <[email protected]> writes:

> At 13:59 2003-08-26, David Abrahams wrote:
>>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.
>
> Yeah I know, the destructor can be that something that you supply.
> It doesn't matter in the case of our runtime converters, but it does
> complicate things for the user if we do have converters that does
> everything at compile time. (Since the user will have to write the
> destructor rather than just returning a temporary..).

It need not complicate matters for users.  There are two ways to deal
with it:

     1. wrap what the user supplies in something which stores the
     temporary in the internal storage

     2. Let users replace the T const& return with a T return via
     specialization. 

I confess, though, that I am really confused about where this is
coming from, since I was sure you had agreed that "100% compile-time
converters" are not worth their costs.

>> > 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.
>
> The problem here is that the constructed temporary will be destroyed before
> it's returned from object_cast<T>(). Given that object_cast<T> is actually a
> function rather than a type with implicit an cast to T of course..

It's called "extract" in Boost.Python and 

     1. Yes, it's a type with an implicit conversion operator

     2. Extraction of a reference to a temporary should fail at runtime

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

You gonna explain this stuff?

>> > 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.
>
> Yeah but the call is still expensive..

But the chain will usually be null so there is no call.

>>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
>
> Yeah I guess. Where does the storage for the postcall action come from?
> Heap allocation?

Sure.  It can be made "arbitrarily cheap" with allocator customization.

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