[Boost.Program_options] String options parser
Hi, We have an executable that uses the program_options library to process command line options like this: $ ./hilbert.x -h -b [ --hilbert ] arg (=1) enable hilbert matrix -e [ --epsilon ] arg (=0.001) roundoff epsilon -h [ --help ] help message -i [ --input-file ] arg process input file -r [ --rank ] arg rank of matrix to construct -t [ --tolerance ] arg (=1e-13) linear tolerance -v [ --inverse ] arg (=0) enable inverse hilbert matrix -w [ --wordsize ] arg (=8) floating-point word size (bytes) and it works great. Now we’re trying to automate some testing and we test our executable with an input file that has hundreds of lines like this: --inverse 1 --tolerance 1e-15 --rank 2 --inverse 1 --tolerance 1e-15 --rank 3 --inverse 1 --tolerance 1e-15 --rank 4 where each line is a separate test case that we run with the specified options. I was looking for a program options parser that can parse a string, so I can read one line of input from this file into a string, and run that test case, that is something like this: // read one line of input from file ifstream ifp; string buffer; while (!ifp.eof() && ifp.good()) { getline(ifp, buffer); // load a set of command line options from this string po::parse_config_file<char>(buffer.c_str(), desc); } The only program option parsers I see are parse_command_line, parse_config_file, and parse_environment. Is there an easy way (without having to construct an argc/argv data structure) to parse a file of program options? — Noel Belcourt
On Jun 13, 2017, at 3:09 PM, Belcourt, Kenneth via Boost-users <boost-users@lists.boost.org<mailto:boost-users@lists.boost.org>> wrote: [ snip …] Now we’re trying to automate some testing and we test our executable with an input file that has hundreds of lines like this: --inverse 1 --tolerance 1e-15 --rank 2 --inverse 1 --tolerance 1e-15 --rank 3 --inverse 1 --tolerance 1e-15 --rank 4 where each line is a separate test case that we run with the specified options. I was looking for a program options parser that can parse a string, so I can read one line of input from this file into a string, and run that test case: [ snip ] The only program option parsers I see are parse_command_line, parse_config_file, and parse_environment. Is there an easy way (without having to construct an argc/argv data structure) to parse a string of program options? Here’s my less than robust solution that converts a line of input into a config file syntax, which I pass into stringstream. char dashes[] = "--"; char dash[] = " -"; string::size_type loc; string buffer; // open file ifstream ifp(s); while (!ifp.eof() && ifp.good()) { // read a line of input getline(ifp, buffer); // replace all occurrences of double-dash with newline loc = buffer.rfind(dashes); while (string::npos != loc) { buffer[loc] = '\n'; buffer[loc+integer::one] = ' '; loc = buffer.rfind(dashes); } // replace all occurrences of space-dash with newline loc = buffer.rfind(dash); while (string::npos != loc) { buffer[loc+integer::one] = '\n'; loc = buffer.rfind(dash); } // check if first option has single dash without leading space if ('-' == buffer[0]) { // remove leading dash buffer.erase(integer::zero, integer::one); } stringstream ss(buffer); po::parse_config_file(ss, desc); } This still requires modifying our input files to use assignment form so this: --inverse 1 --tolerance 1e-15 --rank 2 becomes this: —inverse=1 —tolerance=1e-15 —rank=2 as the equal sign is required for config file syntax. How about a new api to parse command line options from a string? po::store(po::parse_string(buffer, desc), vm); N.
On Tue, Jun 13, 2017 at 5:09 PM, Belcourt, Kenneth via Boost-users <boost-users@lists.boost.org> wrote:
Hi,
We have an executable that uses the program_options library to process command line options like this:
$ ./hilbert.x -h -b [ --hilbert ] arg (=1) enable hilbert matrix -e [ --epsilon ] arg (=0.001) roundoff epsilon -h [ --help ] help message -i [ --input-file ] arg process input file -r [ --rank ] arg rank of matrix to construct -t [ --tolerance ] arg (=1e-13) linear tolerance -v [ --inverse ] arg (=0) enable inverse hilbert matrix -w [ --wordsize ] arg (=8) floating-point word size (bytes)
and it works great. Now we’re trying to automate some testing and we test our executable with an input file that has hundreds of lines like this:
--inverse 1 --tolerance 1e-15 --rank 2 --inverse 1 --tolerance 1e-15 --rank 3 --inverse 1 --tolerance 1e-15 --rank 4
When I've used BPO with input sources, I've used "INI" file format, but I think it may also support other formats like Xml, Json, etc, (?), but I could be wrong about that. Along the lines of this: inverse=1 tolerance=1e-15 rank=2 If you have several different point of entry, that may work, I'm not sure, or feed your subroutines several input sources, depending on how you've implemented your input handlers: inverse=1 tolerance=1e-15 rank=2 inverse=1 tolerance=1e-15 rank=3 inverse=1 tolerance=1e-15 rank=4 HTH
where each line is a separate test case that we run with the specified options. I was looking for a program options parser that can parse a string, so I can read one line of input from this file into a string, and run that test case, that is something like this:
// read one line of input from file ifstream ifp; string buffer; while (!ifp.eof() && ifp.good()) { getline(ifp, buffer); // load a set of command line options from this string po::parse_config_file<char>(buffer.c_str(), desc); }
The only program option parsers I see are parse_command_line, parse_config_file, and parse_environment. Is there an easy way (without having to construct an argc/argv data structure) to parse a file of program options?
— Noel Belcourt
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
On Jun 13, 2017, at 4:23 PM, Michael Powell via Boost-users <boost-users@lists.boost.org> wrote:
On Tue, Jun 13, 2017 at 5:09 PM, Belcourt, Kenneth via Boost-users <boost-users@lists.boost.org> wrote:
Hi,
We have an executable that uses the program_options library to process command line options like this:
$ ./hilbert.x -h -b [ --hilbert ] arg (=1) enable hilbert matrix -e [ --epsilon ] arg (=0.001) roundoff epsilon -h [ --help ] help message -i [ --input-file ] arg process input file -r [ --rank ] arg rank of matrix to construct -t [ --tolerance ] arg (=1e-13) linear tolerance -v [ --inverse ] arg (=0) enable inverse hilbert matrix -w [ --wordsize ] arg (=8) floating-point word size (bytes)
and it works great. Now we’re trying to automate some testing and we test our executable with an input file that has hundreds of lines like this:
--inverse 1 --tolerance 1e-15 --rank 2 --inverse 1 --tolerance 1e-15 --rank 3 --inverse 1 --tolerance 1e-15 --rank 4
When I've used BPO with input sources, I've used "INI" file format, but I think it may also support other formats like Xml, Json, etc, (?), but I could be wrong about that. Along the lines of this:
inverse=1 tolerance=1e-15 rank=2
If you have several different point of entry, that may work, I'm not sure, or feed your subroutines several input sources, depending on how you've implemented your input handlers:
inverse=1 tolerance=1e-15 rank=2 inverse=1 tolerance=1e-15 rank=3 inverse=1 tolerance=1e-15 rank=4
We’re hoping for a cleaner solution but we could certainly make this work. Thanks for the suggestion!
On 14.06.2017 00:23, Michael Powell via Boost-users wrote:
On Tue, Jun 13, 2017 at 5:09 PM, Belcourt, Kenneth via Boost-users <boost-users@lists.boost.org> wrote:
Hi,
We have an executable that uses the program_options library to process command line options like this:
$ ./hilbert.x -h -b [ --hilbert ] arg (=1) enable hilbert matrix -e [ --epsilon ] arg (=0.001) roundoff epsilon -h [ --help ] help message -i [ --input-file ] arg process input file -r [ --rank ] arg rank of matrix to construct -t [ --tolerance ] arg (=1e-13) linear tolerance -v [ --inverse ] arg (=0) enable inverse hilbert matrix -w [ --wordsize ] arg (=8) floating-point word size (bytes)
and it works great. Now we’re trying to automate some testing and we test our executable with an input file that has hundreds of lines like this:
--inverse 1 --tolerance 1e-15 --rank 2 --inverse 1 --tolerance 1e-15 --rank 3 --inverse 1 --tolerance 1e-15 --rank 4 When I've used BPO with input sources, I've used "INI" file format, but I think it may also support other formats like Xml, Json, etc, (?), but I could be wrong about that. Along the lines of this: Boost.PropertyTree could also be useful with INI, Json or XML files.
Cheers, Leon
participants (1)
-
Belcourt, Kenneth -
Leon Mlakar -
Michael Powell