Re: [boost] Generic type inferencer function?

Le 27/12/2015 02:54, Paul Fultz II a écrit :

On Friday, December 18, 2015 at 11:20:54 AM UTC-5, Nat Goodspeed wrote:

...

Our code has any number of instances of this pattern:

template class SomeTemplate { SomeTemplate(const T& t, const U& u); ... };

template SomeTemplate make_SomeTemplate(const T& t, const U& u) { return SomeTemplate(t, u); }

Am I overlooking a generic boost::make<something>() of this general form?

This can easily be built using the `fit::construct` function from the Fit library.

Plus, `by` can be used to apply prohejection to handle the different type of deductions necessary. Here's how to build `make` that decays each parameter:

FIT_STATIC_FUNCTION(make_tuple) = fit::constructstd::tuple().by(fit::decay);

We can use `fit::decay` which will decay and unwrap references. For `tie`, we can do our own projection `lvalue`, which really does nothing except ensures that lvalues are passed to the function:

struct lvalue { template<class T> constexpr T& operator()(T& x) const { return x; } }; FIT_STATIC_FUNCTION(tie) = fit::constructstd::tuple().by(lvalue());

The `forward_as_tuple` can also be written always deducing a reference:

struct reference { template<class T> constexpr T&& operator()(T&& x) const { return std::forward<T>(x); } }; FIT_STATIC_FUNCTION(forward_as_tuple) = fit::constructstd::tuple().by(reference()); I don't know what the other think of having several ways to deduce the

There are some some specificities my make<> function has: * The template parameter can be a template class, a type constructor or a class * The function is customizable Can fit::construct<> be used like make<>? parameters.

Of course, this can be used to create a generic factory. The problem with a generic factory is some classes might want different ways of deducing the parameters(perhaps the class doesn't allow for references at all). There could be some metaprogramming done to notify the generic factory, however, it might be easier just to write a custom factory(its only one line of code). So it might be better for the generic factory to have a customization point instead.

Also, the three different factories provided by tuple seem to be a bad choice for the more general construction. It would be better to have three factory type functions like this:

make - deduces lvalues as lvalues and rvalues as rvalues(ie it contains no rvalue references) make_forward - Everything is deduced as reference(like `forward_as_tuple`) make_decay - decay the parameters and unwrap references(like `make_tuple` and `make_pair`)

Of course, this changes what people generally view `make` as. Perhaps a different name could be used other than `make`.

I people needs to make the difference I would prefer to have make: decay the parameters and unwrap references(like `make_tuple` and `make_pair`) forward_as: Everything is deduced as reference(like `forward_as_tuple`) .... Vicente