Boost logo

Boost :

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2004-10-12 11:14:33

"Tobias Schwinger" <tschwinger_at_[hidden]> wrote in message
> 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
> > 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
> >
> > "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
> > optimization techniques to write a sequence type that will yield better
> > performance than translating to and from mpl::vector. I hope you or
> > 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...


> 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

Best Regards,

Boost list run by bdawes at, gregod at, cpdaniel at, john at