From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2007-06-18 06:52:26
Joel de Guzman wrote:
> Tobias Schwinger wrote:
>> 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).
>> 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  for a predefined limit (say 3) and do the rest  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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk