Re: [C++-sig] [Implementation] Calling wrapped functions, converters, policies

Daniel Wallin <[email protected]> writes:

> At 12:35 2003-09-23, David Abrahams wrote:
>>Daniel Wallin <[email protected]> writes:
>>
>> > At 14:46 2003-09-22, David Abrahams wrote:
>> >>Daniel Wallin <[email protected]> writes:
>> >>
>> >> > At 18:53 2003-09-21, David Abrahams wrote:
>> >> >>Daniel Wallin <[email protected]> writes:
>> >> >>
>> >> >> >>Actually I was thinking that the index should be encoded in the type
>> >> >> >>of the converter.
>> >> >> >
>> >> >> > Ok, both approaches work.
>> >> >>
>> >> >>I think we may have single converter tuple at this point.  If so we'll
>> >> >>want something like:
>> >> >>
>> >> >>        converters.convert(argument_package,mpl::int_<1>());
>> >> >
>> >> > I have expressed some concern on this before due to the issue with an
>> >> > additional layer when returning temporaries from convert().
>> >> > (with const& argument types..)
>> >> >
>> >> > I would rather see something like:
>> >> >
>> >> >     get<0>(converters).convert(argument_package);
>> >> >
>> >> > or
>> >> >
>> >> >     get<0>(converters).convert(argument_package, mpl::int_<0>());
>> >>
>> >>I'm sorry, I don't see why one should be more problematic than the
>> >>other, but I'm willing to go with your first alternative if you like.
>> >>I think the 2nd one is unneccessary.
>> >
>> > It's problematic because of how the 'converters tuple' type would be
>> > implemented. I guess it could be implemented with inheritance,
>> > and require that converters take an mpl::int_<N> where N is their
>> > index.
>>
>>Name hiding could cause a problem there... unless... we could have a
>>using declaration built into the components to get around that.
>
> Right.
>
>     template<class Base, class T>
>     struct tuple_elem
>        : Base, T
>     {
>        using Base::f;
>        using T::f;
>     };
>
>     struct empty_type
>     {
>        void f();
>     };
>
>     typedef inherit_linearly<
>           sequence_t
>         , tuple_elem<_,_>
>         , empty_type>::type composite_t;
>
> Would work I guess. But that puts some additional requirement on the
> convert() signature..

You mean just matching the argument index?  Big deal(?)

>> > But as I saw this it would probably be implemented with a
>> > forwarding function which would obviously cause problems if the
>> > converter would return a temporary which should bind to a const&.
>>
>>It seems to me that if you know enough to return the temporary
>>properly from the inner function, you know enough to return it from
>>the outer one.  Otherwisee you're screwed anyway.
>
> All you need to know is that T = const U& to return a temporary from
> convert(). If there was another layer in between, there is no way that
> layer could deduce that it should return a temporary instead of const&
> because if it did, everything that actually returns references would
> get broken.

I'll take your word for it.

>> > Now that I think about it it wouldn't be that problematic to
>> > implement with inheritance instead, although it does complicate the
>> > convert() signature a bit.
>>
>>I honestly don't care how it's done internally, as long as it's
>>convenient for users and extenders.
>
> Ok, that's my goal as well. Lets move on. :)

Yes, lets!

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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf