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

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.

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

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

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



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