program-options: multi-token for a single value
I'm wondering if program_options supports the notion of two command-line tokens forming a single value, and, if so, how. For example, one of the values I'd like to pass on via the command-line is `a position in lat-lon. For consistency with other programs my users know, I'd like to use something like this: --position 10:11:12:N 13:14:15:W During parsing, I'd like program_options to recognize that --position requires two associated tokens. I tried to use the multitoken() method, but this didn't seem to do what I wanted. The operator>> I wrote for parsing the tokens was still only being passed a single token. Either multitoken doesn't do what I expect, or I'm missing something. Any ideas? Thanks. Austin Bingham
Hi Austin,
I'm wondering if program_options supports the notion of two command-line tokens forming a single value, and, if so, how. For example, one of the values I'd like to pass on via the command-line is `a position in lat-lon. For consistency with other programs my users know, I'd like to use something like this:
--position 10:11:12:N 13:14:15:W
During parsing, I'd like program_options to recognize that --position requires two associated tokens.
I tried to use the multitoken() method, but this didn't seem to do what I wanted. The operator>> I wrote for parsing the tokens was still only being passed a single token. Either multitoken doesn't do what I expect, or I'm missing something. Any ideas? Thanks.
Something strange. What is the type of the 'position' option? Unless it's std::vector of something, I'd expect an exception to be thrown. The solution to your problem is the overload the 'validate' function for your class. Like this: void validate(boost::any& v, const std::vectorstd::string& xs, your_type*, int) You can look at boost/program_options/detail/value_semantic.hpp to learn how to implement this. I intend to document and probably improve the mechanisms really soon now. - Volodya
Something strange. What is the type of the 'position' option? Unless it's std::vector of something, I'd expect an exception to be thrown.
The solution to your problem is the overload the 'validate' function for your class. Like this:
void validate(boost::any& v, const std::vectorstd::string& xs, your_type*, int)
Based on this, I've got a partially working solution. I treat --position as a vector<string> for parsing purposes; later, when I populate the runtime object with the parsed values, I make sure the count() of "position" is 2. While this is a bit problematic, it will work for the most part. Ideally, I would be able to specify that each "--position" token on the command line must be followed by exactly two other tokens. My validate function would then be able to determine if those strings are valid. I'm just waving my hands a bit here, but I don't see any reason why this couldn't be done. Anyhow, like I said, this would be nice but I can get by without it. Austin
Austin Bingham wrote:
The solution to your problem is the overload the 'validate' function for your class. Like this:
void validate(boost::any& v, const std::vectorstd::string& xs, your_type*, int)
Based on this, I've got a partially working solution. I treat --position as a vector<string> for parsing purposes; later, when I populate the runtime object with the parsed values, I make sure the count() of "position" is 2. While this is a bit problematic, it will work for the most part.
Ideally, I would be able to specify that each "--position" token on the command line must be followed by exactly two other tokens. My validate function would then be able to determine if those strings are valid.
I think I'll be able to implement this. OTOH, this will become command-line specific. What if you want to parse --position from config file: position=10:11:12:N 13:14:15:W in this case there are no separate token, the value is considered to be one token. So probably, the best approach is to write your validator so that it operates on a single string, and make program_options merge the tokens. This way, the same validator will work both the command line and config file. - Volodya
I think I'll be able to implement this. OTOH, this will become command-line specific. What if you want to parse --position from config file:
position=10:11:12:N 13:14:15:W
in this case there are no separate token, the value is considered to be one token. So probably, the best approach is to write your validator so that it operates on a single string, and make program_options merge the tokens. This way, the same validator will work both the command line and config file.
That's all sounds great to me. As long as I don't have to force my users to use extra quotes and stuff, I'm willing to do whatever is necessary in my validator. Austin
Austin Bingham wrote:
I think I'll be able to implement this. OTOH, this will become command-line specific. What if you want to parse --position from config file:
position=10:11:12:N 13:14:15:W
in this case there are no separate token, the value is considered to be one token. So probably, the best approach is to write your validator so that it operates on a single string, and make program_options merge the tokens. This way, the same validator will work both the command line and config file.
That's all sounds great to me. As long as I don't have to force my users to use extra quotes and stuff, I'm willing to do whatever is necessary in my validator.
So, syntax like --position="10:11:12:N 13:14:15:W" is not acceptable for you, right? I though about it over weekend and now find this syntax the best one. But anyway I'll think about allowing the syntax you want too. - Volodya
So, syntax like
--position="10:11:12:N 13:14:15:W"
is not acceptable for you, right? I though about it over weekend and now find this syntax the best one. But anyway I'll think about allowing the syntax you want too.
"not acceptable" is perhaps a bit strong ;) If I had my druthers, though, neither the '=' nor the quotes would be necessary. Selfishly, this will help me keep my command lines consistent with older applications. More generally, though, I think it adds flexibility to the library without much extra work or complication. Of course, there are almost certainly issues I'm not taking into account that make my request unworkable. Austin Bingham
participants (2)
-
Austin Bingham -
Vladimir Prus