Re: [Boost-users] [boost] [program options] Potential bug in parsing arguments where one is suffix of the other ?

Subject: Re: [Boost-users] [boost] [program options] Potential bug in parsing arguments where one is suffix of the other ?
From: Sanjit Jhala (sjhalaz_at_[hidden])
Date: 2011-04-01 15:09:42

Rec'd the following response which shd solve this issue for me:

By default guessing is enabled, in which case you cant have two options with
a common prefix, as it assumes the shorter one is the same as the full one
when the user enters it.

Use the allow_guessing style to avoid, see here:
http://www.boost.org/doc/libs/1_43_0/doc/html/boost/program_options/command_line_style/style_t.html

I did this to avoid it:

// disable guessing of option names
int cmdstyle =
 po::command_line_style::default_style &
 ~po::command_line_style::allow_guessing;

store(po::command_line_parser(ac, av).
 style(cmdstyle).options(cmdline_options).
 positional(p).run(), vm);

-Sanjit
On Thu, Mar 31, 2011 at 4:16 PM, Sanjit Jhala <sjhalaz_at_[hidden]> wrote:

> Hi,
>
> I have the following code (modified from example/first.cpp):
>
> *#include <boost/program_options.hpp>*
> *#include <string>*
> *#include <vector>*
> *#include <iostream>*
> *
> *
> *namespace po = boost::program_options;*
> *
> *
> *using namespace std;*
> *
> *
> *typedef vector<string> Strings;*
> *
> *
> *// A helper function to simplify the main part.*
> *template<class T>*
> *ostream& operator<<(ostream& os, const vector<T>& v)*
> *{*
> *  copy(v.begin(), v.end(), ostream_iterator<T>(cout, " "));*
> *  return os; *
> *}*
> *
> *
> *
> *
> *int main(int argc, char *argv[]) {*
> *
> *
> *  po::options_description cmdline_desc("Usage: %s [Options]
> [args]\nOptions");*
> *  cmdline_desc.add_options()*
> *      ("str", po::value< string >(), "a string arg")*
> *      ("strs", po::value< Strings >(), "a list of strings")*
> *      ("foo", po::value< string >(), "a string arg")*
> *      ("bar", po::value< Strings >(), "a list of strings")*
> *      ;   *
> *
> *
> *  po::variables_map vm; *
> *  po::store(po::parse_command_line(argc, argv, cmdline_desc), vm);*
> *  po::notify(vm);*
> *
> *
> *  if (vm.count("str"))*
> *    cout << "Got str arg=" << vm["str"].as< string >() << "\n";*
> *  if (vm.count("strs"))*
> *    cout << "Got strs arg=" << vm["strs"].as< Strings >() << "\n";*
> *  if (vm.count("foo"))*
> *    cout << "Got foo arg=" << vm["foo"].as< string >() << "\n";*
> *  if (vm.count("bar"))*
> *    cout << "Got bar arg=" << vm["bar"].as< Strings >() << "\n";*
> *}*
> *
> *
> When I run the program I see:
> *./po_test --str "a string" --strs "a, vector, of, strings" --foo "a foo"
> --bar "a, bar"*
> *Got strs arg=a string a, vector, of, strings *
> *Got foo arg=a foo*
> *Got bar arg=a, bar *
>
> It appears the parser is getting confused between the "str" and the "strs".
> It doesn't seem to be related to ambiguity in handling vectors since the
> "foo" and "bar" arguments are fine. I see this problem on 32-bit CentOS and
> Ubuntu machines, but not on 64-bit. I am running Boost 1.43 and from
> the /usr/local/include/boost/program_options/version.hpp:
> #define BOOST_PROGRAM_OPTIONS_VERSION_HPP_VP_2004_04_05
> #define BOOST_PROGRAM_OPTIONS_VERSION 2
>
> Is this a bug or a expected behaviour?
>
> -Sanjit
>
>
>