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

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

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

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

---
Daniel Wallin




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