Jonathan Turkanis wrote:
"Tobias Schwinger" <tschwinger@neoscientists.org> wrote in message news:ckg0rf$t0m$1@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