[boost] Re: as_sequence<R(T0,T1)> ?

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

"Tobias Schwinger" <tschwinger_at_[hidden]> wrote:
> Jonathan Turkanis wrote:

> >>>It's not really meant to compete with your proposal -- I wrote it for a
>
> Why not ?! If it's undoubtfully better it should be used instead.
> I don't think it is that _clearly_ better, yet. Although it has some
> advantages...

I just meant that it wasn't intended to supplant your proposal. I'm happy to
work together with you, or to let you steal anything you like from my code ;-)

> Feel free to read / use / change or just deprecate my code in order to
> take it there ;+).

Thanks. I'm feeling freer already.

> First of all: _very_ nice documentation (by the way: you do not manually
> code the syntax highlighting, do you ? ;+).

I have keyboard shortcuts for the various categories.

> Looking at the implementation I think there is a lot of redundancy.
> There is one cascade for references, one for pointers, one for function
> (non ref/ptr) types and the same for synthesizing once again.

Right. For some reason it didn't occur to me to use add/remove
pointer/reference, as you mention below. I wrote the implementation fast, and
it's so easy to copy and paste ;-)

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

>
> The JTFT introduce a new cascade of code for each kind of "signature
> type" (used in the following text as defined in the JTFT docs). The TSFT
> use one common backend for everything. The TSFT do not address function
> types and function references. The idea behind it was: using add_pointer
> / remove_reference may be better.
> The TSFT common backend comes with a price, too: It depends on
> mpl::vector up to BOOST_TT_FUNCTION_MAX_ARITY to be included.
> However, I think the backend part of TSFT is more simple and better.

I think you're clearly correct about only providing specializations for one of
the three type/pointer/reference family. Otherwise, superficial differences
asside, our implementations are very similar. The one key difference is that you
use overload resolution and sizeof to implement the boolean metafunctions. Since
this information is already available in decompose, I'm not sure why you do
this. Is it for efficiency?

> Further suggestions:
> --------------------
>
> 1. Merge the best of both of our approaches
> 1.1. Implement the classification/decomposition interface of JTFT with
> the TSFT (or similar) backend.

Sounds good to me.

> 1.1.1. The TSFT needs to be adjusted slightly to simplify the more fine
> grained separation of result,args and class.
> 1.2. use the native TT macros to publish the traits classes

Good.

> 1.3. handle volatility

Also good. I'm interested to know, though, whether this is simply a matter of
being comprehensive -- which is fine with me -- or whether you think there are
important use cases.

> 2. Strip out the synthesis part and replace it with an mpl-sequence
> implemenation backed with (all) signature types.
>
> 3. Use this instead of mpl::vector in all cases.
>
> 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?

?

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

> One last note:
> --------------
>
> The imperative used in the previous section is not meant as harsh as it
> may sound.
> So the section should be read as my todo list for the project: "combine
> the best parts of JTFT and TSFT into FT".

You don't have to worry about offending my sensibilities. I'm unflappable. ;-)

> Best regards,
>
>
> Tobias

Jonathan