Re: [boost] boost::factory?

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2007-06-18 06:52:26

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