Hi Joel, Joel de Guzman wrote:
Tobias Schwinger wrote:
[1]
For now (C++89) it might be good enough to just have operator() take its arguments by non-const reference. As usually the call will be deferred and as long as the arguments are L-Values they will be deduced even if const qualified (this might break the code of the first use case above - wrapping the factory specialization into a Boost.Bind function object without actually binding anything will work around the problem, though).
[2]
Alternatively we could solve the forwarding problem (within the function object itself) using a "hammer and crowbar utility" in Fusion (overloading operator() with all combinations of templatized const/non-const reference parameters) until we have better means to do so. I personally prefer the former because it's more lightweight and might allow us to be more portable than Fusion is, however.
...and avoids circular dependencies if placed outside of and used by Fusion.
Have [2] for a predefined limit (say 3) and do the rest [1] for more (e.g. 3 or more).
The first two will probably do, since AFAIK both standard and Fusion algorithms will be happy with it. OTOH, once there's a single "L/R-Value overload", users will probably request more of them for manual use (which could be an argument not to add them in the first place).
Isn't that how you did it with the fusion functional stuff?
Well, unintentionally - it was a bug, not a feature :-|. It has recently been fixed (upon Eric Niebler's report) and now there are overloads for all combinations for (default-wise) 6 parameters, now.
Anyway, yeah, I need such a utility, especially if it is lightweight.
Wonderful (what a coincidence)! In fact, the recent discussion of a "fused_ctor" brought it up and the utility also fits nicely into the "Fusion infinity puzzle" (to be continued). It seems misplaced in Fusion, however, because it is generally useful without having anything to do with tuples. Ideally the idea or even the implementation (that is, I'd provide one if there's interest) gets adopted by the utility suite of an existing library (such as Bind) or integrated into an existing set of utilities (e.g. In-Place - which would become Factory then). Otherwise we'd have an "ultra fast track candidate" for boost/utility which would live in Fusion until it finds a better home. Regards, Tobias