Having program_options generate a round-trippable config file?

Hi all, I'm using program_options to combine arguments from the command line, the environment, and one or more input files. As you'd expect, it works very well. However, I have an additional requirement that I'm unsure how to implement cleanly atop the library: Given instances of program_options::options_description and program_options::variables_map, I'd like to save a program_options::parse_config_file-friendly file containing the final values obtained. Such a config file could be given back to the program and would identically reproduce the options used. The need is for some scientific software where I want a precise record of what a user has chosen for reasons of scientific repeatability. I see several ways to go about achieving this need, but all of them are ugly, brittle hacks: 1) Accessing the information directly from variables_map seems difficult due to variables_map's use of type erasure and the fact that it does not save the tokens from which values are derived. 2) Obtaining the tokens from the intermediate program_options::parsed_options instances is a possibility but requires me to effectively reimplement the logic contained within program_options::store. It also fails to account for defaulted values. 3) Looping over each program_options::value_semantic found in the options_description instance and adding a notify() callback again runs into type erasure troubles. 4) Adding a notify() to each option_description at its point of declaration avoids type erasure but makes the code impact O(n) where n is the number of options. Has anyone built such a feature atop program_options? Can anyone lend some wisdom? Thanks, Rhys

... I'd like to save a program_options::parse_config_file-friendly file containing the final values obtained. Such a config file could be given back to the program and would identically reproduce the options used.
Hi Rhys, About a year ago, I had a similar need and wrote a crude but useful Settings class with save() and load() methods. I am not saying it is immediately fit for purpose, as it was specifically tailored to my own needs, but perhaps it can serve as inspiration
1) Accessing the information directly from variables_map seems difficult due to variables_map's use of type erasure and the fact that it does not save the tokens from which values are derived.
I seem to recollect that the save() method did exactly this: iterating through the variable_map. I used some string manipulation to split section-names from actual value-names, but that was all. Regards, Andre
participants (2)
-
André Prins
-
Rhys Ulerich