Template argument inference by constructor arguments - c++

Question

It is possible to "peel" function argument type using:
void foo_double(double a)
{
}
void foo_int(int a)
{
}
template <class R, class A0>
void bar(R (*fp)(A0))
{
// Do something related with A0
}
int main()
{
bar(foo_double); // A0 is double
bar(foo_int); // A0 is int
}
Is it possible to do the same "argument type peeling" to a class constructor function?
Edit:
I believe I didn't explain myself clearly in the original code snippet. Here is the complete scenario.
I have multiple classes C1,...,Cn which I need to expose to python as functions. Lets assume all classes have a common void Run() method. However, the constructors of these classes accept different arguments. To expose functions to python I use boost.python which automatically exports function to an appropriate python function while handling all type conversions (mostly primitives).
My first solution was:
class C1
{
public:
C1() {}
void Run();
};
class C2
{
public:
C2(double a) {}
void Run();
};
template <class T>
void python_wrapper()
{
T instance();
instance.Run();
}
template <class T, class A0>
void python_wrapper(A0 a0)
{
T instance(a0);
instance.Run();
}
BOOST_PYTHON_MODULE(_pythonmodule)
{
// This is boost.python stuff
python::def("f1", python_wrapper<C1>);
python::def("f2", python_wrapper<C2, double>);
}
And... It works.
What I am trying to accomplish now is to use python_wrapper<C2> instead of python_wrapper<C2, double> while inferring the constructor argument types.
As I showed in the original post. I could accomplish something similar if I was wrapping functions instead of classes.

Answer 1

There is no way of deducing a type's constructor's arguments.
C++98/03 and C++11 specifications explicitly list the context in which type deduction may occur (refer to § 14.8.2 and its subsections). Deduction is a qualify of life enhancement for template programming, and not mandatory. Anything that can be done through deduction can also be achieved through explicit calls. Thus, in order for deduction to be possible, it would require that one could explicitly provide a constructor to a function template.
However, this is impossible. As noted in § 12.1 of C++98/03 and C++11 specifications, constructors do not have names. Additionally, § 12.1.12 of C++98/03 and § 12.1.10 of C++11 state that the address of a constructor shall not be taken. Thus, there is no way to provide an identifier; therefore, deduction cannot occur.
With deduction being impossible, it may be worth considering alternative solutions. Each solution will have its own sets of pros and cons, but all of them will require that the argument types be explicitly listed in some context outside of the constructor:
Provide the constructor's argument types to a function template.
Pros:
Fairly simple.
Cons:
The association between the type and the type's constructor's argument types is not very visible.
The association is not reusable. For example, the association would need to be duplicated if passing it to multiple function templates or class templates.
Required for every type that has a constructor with an arity of 1 or greater.
Maintain the association with a type trait.
Pros:
Reusable.
The association between the type and the type's constructor's argument types is more visible.
Not overly complicated.
Cons:
Coding is slightly more complex than providing the association directly to a function template.
Required for every type that has a constructor with an arity of 1 or greater.
Create a factory function for each type.
Pros:
Very simple.
Reusable.
The association between the type and the type's constructor's argument types is very visible.
Cons:
Required for every type, even if the arity is 0. This could be mitigated with an invasive factory functions, as there will be no ambiguities due to scope. For a non-invasive factory functions, there may be collisions on signatures, so the function names must be unique.
Heavy use of meta-programming to have a vector of constructor argument types. Template code would then iterate over the growing list trying to identify a workable match.
Pros:
If types have similar constructors, then a single entry in the vector may serve as a workable match for multiple types.
Cons:
Much more complex.
May require modifying compiler arguments to support template depth.
Given the situation described for your environment:
There are many classes.
Some already exists and shouldn't be changed.
More of these are written on a daily basis.
The constructors are unique.
When factored with the C++ specification, I believe we have defined a Kobayashi Maru. You will have to weight out the pros and cons to determine what approach can be adapted for your environment. The simplest approach may already be the one you have in place, as it only requires a single location for code to change as more types are created.
Nevertheless, here is an approach using a type trait that provides information about a type's constructor in a noninvasive manner. Without C++11 capabilities, such as variadic templates, there is a bit of boilerplate code. Additionally, the implementation may not cover all cases, such as multiple constructors.
Using the classes presented in the original question:
class C1
{
public:
C1();
void Run();
};
class C2
{
public:
C2(double a);
void Run();
};
A template that represents constructor's traits will be used. I am using a type-list provided by Boost.MPL to represent a constructor's argument types. The default constructor_traits indicates no arguments are required.
/// #brief constructor_traits is a type_trait that is used to noninvasively
/// associated T with constructor meta information, such as T'
/// constructor's argument types.
///
/// For example, if Foo has a constructor that accepts a single
/// integer, then constructor_traits<Foo>::type should be
/// boost::mpl::vector<int>.
template <typename T>
struct constructor_traits
{
typedef boost::mpl::vector<> type;
};
This trait is then specialized for types with constructors that accept arguments, such as C2.
/// Specialize constructor_traits for C2 to indicate that its constructor
/// accepts a double.
template <>
struct constructor_traits<C2>
{
typedef boost::mpl::vector<double> type;
};
The boost::mpl::vector is a list of types that represents the constructor's arguments. It provides random access via boost::mpl::at. To provide a slightly cleaner access to elements, a helper type is introduced:
/// #brief Helper type that makes getting the constructor argument slightly
/// easier.
template <typename Vector,
std::size_t Index>
struct get_constructor_arg
: boost::mpl::at<Vector, boost::mpl::int_<Index> >
{};
When exposing the functions to Boost.Python, the desired syntax is to only provide a single type. Either function templates or class templates can be used to solve this problem. I have decided to use class templates, as it reduces some of the boilerplate code.
/// #brief runner type is used to provide a static run function that
/// will delegate the construction and running of type T based
/// on T's constructor_traits.
template <typename T,
typename Args = typename constructor_traits<T>::type,
std::size_t = boost::mpl::size<Args>::value>
struct runner
{
static void run()
{
T().Run();
}
};
This template is then specialized for the amount of arguments the constructor accepts. The following is specialized to accept one argument. This is determined by the 1 in the template argument list of the specialization.
/// Specialization for runner for types with have a single argument
/// constructor.
template <typename T,
typename Args>
struct runner<T, Args, 1>
{
static void run(typename get_constructor_arg<Args, 0>::type a0)
{
T(a0).Run();
}
};
Function templates could also be used to solve this problem. I decided to use class templates because:
No need for SFINAE. Would need to use enable_if constructs to select the correct template.
Being able to provide default template arguments with a class template prevents the need to obtain the constructor_trait multiple times.
The resulting Boost.Python calls would look like:
BOOST_PYTHON_MODULE(_pythonmodule)
{
boost::python::def("f1", &runner<C1>::run);
boost::python::def("f2", &runner<C2>::run);
}
Here is the complete code:
#include <iostream>
#include <boost/mpl/vector.hpp>
#include <boost/python.hpp>
class C1
{
public:
C1() {}
void Run() { std::cout << "run c1" << std::endl; }
};
class C2
{
public:
C2(double a) : a_(a) {}
void Run() { std::cout << "run c2: " << a_ << std::endl;}
private:
double a_;
};
/// #brief constructor_traits is a type_trait that is used to noninvasively
/// associated T with constructor meta information, such as T'
/// constructor's argument types.
///
/// For example, if Foo has a constructor that accepts a single
/// integer, then constructor_traits<Foo>::type should be
/// boost::mpl::vector<int>.
template <typename T>
struct constructor_traits
{
typedef boost::mpl::vector<> type;
};
/// Specialize constructor_traits for C2 to indicate that its constructor
/// accepts a double.
template <>
struct constructor_traits<C2>
{
typedef boost::mpl::vector<double> type;
};
/// #brief Helper type that makes getting the constructor argument slightly
/// easier.
template <typename Vector,
std::size_t Index>
struct get_constructor_arg
: boost::mpl::at<Vector, boost::mpl::int_<Index> >
{};
/// #brief runner type is used to provide a static run function that
/// will delegate the construction and running of type T based
/// on T's constructor_traits.
template <typename T,
typename Args = typename constructor_traits<T>::type,
std::size_t = boost::mpl::size<Args>::value>
struct runner
{
static void run()
{
T().Run();
}
};
/// Specialization for runner for types with have a single argument
/// constructor.
template <typename T,
typename Args>
struct runner<T, Args, 1>
{
static void run(typename get_constructor_arg<Args, 0>::type a0)
{
T(a0).Run();
}
};
BOOST_PYTHON_MODULE(example)
{
boost::python::def("f1", &runner<C1>::run);
boost::python::def("f2", &runner<C2>::run);
}
And the test output:
>>> import example
>>> example.f1()
run c1
>>> example.f2(3.14)
run c2: 3.14

Answer 2

You cannot take the address of a constructor (C++98 Standard 12.1/12 Constructors - "12.1-12 Constructors - "The address of a constructor shall not be taken.")
If all classes share a base class then you could make a factory, but without C++11 variadic templates I don't know of a way to do the argument forwarding.
template <typename type>
static type* construct(){
return new type();
}
auto value = &construct<int>;
You now have a bindable function that when called, produces an type*
auto value = &construct<int>;
int* newInt = (*value)();
delete newInt;
To allow for varying constructors inputs, this uses C++11
template <typename type>
class constructor {
public:
template<typename ...Args>
static std::shared_ptr<type> alloc(Args&& ...args){
return std::shared_ptr<type>(new type(std::forward<Args>(args)...));
}
// placement new
template<typename ...Args>
static std::shared_ptr<type> realloc( std::shared_ptr<type>& object,Args&& ...args){
(new (&(*object)) type(std::forward<Args>(args)...));
return object;
}
};
class fooBar{
public:
fooBar(int x,float f){
}
};
typedef std::shared_ptr<fooBar> fooBarPtr;
Usage:
fooBarPtr a = constructor<fooBar>::alloc(5,0.0f);
Or this might be closer to what the op wants.
class fooy{
int _x = 0;
public:
fooy(int argCount, va_list& list){
if( argCount > 0){
_x = va_arg(list, int);
}
}
};
template <typename type>
std::shared_ptr<type> alloc(int argCount,...) {
va_list list;
va_start(list, argCount);
auto result = std::shared_ptr<type>( new type(argCount,list) );
va_end(list);
return result;
}
Usage:
auto foo1 = alloc<fooy>(0); // passing zero args
auto foo2 = alloc<fooy>(1,1234); // passing one arg

Answer 3

Since you don't want to change the existing classes, there's no way to automate the deduction for those classes within C++. You can do it outside C++ for those classes by extracting the signature information from the source code. This extraction can be done manually or automated by a script or even by a C++ program.
For each existing class E, use the extracted information to define a specialization of a class template that defines a static member function func that passes its argument(s), if any, to constructor of class E and invokes the Run method.
For new classes, simply require them to define func, and let the class template default to using the existing func.
Then the general Python wrapper definition code can infer arguments for func, which you have shown you know how to do.
This means the folks who define the classes just need to start adding func for new such classes.
At a slightly higher level, I think it would be worth using some time on involving the relevant people and finding out how an ungood design could be adopted and entrenched by having a zillion classes defined. With the goal of preventing that from happening again in the future. How to deal with that would depend, I think, on how it happened.

Answer 4

I'm not sure how this will interact with python::def, but in general this is what variadic templates are for:
struct C1{
C1(){}
void run(){}
};
struct C2{
C2(int){}
void run(){}
};
template<typename CLASS, typename... PARAMS>
void call(PARAMS... params) {
CLASS inst(params...);
inst.run();
}
main() {
call<C1>();
call<C2>(42);
}
It's c++11, but supported in gcc since version 4.3