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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2004-10-12 13:39:43

Jonathan Turkanis wrote:
> "Tobias Schwinger" <tschwinger_at_[hidden]> wrote in message
> news:ckg0rf$t0m$1_at_sea.gmane.org...
> 
>>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.
> 

I would prefer to keep ::type (because of mpl::eval_if, mpl::and, ...).

The advantage would be to get rid of (at least) one specialization 
cascade for the synthesis.
I'm not really sure it's worth maintaining an mpl-sequence 
implementation (although I think it would be more elegant), since I 
don't know if the type synthesis feature will be used that frequently. 
Could you name a few typical appications ?

While talking about appications: I think I did not give an example for 
the usefulness of volatility support, yet:
Let's (again) consider using this for an eventing system with a 
metaprogrammed facility to ease the registration of handler methods.
If it runs in a multithreaded context 'volatile' would come handy to tag 
that a function needs to be synchonized (it would even suit 
semantically, somehow).
Put abstract it's yet another flag for (nearly) free.

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

OK.

Greetings,

Tobias