From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2004-10-12 13:39:43
Jonathan Turkanis wrote:
> "Tobias Schwinger" <tschwinger_at_[hidden]> wrote in message
>>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
>>>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
>>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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk