Re: Re: Conversion policies

At 03:34 2003-08-26, David Abrahams wrote:
>Daniel Wallin <[email protected]> writes:
>
> > At 17:20 2003-08-22, David Abrahams wrote:
> >
> >>2. If this is just an issue of user-customization, I am learning to
> >>    prefer not distorting interfaces for broken compilers.  I'd rather
> >>    ask those users to apply BOOST_TT_BROKEN_COMPILER_SPEC in order to
> >>    produce the neccessary specializations for us to work in one
> >>    uniform way.  I know that doesn't *directly* address partial
> >>    ordering, but I think you can usually transform all partial
> >>    ordering problems into partial specialization problems, can't you?
> >
> > Yes, in this particular case we could just use a template parameter
> > to the converter to deduce the type, given that we don't care about
> > non conforming compilers.
> >
> > template<int N>
> > struct my_policy : converter_generator_tag<N>
> > {
> >     template<class T>
> >     struct generate_converter
>
>This should be called "apply" so that my_policy<N> is a metafunction
>class.

Ok.

> >     {
> >        typedef my_converter<T> type;
> >     };
> > };
> >
> > 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. 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. ;)

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?

I remember there being some discussion on string conversions on the
C++Sig list, unicode -> const char* or something like that..
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? 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.

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

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