From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-10-12 11:14:33
"Tobias Schwinger" <tschwinger_at_[hidden]> wrote in message
news:ckg0rf$t0m$1_at_sea.gmane.org...
> Jonathan Turkanis wrote:
> > "Tobias Schwinger" <tschwinger_at_[hidden]> wrote:
> >>Comparsion (JTFT versus TSFT):
> >>------------------------------
> >>
> >>The JTFT separate function I/O signatures into result, arguments
> >>and optionally class. TSFT only separates the input signature from the
> >>result. I have no idea which approach is better as there are
> >>applications where JTFT is more convenient (implementing closures) or
> >>where TSFT is more convenient ((full) argument binding). Both interfaces
> >>semantically make sense to me. While I read it now - I think I like the
> >>JTFT interface better... What were your thoughts on this design ?
> >
> >
> > To me it's more natural not to consider the implicit object pointer position
to
> > be part of the argument list, which is why I chose my design. Whichever is
> > implemented from scratch, the other can be implemented easily as a wrapper.
> >
>
> Even though I thought quite a bit about separating them while writing it
> - and I decided not to do so. Your interface does seem more natural and
> thus preferable to me.
Okay, it's settled. ;-)
> >>2. Strip out the synthesis part and replace it with an mpl-sequence
> >>implemenation backed with (all) signature types.
> >>Step 2 is not that new. Alexander brought it up (well at least the base)
> >>when we started this discussion.
> >
> >
> > Just to make sure we're on the same page, are you refering to these
comments:
> >
> > "Alexander Nasonov" <alnsn_at_[hidden]> wrote:
> >
> >>Conversion to mpl::vector and back to signature would slow down
> >>a compilation. Why waste your time if function_arguments can be
> >>made as fast as mpl::vector after applying similar optimization
> >>techniques?
> > ?
> No. It was in the thread I brought up that this is missing.
> Alexander suggested function_signature<T> could model an mpl sequence
> itself instead of having function_signature<T>::type be an mpl sequence.
Okay, I searched but couldn't find it.
> >>I did find it too complicated and tried to keep things "safe and simple"
> >>in my proposal (it was meant as an extension to Type Traits rather than
> >>MPL ;+). However, if you really want to go that far in terms of
> >>modifying/synthesizing signature types, I believe this is the right way
> >>to go.
> >
> >
> > This is fine with me. Unfortunately, I'm probably not familiar enough with
mpl
> > optimization techniques to write a sequence type that will yield better
> > performance than translating to and from mpl::vector. I hope you or
Alexander
> > have a better grasp of these issues then I do. I does sound fun, though.
> >
>
> A basic imlpementation could look just like 'vector' but with a few
> typedefs more...
Okay.
> As you said: it sounds fun - and is likely to be slightly better.
> However, I don't think it's that very important - as the case of
> modifying signature types is not likely to happen that often (correct me
> if I'm wrong).
> I would vote for this even without a special sequence, that is...
If the efficiency advantages don't depend on removing the indirection from
function_signature<T>::type, then we can consider implementing a native sequence
type as a premature optimization.
>
> Who's doing the megre, then ?
>
>
> I'll be quite busy until the middle of next week and won't get very much
> done before it...
>
I'll be out of town until next friday, so let's suspend this discussion until
then.
Best Regards,
Jonathan