Joel, thanks for this review. Joel de Guzman wrote:
John Torjo wrote:
* What is your evaluation of the design?
simple and effective. I'd like to see more tweakable parameters for specific uses. I frequently deal with different number expansions in a case to case basis. For example, is it possible to have arity 3 for function X and arity-5 for function Y? A single number seems wasteful if I'm sure that a certain use needs only a few. Is that possible?
Yes, I think so. And it turns out to be a very good idea, as it potentially makes overload resolution *a lot* faster. Here comes the benchmark compiling do_the_bind.cpp, ported to use the forward adapter with gcc: Arity=8 preprocess real 0m1.384s user 0m1.270s sys 0m0.109s preprocess, compile, link real 0m12.405s user 0m11.769s sys 0m0.540s Arity=4 preprocess real 0m0.918s user 0m0.454s sys 0m0.081s preprocess, compile, link real 0m1.949s user 0m1.653s sys 0m0.268s Interestingly preprocessing is a minor concern and so we could even provide means to take our pick at compile time (as opposed to preprocessing time).
* What is your evaluation of the implementation?
again, simple and effective.
* What is your evaluation of the documentation?
concise and sufficient for its purpose. I'd like to see more information on result type deduction though. It says: "Boost.ResultOf can be used to determine the result types of specific call expressions.". Ok, but what does that really imply? It would be good to have some information on this and its implications. For instance, for polymorphic function objects, do we have to supply all the nested /result/ metafunction for all overloads?
I see. This question really shouldn't be left unanswered.
How can the forward_adapter template know what to return?
"By applying result_of" - anything beyond that should probably be said within the docs of ResultOf...
I'd like to see an example for a polymorphic function.
...which also might be the more appropriate place for such an example. Slightly slipping off topic, I wonder whether the docs of ResultOf been updated to refer to the current version of the specification (with changed semantics for reference types). We should really get this taken care of before 1.35 goes out. Regards, Tobias