I almost missed Steven's post. Please post to both lists. Steven Watanabe wrote:
AMDG
Joel de Guzman
writes: Single function:
I'm a strong advocate of smaller is better. Modularity matters. Big classes (or in this case function objects), metaprogram blobs (i.e. traits), humongous enums, and all such sort of dinosours are best avoided. They are convenient up to a certain extent and becomes unmanageable beyond a certain limit.
When it's being managed by humans sure. When the creation of the whatever is automated and it's never used by humans directly it doesn't matter much. The big function object you refer to has a single conceptual responsibility. It isn't a blob any more than a fusion sequence used for the same purpose.
Ok. Good point.
In all of my use cases, I have N functions that are provided elsewhere and I have no control over (e.g. parser functions). I insist that this is the more common use case. Grouping them into a single big struct is an unnecessary and cumbersome step.
It may be more common. What I know for certain is that it's slightly easier to implement my interface in terms of yours than the other way around.
Still, if people insist, I outlined a way to convert the big function object to smaller 'bound' objects, in another post. Just bind 'em into smaller function chunks.
That's true for your use cases. For cases where you have a runtime integer which you need to convert into a compile time integer, which is then used to index into an mpl sequence for instance (as in variant) separate function objects are pointless. I don't want to relegate this usage to the side just because you don't happen to need it. There are enough use cases that it needs to be considered, IMO. Another example is for finite state machines. Also, at one point I was considering a multiple dispatcher that involved a switch.
Yes. I agree. The index is indeed needed. See my latest posts. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net