12

Very simple example:



#include <string>
#include <boost/program_options.hpp>

namespace po = boost::program_options;

int main(int argc, char* argv[])
{
    po::options_description recipients("Recipient(s)");
    recipients.add_options()
        ("csv",         po::value<std::string>(),     ""  )
        ("csv_name",    po::value<unsigned>(),        ""  )
    ;

    po::options_description cmdline_options;
    cmdline_options.add(recipients);

    po::variables_map vm;
    po::store(po::command_line_parser(argc, argv).options(cmdline_options).run(), vm);
    po::notify(vm);

    return 0;
}

And some tests:


>Test --csv test
in option 'csv_name': invalid option value

>Test --csv_name test
in option 'csv_name': invalid option value

>Test --csv_name 0

>Test --csv text
in option 'csv_name': invalid option value

>Test --csv 0

>Test --csv_name 0

>Test --csv_name 0 --csv text
multiple occurrences

Looks like that boost::program_option threats parameter "csv" as "csv_name".
Is it a feature or bug?

Dmitriy
  • 3,305
  • 7
  • 44
  • 55

2 Answers2

9

Yes, this is a "feature" due to default options parsing style. Try with short options, like:

recipients.add_options()
    ("csv,c",      po::value<std::string>(), ""  )
    ("csv_name,C", po::value<unsigned>(),    ""  )
;

Or play with the basic_command_line_parser::style(int) method. I haven't tried this, so YMMV.

Nikolai Fetissov
  • 82,306
  • 11
  • 110
  • 171
  • 4
    I are right. parser.style(po::command_line_style::default_style ^ po::command_line_style::allow_guessing); helps me. Thanks. – Dmitriy Apr 07 '10 at 03:33
5

I am afraid this is a bug. But, it should be fixed in 1.42 -- which version did you try with?

Vladimir Prus
  • 4,600
  • 22
  • 31
  • 1
    I'm using Version 1.42.0. As I already said parser.style(po::command_line_style::default_style ^ po::command_line_style::allow_guessing); helps me. – Dmitriy Apr 08 '10 at 03:18
  • Hi Vladimir. Nice to see the author answering for the library :) What do you think the bug is/was - the default parsing style? – Nikolai Fetissov Apr 09 '10 at 03:34
  • 1
    No, the default style is fine. However, if you have two options, one named "csv" and another named "csv_name", and the command line has "--csv", then it's reasonable to prefer full match to an approximate match. I believe the fix is this: https://svn.boost.org/trac/boost/changeset/59744 – Vladimir Prus Apr 10 '10 at 08:34
  • Hi Vladimir. Boost 1.43 released, but looks like the bugfix doesn't included. Could you confirm that the bug is not fixed in boost 1.43, please? – Dmitriy May 13 '10 at 05:46
  • Unfortunately, it seems like I have failed to merge this fix to the trunk -- so you get to apply it manually from the changeset link I gave above. I am really sorry! – Vladimir Prus May 14 '10 at 06:43
  • Not really related to this post: I wonder whether you still support/update `boost::program_options`. The docu appears 10 years old and I recently got loads of warning messages when compiling with `clang 3.4 -std=c++11`. The most worrying of those was and uninitialized bool in some boost lexer ... – Walter Mar 28 '14 at 09:55
  • According to https://github.com/boostorg/program_options/tree/develop/doc the last doc update is just 3 years old. – Vladimir Prus Mar 28 '14 at 13:46
  • On your general question, I don't have a lot of time for program_options, but there are no any big plans for it either - it does serve quite specific purpose and that's it. Patches to fix warnings can be of course applied, though your comment suggests that the warning may be in other code. – Vladimir Prus Mar 28 '14 at 13:49