Re: Re: Conversion policies

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

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

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

Yeah but the call is still expensive..

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

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

Ok, great.

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