Refactoring of meta::inputparameters (Defect #683)
Currently, the inputparameters are in one big file, which makes this class confusing.
In addition, it does not help users to see all possible parameters when they only need some for a concrete executable.
I moved the options and the parameters themselves to own classes.
The assignment of the single parameters to these classes has to be checked again as some are probably beeter suited for other classes.
Then, the rest of the constructor in inputparameters has to be refactored.
In addition, it might be non-trivial to refactor the conversion from strings to the enum-types as well as the aliases!
Here, the best thing would be to have a vector of ParametersBasic *, and on each one calls the appr. fct. in turn.
However, I dont know how then the parameters of the spec. classes should be member of inputparameters without making two kinds of objects...
- Status changed from New to In Progress
- % Done changed from 0 to 30
Please note that I slightly modified your clases. I forbid copying to prevent slicing and I made sure the options_descriptions are returned by reference. If the are no longer alive if the options are parsed, behaviour is undefined. This showed in the su3vec tests. See 8be25a7cc540f23acf3c3b0ee04a4c8819d659c7 for details.
Thanks for the fix, Matthias. I am glad that the bug showed up, I did not have a problem with that, which was propably luck.
The changes were done prior to the lattice conference, so it might also be that any compiler warning got lost due to that.
However, the "problem" of the structure of the inputparameters is a bit complicated.
As it is now, the inputparameters class selects the parameters appropiate for a given executable, so that a user only sees those.
But the object inputparameters object itself has all available parameters, including getters and setters.
So basically, all functionality is always there, but a part may be hidden from the user.
The problem is that if at some point in the code some parameter is requested, it is a priori not known if this parameter is actually availabe to the user. This may be related to a too high interconnection in the code in general and may cause some problems.
Do you have any idea how to improve this?
- Assignee changed from Christopher Pinke to Matthias Bach