Dave, thanks for your review and the positive vote. David Abrahams wrote:
on Mon Dec 03 2007, John Torjo <john.groups-AT-torjo.com> wrote:
* What is your evaluation of the design?
Looks good to me.
* What is your evaluation of the implementation?
Also looks good, although I don't understand the PP approach being used.
It's quite simple, in fact: Looking at the bits of a counter with loop unrolling applied (not to hit the limits of the PP lib for arities > 8).
It certainly looks different from the very fast one that Paul Mensonides put together for me once (attached at bottom),
Interesting! I never noticed that SEQ_PRODUCT macro actually takes an arbitrary number of factors - pretty cool...
but I'm willing to believe it's better.
Well, I'm not :-). That is, not without at least taking a closer look. Running a quick benchmark shows -to my very surprise- that the performance difference is rather insignificant (at least with GCC/Darwin). Even more surprisingly my code starts outperforming Paul's at max.arity>7. I believe Paul's code can theoretically run a lot faster with a preprocessor that is well-optimized for metaprogramming (not sure there is one around) and it has the "wizardry bonus". Mine OTOH emits at least a few newline characters - which I happen to like :-). Anyway, I will benchmark with some more compilers and eventually change things to use Paul's approach if a significant advantage becomes apparent.
Comments would be helpful.
OK.
It should use compressed_pair to store the wrapped function object to take advantage of EBO.
The class only has a single member, so how would it be applicable? We could just inherit the target function privately to exploit EBCO in cases when inheriting from 'forward<F>'...
* What is your evaluation of the documentation?
Nice, but terse. It would probably be helpful to many to add some more material explaining the forwarding problem.
Are you missing something in particular? BTW: "Virgin guinea pig readers" out there? - Don't hesitate, you're always welcome... Regards, Tobias