Suggestion: Singleton class database and automatic generation of templated class names

[roma160]

Motivation for using singleton class storage

In the current implementation, every type instantiation of subclasses RuntimeSelectionFactory carries with it a static table with subclasses of the factory. The problem is, if it is planned to continue using templated classes in combination with shared plug-in libraries, then each translation unit that uses the factory would receive and work with its own copy of the table, which could contain data that differs between tables of other translation units. Currently, it is not an issue because there are no tests in the currently used suite that check the usage of classes from shared libraries.

My proposal is to keep only one static table object, which would be defined only on the NeoFOAM library side, and force each plug-in library to store its data in that object. In such a way the data about existing factories subclasses would always be in sync between all translation units.

Motivation for using automatic generation of templated class names

Currently, all subclasses of RuntimeSelectionFactory have to declare the static std::string name() function, which is used as a key in the class table and only contains the name of the class (without the type of the templated parameter. A good example is VolumeBoundaryFactory, which is both used in the code as VolumeBoundaryFactory<double> and VolumeBoundaryFactory<class NeoFOAM::Vector>).

Because a copy of the table is carried with each instantiation of the templated factories and because each factory subclass uses the same templated parameter as its parent, it is not currently an issue. But, if it happens so that the subclass of the factory would need an additional templated parameter or, in the case of using the singleton table approach, there would be no way to distinguish two different instances of the template inside of the table.

My proposal is to use the constexpr class type name approach, described in this StackOverflow answer. As far as I understood, this functionality should be supported by the version of C++ NeoFOAM project is using, and it should also be more or less compiler and system-independent.

At the same time, implementing this suggestion would require pretty extensive rewriting of the existing codebase. So I wanted to know, does it make any sense to do that?

[greole]

Sounds good to me. @HenningScheufler what is your opinion? In any case please go ahead and open a PR for it.