Re: Re: Conversion policies

At 18:10 2003-08-26, David Abrahams wrote:
>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:
> >> >
> >>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.

Right.

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

Yeah you're right, I did agree to that. I'm just trying to clear things up. ;)
It is still unclear to me how runtime and compile time converters will
interact though, like in the case of our "adopt" policy.. In luabind it's
a converter, in langbinding perhaps it will be a policy with a post-call
action which removes ownership instead. I don't know..

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

Ok. Out of curiosity, why should it 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?

Ok, I was just rambling about how compile time converters could
interact with runtime converters. I should have named "chain"
"composite" instead; it tries all it's converters and returns a best
match, just like the runtime system does.

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

Right.

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

Ok I'm convinced; this is a good feature.

---
Daniel Wallin



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