Allow "type aliases" for explicit instantiations of member function templates
I have a class template that has a non-negligible number of template parameters, which also has an entry method template. As a result I have a lot of explicit instantiations of the form:
extern entry void AlgorithmSingleton< TestMetavariables, typelist<Action1>, tmpl::list<Tags::IntReceiveTag>, int, int, db::DataBox<tmpl::list<>>> receive_data<Tags::IntReceiveTag>(int&, int&, const bool);
Now if I add something to one of the typelists I have to add it to every explicit instantiation in the CI file. You can see how this can get a bit tedious. I'd love to be able to write:
extern entry void MyAliasToSingleton receive_data<Tags::IntReceiveTag>(int&, int&, const bool);
MyAliasToSingleton would be defined using, say the type alias notation:
using MyAliasToSingleton = AlgorithmSingleton< TestMetavariables, typelist<Action1>, tmpl::list<Tags::IntReceiveTag>, int, int, db::DataBox<tmpl::list<>>>;
I'm not yet sure charmc should add the type alias as an actual type alias in, say the
decl.h file, but at least to be able to reduce the amount of typing necessary in the CI files would be nice. It would also reduce the amount of errors that occur because of inconsistent template class types.
Right now if I try the above I get compiler errors about
CkIndex_MyAliasToSingleton that are, understandably, pretty much nonsense.
#1 Updated by Phil Miller almost 2 years ago
- Target version set to 6.9.0
Along the path to prospectively eliminating the need for .ci files and just using straight C++, we're going to try to evolve our code generation so that your
using declaration in a suitably-included header can do what you want it to.
Essentially, the strategy would be to replace generated symbol names like
CkIndex_Foo, CProxy_Foo, and CBase_Foo with templates along the lines of
ck::index<Foo>, ck::proxy<Foo>, ck::base<Foo>, so that the defined alias will be handled correctly by the underlying compiler.
#2 Updated by Nils Deppe almost 2 years ago
Alright, cool. I'm not sure how far along you are with replacing interface files, but I have managed to eliminate them in our code base. The major outstanding thing I haven't done (haven't had time yet) are reduction targets, but I can do entry methods, many with automatic registration, and variadic entry methods. If you're interested then once this code has been thoroughly tested over the next month or two I can explain it. It'll be available on GitHub in our many repo soon.