boostorg / program_options Goto Github PK

Boost.org program_options module

Home Page: http://boost.org/libs/program_options

C++ 96.70% HTML 0.14% Python 0.54% Shell 1.15% Batchfile 0.46% CMake 1.02%

program_options's Introduction

Program Options, part of the collection of Boost C++ Libraries, allows for definition and acquisition of (name, value) pairs from the user via conventional methods such as command line and config file. It is roughly analogous to getopt_long, but for use with C++.

License

Distributed under the Boost Software License, Version 1.0.

Properties

C++03
Requires Linking

Build Status

(in progress...)

Branch	Travis	Appveyor	codecov.io	Deps	Docs	Tests
`master`
`develop`

Directories

Name	Purpose
`build`	build script for link library
`ci`	continuous integration scripts
`doc`	documentation
`example`	use case examples
`include`	headers
`src`	source code for link library
`test`	unit tests

More information

Ask questions: Be sure to read the documentation first to see if it answers your question.
Report bugs: Be sure to mention Boost version, platform and compiler you're using. A small compilable code sample to reproduce the problem is always good as well.
Submit Pull Requests against the develop branch. Note that by submitting patches you agree to license your modifications under the Boost Software License, Version 1.0. Be sure to include tests proving your changes work properly.
Discussions about the library are held on the Boost developers mailing list. Be sure to read the discussion policy before posting and add the [program_options] tag at the beginning of the subject line.

program_options's People

Contributors

Stargazers

Watchers

Forkers

rpetrich danielae sanderbog chfast marcelraad danieljames d3rhans jurko-gospodnetic mjdecker mikemitterer tempoz timblechmann lanurmi gevorgvoskanyan fsun2p10 sarthak0415 limbolily jonaskunze ya1gaurav mauve ecatmur crossbuild idupree chardan teeks99 autodesk-forks xltools jameslinus stammen njlr blaecwen dexata jojoatxgme toonetown sjoubert bazelboost myestro mikegitb jeking3 emreturkay jbrzusto devindusoft tlanc007 b-spencer yoann01 sefi-roee mike-devel atulkumarpccs kojoley nomis madebr buckaroo-pm landberg liutongxuan dwielosz scramsby moreheadm mosjin jinhang2008 matwey zhaohui0923 aboualiaa lihui7115 lastique allenbh eugenezelenko f3rm4rf3r xloem sgoru zap150 xtrememapping samd2 sdarwin nirvananimbusa watayut opensourceeda fieryswampshire longgang camerbam jonesmz externpro nblei venturecurrency eedy ekra-ltd jingliang2005 brian8181 isabella232 apolukhin msft-vivi olologin matthew-rigoroustech gtton sunflowerbloom ka-de creaform-r-d seanpm2001 superlokkus georgthegreat sam-caldwell

program_options's Issues

linking with program_options has unresolved symbols on MSVC

I'm developing a simple command line client application against boost::program_options. Everything works fine on Linux with gcc-4.8, gcc-5.3 and gcc-6.3, on Darwin with XCode 7 and on Windows with MinGW-w64. But on Windows with MSVC Build Tools x64 from 2015 and 2017 I get two unresolved symbols:

LightBISClientCMDLine.cc.obj : error LNK2001: unresolved external symbol "class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > boost::program_options::arg" (?arg@program_options@boost@@3V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@A)
LightBISClientCMDLine.cc.obj : error LNK2001: unresolved external symbol "public: static unsigned int const boost::program_options::options_description::m_default_line_length" (?m_default_line_length@options_description@program_options@boost@@2IB)

I checked program_options.dll and I am under the impression that those two symbols are defined there. I get exact matches for ?arg@program_options@boost@@3V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@A and ?m_default_line_length@options_description@program_options@boost@@2ib.` Also all other symbols from program_options are resolved correctly. Here is the details build log with a verbose linker message: http://data.biodataanalysis.de/tmp/boost_program_options_linker_error_emmenlau.txt

I checked the build log to see that the library was built with -DBOOST_PROGRAM_OPTIONS_DYN_LINK=1.

As far as I could see, it's not supported to export STL classes like std::string from a DLL with Visual Studio 2015 and 2017 because it seems considered bad practice. There are various reports that indicate that exporting STL classes can cause issues when mixing different runtimes or compiler versions. Is it possible that Microsoft just disabled that option alltogether?

I found related reports here:

Here is an example that shows the error. The build is configured with cmake: https://github.com/emmenlau/BDAMinimalTestCase

Program options default has unreasonable precision

Source code:

  time_t now,then;
  double tolerance,stageTolerance,areadone,rmsadj;
  bool done=false;
  string inputFile,outputFile;
  bool validArgs,validCmd=true;
  po::options_description generic("Options");
  po::options_description hidden("Hidden options");
  po::options_description cmdline_options;
  po::positional_options_description p;
  po::variables_map vm;
  generic.add_options()
    ("tolerance,t",po::value<double>(&tolerance)->default_value(0.1),"Vertical tolerance")
    ("output,o",po::value<string>(&outputFile),"Output file");
  hidden.add_options()
    ("input",po::value<string>(&inputFile),"Input file");
  p.add("input",1);
  cmdline_options.add(generic).add(hidden);
//...
      cout<<generic;

Output:

  -t [ --tolerance ] arg (=0.10000000000000001)
                                        Vertical tolerance
  -o [ --output ] arg                   Output file

Output should be:

  -t [ --tolerance ] arg (=0.1)         Vertical tolerance
  -o [ --output ] arg                   Output file

I've tried this on Boost 1.65.1 on Ubuntu Beaver, and Boost 1.69.0 on DragonFly BSD 5.5, and got the same result.

For an idea on how to fix it, see ldecimal.cpp in https://github.com/phma/bezitopo, but that would output ".1", not "0.1".

[Regression 1.69.0] Clang UBSan triggers when std::string is used in notify()

We found that clang UBSan shows undefined behaviour when we use an option of type std::string with po::notify(). Please see https://stackoverflow.com/q/55064334/2375725 for more details and a minimal working example.
My colleague has already bisected the issue in this comment and it seems to be related to activating -fvisibility-inlines-hidden and -fvisibility=hidden.
Unfortunately we have no idea where to go from here...

We will also open a ticket at clang as we are really not sure whether this is a false positive in clang UBSan or actual undefined behaviour.

UBSAN errors identified

I ran a build of develop through UBSAN and a number of tests failed; this needs to be investigated and resolved.

https://travis-ci.org/jeking3/program_options/jobs/350280182

Support initializer_list

To do something like this:

argagg::parser argparser {{
    { "help", {"-h", "--help"},
      "shows this help message", 0},
    { "delim", {"-d", "--delim"},
      "delimiter (default: ,)", 1},
    { "num", {"-n", "--num"},
      "number", 1},
  }};

Documentation typo

program_options/example/real.cpp

Line 26 in d95d316

/* Function used to check that of 'for_what' is specified, then

Should be 'if'not 'of'.

Cannot use shared library in C++98

After boostorg/function#25 building a C++ < 11 consumer fails. Affects at least gearmand, pdfedit, uhd. CC @Kojoley

$ cat >a.cc
#include <boost/program_options.hpp>

int main(int argc, char **argv) {
  boost::program_options::options_description desc("foo");
  boost::program_options::parse_command_line(argc, argv, desc);
  return 0;
}

$ c++ -std=gnu++98 a.cc -lboost_program_options
>>> referenced by a.cc
>>>               /tmp/a-fa8c69.o:(boost::program_options::basic_command_line_parser<char>::extra_parser(boost::function1<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&>))
c++: error: linker command failed with exit code 1 (use -v to see invocation)

build error with boost 1.68

When building boost 1.68, I have an error when building program_options where it cannot copy the program_options-mt.lib file.

It seems the .lib file is not created since nothing is exported when not using BOOST_ALL_DYN_LIB.

Taking example on boost.timer, I modified the Jamfile.v2 file to look like this

boost-lib program_options
    : $(SOURCES).cpp
    : # See https://svn.boost.org/trac/boost/ticket/5049
      <target-os>hpux,<toolset>gcc:<define>_INCLUDE_STDC__SOURCE_199901
      <link>shared:<define>BOOST_PROGRAM_OPTIONS_DYN_LINK=1
      <link>static:<define>BOOST_PROGRAM_OPTIONS_STATIC_LINK=1
    ;

and it seems to fix my issue.

The parsing error of the multitoken argument with negative numbers

The parsing error of the multitoken argument with negative numbers occurs while setting negative numbers after the first number.

For example, if we set an option

("point,p", po::value<std::vector<float>>(&options.point)->multitoken(), "The point")

and enter in the command line the following values

prog -p -1 2 3

It works correctly.
However, if we enter the values given bellow

prog -p -1 -2 3

the parsing error occurs

unrecognised option '-2'

This error exists in Boost 1.65.1 as well.

Reverting change for implicit_option that happened in boost 1.59

Dear Vladimir Prus. This is a follow up to your comment in (http://stackoverflow.com/questions/31921200/how-to-have-an-optional-option-value-in-boost-program-options)

implicit_option changed its behaviour in boost 1.59 so that --option_name option_value no longer works and needs to be written as --option_name=option_value. I would find it useful if the original behavior was restored and both formats worked (and the documentation changed to reflect this). Thank you.

[Feature] Allow Unknown Options from all sources

For the command line parser, there is the allow_unregistered() method to not throw an exception whenever an option is not recognized.

However, this is missing from the configuration file and environment parsers.

It is possible to do work around this for both configuration files and environment, but I am of the opinion this should be handled in similar fashion to the command line parsers!

Feature Request: Provide conflicting_options and option_dependency

Why don't you provide conflicting_options and option_dependency shown in example/real.cpp?
It is useful.

If provided, It is desirable that conflicting_options is variadic.

Feature Request: Make options_description output optionally machine readable (ie --helpjson) to support auto-completion of process arguments in system shells

This is a dupe of a feature request I filed for Qt's QCommandLineParser, so I'll just link to that instead of copy/pasting the description here: https://bugreports.qt.io/browse/QTBUG-74594

GCC suggest-override warnings

Complete list of warnings when Boost 1.72 is built with GCC 7.5 with -Wsuggest-override added to cxxflags:

./boost/program_options/detail/config_file.hpp:167:5: warning: ‘bool boost::program_options::detail::basic_config_file_iterator::getline(std::__cxx11::string&) [with charT = char; std::__cxx11::string = std::__cxx11::basic_string]’ can be marked override [-Wsuggest-override]
./boost/program_options/detail/config_file.hpp:167:5: warning: ‘bool boost::program_options::detail::basic_config_file_iterator::getline(std::__cxx11::string&) [with charT = wchar_t; std::__cxx11::string = std::__cxx11::basic_string]’ can be marked override [-Wsuggest-override]
./boost/program_options/detail/value_semantic.hpp:174:5: warning: ‘void boost::program_options::typed_value::xparse(boost::any&, const std::vector >&) const [with T = bool; charT = char]’ can be marked override [-Wsuggest-override]
./boost/program_options/detail/value_semantic.hpp:20:5: warning: ‘std::__cxx11::string boost::program_options::typed_value::name() const [with T = bool; charT = char; std::__cxx11::string = std::__cxx11::basic_string]’ can be marked override [-Wsuggest-override]
./boost/program_options/detail/value_semantic.hpp:38:5: warning: ‘void boost::program_options::typed_value::notify(const boost::any&) const [with T = bool; charT = char]’ can be marked override [-Wsuggest-override]
./boost/program_options/errors.hpp:186:29: warning: ‘virtual const char* boost::program_options::error_with_option_name::what() const’ can be marked override [-Wsuggest-override]
./boost/program_options/errors.hpp:259:22: warning: ‘virtual void boost::program_options::error_with_no_option_name::set_option_name(const string&)’ can be marked override [-Wsuggest-override]
./boost/program_options/errors.hpp:292:22: warning: ‘virtual void boost::program_options::ambiguous_option::substitute_placeholders(const string&) const’ can be marked override [-Wsuggest-override]
./boost/program_options/errors.hpp:346:29: warning: ‘virtual std::__cxx11::string boost::program_options::invalid_config_file_syntax::tokens() const’ can be marked override [-Wsuggest-override]
./boost/program_options/value_semantic.hpp:113:14: warning: ‘virtual void boost::program_options::value_semantic_codecvt_helper::parse(boost::any&, const std::vector >&, bool) const’ can be marked override [-Wsuggest-override]
./boost/program_options/value_semantic.hpp:133:21: warning: ‘virtual std::__cxx11::string boost::program_options::untyped_value::name() const’ can be marked override [-Wsuggest-override]
./boost/program_options/value_semantic.hpp:135:18: warning: ‘virtual unsigned int boost::program_options::untyped_value::min_tokens() const’ can be marked override [-Wsuggest-override]
./boost/program_options/value_semantic.hpp:136:18: warning: ‘virtual unsigned int boost::program_options::untyped_value::max_tokens() const’ can be marked override [-Wsuggest-override]
./boost/program_options/value_semantic.hpp:138:14: warning: ‘virtual bool boost::program_options::untyped_value::is_composing() const’ can be marked override [-Wsuggest-override]
./boost/program_options/value_semantic.hpp:140:14: warning: ‘virtual bool boost::program_options::untyped_value::is_required() const’ can be marked override [-Wsuggest-override]
./boost/program_options/value_semantic.hpp:147:14: warning: ‘virtual void boost::program_options::untyped_value::xparse(boost::any&, const std::vector >&) const’ can be marked override [-Wsuggest-override]
./boost/program_options/value_semantic.hpp:151:14: warning: ‘virtual bool boost::program_options::untyped_value::apply_default(boost::any&) const’ can be marked override [-Wsuggest-override]
./boost/program_options/value_semantic.hpp:154:14: warning: ‘virtual void boost::program_options::untyped_value::notify(const boost::any&) const’ can be marked override [-Wsuggest-override]
./boost/program_options/value_semantic.hpp:304:14: warning: ‘bool boost::program_options::typed_value::is_composing() const [with T = bool; charT = char]’ can be marked override [-Wsuggest-override]
./boost/program_options/value_semantic.hpp:306:18: warning: ‘unsigned int boost::program_options::typed_value::min_tokens() const [with T = bool; charT = char]’ can be marked override [-Wsuggest-override]
./boost/program_options/value_semantic.hpp:315:18: warning: ‘unsigned int boost::program_options::typed_value::max_tokens() const [with T = bool; charT = char]’ can be marked override [-Wsuggest-override]
./boost/program_options/value_semantic.hpp:325:14: warning: ‘bool boost::program_options::typed_value::is_required() const [with T = bool; charT = char]’ can be marked override [-Wsuggest-override]
./boost/program_options/value_semantic.hpp:337:22: warning: ‘bool boost::program_options::typed_value::apply_default(boost::any&) const [with T = bool; charT = char]’ can be marked override [-Wsuggest-override]
./boost/program_options/value_semantic.hpp:355:31: warning: ‘const std::type_info& boost::program_options::typed_value::value_type() const [with T = bool; charT = char]’ can be marked override [-Wsuggest-override]
./boost/program_options/value_semantic.hpp:93:14: warning: ‘virtual void boost::program_options::value_semantic_codecvt_helper::parse(boost::any&, const std::vector >&, bool) const’ can be marked override [-Wsuggest-override]
./boost/program_options/variables_map.hpp:165:31: warning: ‘virtual const boost::program_options::variable_value& boost::program_options::variables_map::get(const string&) const’ can be marked override [-Wsuggest-override]

BOOST_OVERRIDE was introduced in boostorg/config@ffe4e0f.

do_length hides overloaded

Got this in a build today (develop):

https://api.travis-ci.org/jobs/292877168/log.txt?deansi=true

In file included from libs/program_options/src/convert.cpp:19:
In file included from ./boost/program_options/detail/utf8_codecvt_facet.hpp:19:
./boost/detail/utf8_codecvt_facet.hpp:181:17: warning: 'boost::program_options::detail::utf8_codecvt_facet::do_length' hides overloaded virtual function [-Woverloaded-virtual]
    virtual int do_length(
                ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/codecvt.h:453:11: note: hidden overloaded virtual function 'std::codecvt<wchar_t, char, __mbstate_t>::do_length' declared here: type mismatch at 1st parameter ('std::codecvt<wchar_t, char, __mbstate_t>::state_type &' (aka '__mbstate_t &') vs 'const std::mbstate_t &' (aka 'const __mbstate_t &'))
      int do_length(state_type&, const extern_type* __from,
          ^

Long case insensitive style also makes short case insensitive.

When you use the ::long_case_insensitive style it inadvertently behaves as if you also selected ::short_case_insensitive.

I noticed this behavior since boost 1.68.0, compiling with 1.67.0 gives the correct result.

In v1.67.0, if you call the test program below like this, ./test -A, it will give the correct result:

Adam is selected:  false
Alice is selected: true

In v1.68.0 and v1.69.0 it will give the wrong result, as if ::short_case_insensitive was also selected.:

Adam is selected:  true
Alice is selected: false

Basically the -A argument becomes an -a argument.

Example code to illustrate the problem.

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

namespace po = boost::program_options;
namespace po_style = boost::program_options::command_line_style;

int main(int argc, char* argv[]){

        bool adamSelected = false;
        bool aliceSelected = false;


        try{
                po::options_description desc("Allowed options");
                desc.add_options()
                    ("adam,a", po::value<bool>(&adamSelected)->default_value(false)->implicit_value(true),"Choose Adam")
                    ("alice,A", po::value<bool>(&aliceSelected)->default_value(false)->implicit_value(true),"Choose Alice")
                ;

                po::variables_map vm;

                auto parsed = po::command_line_parser(argc, argv).options(desc).style(po_style::unix_style | po_style::long_case_insensitive).run();
                po::store(parsed, vm);

                po::notify(vm);

                std::cout << "Adam is selected:  " << (adamSelected?"true":"false") << std::endl
                        << "Alice is selected: " << (aliceSelected?"true":"false") << std::endl;
        }
        catch(std::exception& e){
                std::cerr << e.what() << std::endl;
        }
        return 0;
}

Need explanation regarding how to build after cloning

Building program_options as part of a boost distribution is easy. But if I clone this repository and want to build the latest version - how do I do that?

Either a README.md should explain this, or if you don't want to "pollute" the hierarchy with that file - at least a Wiki page here on GitHub, or a title link to somewhere explaining how to do it.

Why is it ok to add multiple option_description's with the same long name?

It seems that options_descriptions.add() doesn't check for repeat addition of an option with the same name. This is even illustrated by void test_ambiguous_short() within exception_test.cpp -- where the exception the test catches only regards the ambiguity of -c, not of --output.

What am I missing here?

Memory leaks when application is compiled with BOOST_DISABLE_THREADS

There's a memory leak if an application is compiled with BOOST_DISABLE_THREADS, is this expected behaviour?

test.cc:

#include <boost/program_options.hpp>

int main(int argc, char *argv[]) {
        boost::program_options::options_description opts{"Test"};
        opts.add_options()
                ("help,h", boost::program_options::bool_switch(), "display this help and exit");

        return 0;
}

Without BOOST_DISABLE_THREADS defined:

$ g++ -fsanitize=address  test.cc  -lboost_program_options -lboost_system -o test
$ ./test
$

With BOOST_DISABLE_THREADS defined:

$ g++ -fsanitize=address -DBOOST_DISABLE_THREADS  test.cc  -lboost_program_options -lboost_system -o test
=================================================================
==97000==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 24 byte(s) in 1 object(s) allocated from:
    #0 0x7f6757a39458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
    #1 0x7f675771777f in boost::program_options::options_description_easy_init::operator()(char const*, boost::program_options::value_semantic const*, char const*) (/usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.65.1+0x3f77f)

Indirect leak of 176 byte(s) in 1 object(s) allocated from:
    #0 0x7f6757a39458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
    #1 0x7f6757732624 in boost::program_options::bool_switch(bool*) (/usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.65.1+0x5a624)

Indirect leak of 120 byte(s) in 1 object(s) allocated from:
    #0 0x7f6757a39458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
    #1 0x7f6757717761 in boost::program_options::options_description_easy_init::operator()(char const*, boost::program_options::value_semantic const*, char const*) (/usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.65.1+0x3f761)
    #2 0x7f6756d67b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

Indirect leak of 27 byte(s) in 1 object(s) allocated from:
    #0 0x7f6757a39458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
    #1 0x7f67577155fc  (/usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.65.1+0x3d5fc)

Indirect leak of 24 byte(s) in 1 object(s) allocated from:
    #0 0x7f6757a39458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
    #1 0x7f6757716593 in boost::program_options::option_description::option_description(char const*, boost::program_options::value_semantic const*, char const*) (/usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.65.1+0x3e593)

Indirect leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x7f6757a39458 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0458)
    #1 0x7f67577326c5 in boost::program_options::bool_switch(bool*) (/usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.65.1+0x5a6c5)

SUMMARY: AddressSanitizer: 387 byte(s) leaked in 6 allocation(s).

Support for <boost/std>::filesystem::path

Basically the same issue from the mailing list which is open since Boost 1.35: http://boost.2283326.n4.nabble.com/program-options-Problem-with-paths-that-have-spaces-td2576490.html

Problem: You cannot take a *::filesystem::path param that contains spaces.

Reason: BPO uses lexical_casts which uses stream extraction stopping on first whitespace

Possible solution: Special case for types having a ctor accepting a string and using that.

Related issue: boostorg/lexical_cast#25 but won't be fixed there. Consider: lexical_cast<path>("\"/home/my user\"") is considered OK but calling a program with ./foobar "\"/home/my user\"" is not OK. So this is a BPO issue

CMake Support

Are there any plans to add cmake support in the near future?

exception thrown: std::out_of_range

error_with_option_name::what throws an exception of type std::out_of_range when
option placeholder is set up but no (or empty) original_token is provided.

strip_prefixes does not validate text argument

inline std::string strip_prefixes(const std::string& text)
{
    // "--foo-bar" -> "foo-bar"
    return text.substr(text.find_first_not_of("-/"));
}

and get_canonical_option_name passes to it whatever end user has provided to
the error_with_option_name ctor as an original_token argument

error_with_option_name::error_with_option_name(..., 
                                               const std::string& original_token,
                                               ...)
{
  m_substitutions["original_token"] = original_token;
}

string error_with_option_name::get_canonical_option_name() const
{
  if (!m_substitutions.find("option")->second.length())
      return m_substitutions.find("original_token")->second;

  string original_token = strip_prefixes(m_substitutions.find("original_token")->second);
  string option_name = strip_prefixes(m_substitutions.find("option")->second);

tested with boost 1.64.0

No way to get number of non-unlimited positional arguments

Documentation for positional_options_description says it has a max_total_count function that returns the number of positional arguments, and may return numeric_limits::max to indicate unlimited arguments. However, there is no way to determine the number of counted arguments.

Given an instance of positional_options_description, it is therefore impossible, for example, to print out a list of all positional arguments, stopping at the last, unlimited argument. A new member function that provides this is all you'd need to add, IMO.

travis fails on apple xcode

I've forked this repo and enabled macos on travis.

The tests fail on macos: https://travis-ci.com/madebr/program_options/builds/96364270

Confusing behavior when order of long/short options are swapped

Adding an option like this:

desc.add_options()( "h,help", "Print help and exit" );

In a simple test program and then trying to use --help results in a confusing error:

$ ./prog --help
libc++abi.dylib: terminating with uncaught exception of type boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::program_options::unknown_option> >: unrecognised option '--help'

The documentation for option_description::option_description(const char*, const value_semantic*) says:

The 'name' parameter is interpreted by the following rules:
if there's no "," character in 'name', it specifies long name
otherwise, the part before "," specifies long name and the part after -- short name.

However, it is easy for new users of this library to think that swapping them is OK.

The reason for this limitation isn't clear to me -- presumably, if one is "long" and the other "short", providing them in either order should be OK, and a simple test can tell which is which. In either case, the error message on misuse is needlessly cryptic and could probably be turned into an error thrown from option_description::option_description. This seems reasonable, since using "h,help" as the option name results in bad behavior regardless: the resulting executable has options --h and -h.

Compile problems on Android ndk r16 beta 1

Hello, in attempt to build boost for android with more or less reasonable strict settings (-Werror) I uncovered some bugs.

clang-darwin.compile.c++ android-build/boost/bin.v2/ 
libs/program_options/build/clang-darwin-5.0~x86/debug/ 
address-model-32/link-stati 
c/target-os-android/threading-multi/cmdline.o 
libs/program_options/src/cmdline.cpp:104:41: error: declaration shadows a 
field of 'boost::program_options::detail::cmdline' [-Werror 
,-Wshadow] 
    cmdline::init(const vector<string>& args) 
                                        ^ 
./boost/program_options/detail/cmdline.hpp:139:34: note: previous 
declaration is here 
        std::vector<std::string> args; 
                                 ^ 
libs/program_options/src/cmdline.cpp:508:48: error: declaration shadows a 
field of 'boost::program_options::detail::cmdline' [-Werror 
,-Wshadow] 
    cmdline::parse_long_option(vector<string>& args) 
                                               ^ 
./boost/program_options/detail/cmdline.hpp:139:34: note: previous 
declaration is here 
        std::vector<std::string> args; 
                                 ^ 
libs/program_options/src/cmdline.cpp:545:49: error: declaration shadows a 
field of 'boost::program_options::detail::cmdline' [-Werror,-Wshadow] 
    cmdline::parse_short_option(vector<string>& args) 
                                                ^ 
./boost/program_options/detail/cmdline.hpp:139:34: note: previous 
declaration is here 
        std::vector<std::string> args; 
                                 ^ 
libs/program_options/src/cmdline.cpp:611:47: error: declaration shadows a 
field of 'boost::program_options::detail::cmdline' [-Werror,-Wshadow] 
    cmdline::parse_dos_option(vector<string>& args) 
                                              ^ 
./boost/program_options/detail/cmdline.hpp:139:34: note: previous 
declaration is here 
        std::vector<std::string> args; 
                                 ^ 
libs/program_options/src/cmdline.cpp:632:58: error: declaration shadows a 
field of 'boost::program_options::detail::cmdline' [-Werror,-Wshadow] 
    cmdline::parse_disguised_long_option(vector<string>& args) 
                                                         ^ 
./boost/program_options/detail/cmdline.hpp:139:34: note: previous 
declaration is here 
        std::vector<std::string> args; 
                                 ^ 
libs/program_options/src/cmdline.cpp:663:47: error: declaration shadows a 
field of 'boost::program_options::detail::cmdline' [-Werror,-Wshadow] 
    cmdline::parse_terminator(vector<string>& args) 
                                              ^ 
./boost/program_options/detail/cmdline.hpp:139:34: note: previous 
declaration is here 
        std::vector<std::string> args; 
                                 ^ 
libs/program_options/src/cmdline.cpp:683:55: error: declaration shadows a 
field of 'boost::program_options::detail::cmdline' [-Werror,-Wshadow] 
    cmdline::handle_additional_parser(vector<string>& args) 
                                                      ^ 
./boost/program_options/detail/cmdline.hpp:139:34: note: previous 
declaration is here 
        std::vector<std::string> args; 
                                 ^ 
7 errors generated. 
    "/usr/local/opt/android-ndk/android-ndk-r16-beta1// 
toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++" 
"-DBOOST_AC_USE_PTHREADS" "-DBOOST_SP_USE_PTHREADS" "-fvisibility=hidden" 
"-fvisibility-inlines-hidden" "-Wno-unused-local-typedef" -x c++ -std=c++14 
-O0 -g -O0 -fno-inline -Wall -g --target=i686-none-linux-android 
--gcc-toolchain=/usr/local/opt/android-ndk/android-ndk- 
r16-beta1//toolchains/x86-4.9/prebuilt/darwin-x86_64 
--sysroot=/usr/local/opt/android-ndk/android-ndk-r16-beta1//sysroot 
-isystem /usr/local/opt/android-ndk/android-ndk-r16-beta1// 
sources/cxx-stl/llvm-libc++/include -isystem /usr/local/opt/android-ndk/ 
android-ndk-r16-beta1//sources/cxx-stl/llvm-libc++abi/include -isystem 
/usr/local/opt/android-ndk/android-ndk-r16-beta1//sources/android/support/include 
-isystem /usr/local/opt/android-ndk/android-ndk-r16-beta1//sysroot/usr/include 
-isystem /usr/local/opt/android-ndk/android-ndk-r16-beta1// 
sysroot/usr/include/i686-linux-android -DANDROID -D__ANDROID_API__=21 
-ffunction-sections -funwind-tables -fstack-protector-strong 
-fno-limit-debug-info -fPIC -no-canonical-prefixes -mstackrealign 
-Wa,--noexecstack -Wformat -Werror=format-security -Wall -Werror -Wshadow 
-march=i686 -DBOOST_ALL_NO_LIB=1 -D_LITTLE_ENDIAN -I"." -c -o 
"android-build/boost/bin.v2/libs/program_options/build/ 
clang-darwin-5.0~x86/debug/address-model-32/link-static/ 
target-os-android/threading-multi/cmdline.o" "libs/program_options/src/ 
cmdline.cpp"

This is using clang toolchain on Android NDK r16 beta1.

Reference to user-config.jam for the build

Branch coverage is around 50% (which typically means error path testing should be improved)

+lcov --gcov-tool=gcov-7 --rc lcov_branch_coverage=1 --list coverage.info
Reading tracefile coverage.info
                                               |Lines      |Functions|Branches  
Filename                                       |Rate    Num|Rate  Num|Rate   Num
================================================================================
[/home/travis/build/jeking3/boost-root/]
boost/program_options/detail/cmdline.hpp       | 100%     1| 100%   1|50.0%    6
boost/program_options/detail/config_file.hpp   |95.2%    21|77.8%  18|50.0%   86
boost/program_options/detail/convert.hpp       | 100%     5| 100%   2|62.5%   16
boost/program_options/detail/parsers.hpp       | 100%    37| 100%  13|56.1%   82
boost/program_options/detail/value_semantic.hpp|91.3%    69|79.2%  53|29.5%  484
boost/program_options/environment_iterator.hpp | 100%    19| 100%   4|53.8%   26
boost/program_options/eof_iterator.hpp         | 100%    18| 100%  15|64.3%   14
boost/program_options/errors.hpp               |94.9%    99|73.1%  78|42.2%  166
boost/program_options/option.hpp               | 100%     7| 100%   8|39.7%   68
boost/program_options/options_description.hpp  | 100%     1|50.0%   2|28.6%   14
boost/program_options/parsers.hpp              | 100%     5| 100%   6|50.0%   12
boost/program_options/positional_options.hpp   | 100%     1| 100%   1|50.0%    4
boost/program_options/value_semantic.hpp       | 100%    67|84.7% 118|56.2%  208
boost/program_options/variables_map.hpp        | 100%    17|89.5%  19|40.0%   25
libs/program_options/src/cmdline.cpp           |92.8%   334|95.8%  24|62.3%  778
libs/program_options/src/config_file.cpp       |97.2%    72| 100%   8|57.3%  206
libs/program_options/src/convert.cpp           |93.9%    33| 100%  13|40.6%   64
libs/program_options/s...ptions_description.cpp|93.4%   257|93.9%  33|56.2%  582
libs/program_options/src/parsers.cpp           | 100%    58|93.8%  16|51.0%  210
libs/program_options/src/positional_options.cpp| 100%    16| 100%   4|70.0%   20
libs/program_options/src/split.cpp             |81.8%    11|50.0%   4|27.0%  100
libs/program_options/src/value_semantic.cpp    |81.8%   192|85.7%  28|45.4%  608
libs/program_options/src/variables_map.cpp     |78.0%   100|66.7%  12|56.4%  259
================================================================================
                                         Total:|91.9%  1440|85.2% 480|50.3% 4038

Build job:
https://travis-ci.org/jeking3/program_options/jobs/350413747

Problems with displaying long option description with cyrillic characters

I'm having some weird issues with displaying long option description that contains cyrillic characters:

[program_options]$ ./example --help
Allowed options:
  -h [ --help ]                      print usage message
  -f [ --enforcewrite ] enforcewrite Всегда перезаписывать
                                     файлы в директории с
                                     преобразованной
                                     политикой безопасност▒
                                     ▒

Note that weird symbols at the description end.
Here's the code to reproduce it:

#include <boost/program_options.hpp>
using namespace boost::program_options;

#include <iostream>
using namespace std;

int main(int argc, char* argv[])
{
    string s;

    options_description desc("Allowed options");
    desc.add_options()
        ("help,h", "print usage message")
        ("enforcewrite,f", value(&s)->value_name("enforcewrite"),
        "Всегда перезаписывать файлы в директории с преобразованной политикой безопасности");

    variables_map vm;
    store(parse_command_line(argc, argv, desc), vm);

    if (vm.count("help")) {
        cout << desc << "\n";
        return 0;
    }
}

Appearance of such symbols seems to depend somehow on the length of the text string associated with the option (including option name, default value and it's description). In my case I worked around the problem by increasing the column width.

program option version is: 1.62.0
OS: CentOS 7.1

boost_program_options failed to link due to undefined references

When building a program that uses boost::program_options a couple of undefined refereneces show up:

CMakeFiles/saryxo_train.dir/src/main.cpp.o: In Function »boost::program_options::basic_command_line_parser<char>::basic_command_line_parser(int, char const* const*)«:
/usr/local/include/boost/program_options/detail/parsers.hpp:28: Warning: undefined reference to »boost::program_options::detail::cmdline::cmdline(std::__debug::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&)«
CMakeFiles/saryxo_train.dir/src/main.cpp.o:(.data.rel.ro._ZTVN5boost15program_options11typed_valueIicEE[_ZTVN5boost15program_options11typed_valueIicEE]+0x38): Warning: undefined reference to »boost::program_options::value_semantic_codecvt_helper<char>::parse(boost::any&, std::__debug::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, bool) const«
CMakeFiles/saryxo_train.dir/src/main.cpp.o:(.data.rel.ro._ZTVN5boost15program_options11typed_valueIjcEE[_ZTVN5boost15program_options11typed_valueIjcEE]+0x38): Warning: undefined reference to »boost::program_options::value_semantic_codecvt_helper<char>::parse(boost::any&, std::__debug::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, bool) const«
CMakeFiles/saryxo_train.dir/src/main.cpp.o:(.data.rel.ro._ZTVN5boost15program_options11typed_valueINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEcEE[_ZTVN5boost15program_options11typed_valueINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEcEE]+0x38): Warning: undefined reference to »boost::program_options::value_semantic_codecvt_helper<char>::parse(boost::any&, std::__debug::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, bool) const«
CMakeFiles/saryxo_train.dir/src/main.cpp.o: In Function »boost::program_options::typed_value<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, char>::xparse(boost::any&, std::__debug::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&) const«:
/usr/local/include/boost/program_options/detail/value_semantic.hpp:184: Warning: undefined reference to  »boost::program_options::validate(boost::any&, std::__debug::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, int)«

I am using CMake 3.14 and link boost in the CMake list like:

cmake_minimum_required(VERSION 3.14)
set (CMAKE_CXX_STANDARD 14)
find_package(Boost 1.70 COMPONENTS filesystem program_options REQUIRED)
...
target_link_libraries(project ${Boost_LIBRARIES})

System Plattform: Ubuntu x86_64
CMake/GCC Version: 3.14/7.4.0
Boost Version: 1.71

symbol visibility problem on macOS

When I compile with gcc-9, gcc-10, clang-9, clang-10 or the Xcode clang I have this problem. I do not see it under Linux (Ubuntu 18 LTS):
BUG-REPORT.txt

I get linkage warnings that suggest possible runtime failure

ld: warning: direct access in function '__ZN5boost10wrapexceptINS_15program_options14unknown_optionEEC1ERKS3_' from file lib/libboost_program_options.a(options_description.o)' to global weak symbol '__ZTVN5boost15program_options5errorE' from file XXX means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.

What's weird is that visibility should only apply to dynamic linkage, and I have built the libraries entirely statically.

I was able to get around this by building all of boost by supplying cxxflags="-fvisibility=default" to b2. Probably not the right fix but make the problem go away.

Probably incomplete list of symbols causing this problem. I do not have this issue with any other Boost library I use.

implicit_value eats the following positional argument

implicit_value seems a bit too greedy in v1.65. I guess it is related to the discussion in #25. For example, suppose a.out has an option -v,--verbose with implicit_value(true) and a positional argument.

# positional argument is set properly
./a.out infile

# -v is invalid; positional argument is empty
./a.out -v infile

# -v is set to false; positional argument is empty
./a.out -v 0

Possible work-around for users will be like these:

# give the positional argument first
./a.out infile -v

# give an *explicit* value to the implicit option
./a.out -v1 infile

I think that even in the case of -v infile the evaluation of positional/required arguments should precede the implicit value consumption given that those options already have implicit values.

Add CI builds to improve pull request and code quality

CI builds would run every pull request and periodically run master and develop through builds to prove out code correctness (i.e. does it compile, link, and pass unit tests?) as well as code coverage and static code analysis (coverity scan, cppcheck, ubsan jobs).

There are good examples in the Boost.DateTime, Boost.Format, and Boost.Uuid repositories on how to set these up. I can assist in setting these up if needed.

Long option name tokens are parsed as previous option value

program_options/src/cmdline.cpp

Line 477 in d95d316

const option_description* od = m_desc->find_nothrow(other_tokens[0],

If long option follows an option with (string) value, it is parsed as value instead of known option. For example in command line "--option_with_value --known_option", option_with_value will have value equal to "--known_option". This issue does not occur if following option is in short format.

As I understand the code, find_nothrow in referenced file is given token with leading dashes instead of option's string_key (or name).

Strange behavior with empty "--"

In this example

example -- --option

arguments are going to be parsed as positional arguments: "--" and "--option". I don't understand why.

Issue with count() when using empty long argument

I'm trying to use the library with an empty long argument and a short argument (in the example: (",h", "help")). The variable_map.count() in this case doesn't seem to work, i.e., even if -h is an argument count("h") or count(",h") always returns 0. (I'm also not sure what is the correct syntax for count when there is an empty long argument.)

I've added a minimal working example

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

    namespace po = boost::program_options;

    int main(int argc, char* argv[])
    {
      po::options_description test("test");
      test.add_options()
        (",h", "help");

      po::variables_map vm;
      po::store(po::parse_command_line(argc, argv, test), vm);
      po::notify(vm);

      if(vm.count(",h"))
        {
          std::cout<<"Success\n"; // never reaches here
        }

      return 0;
    }

I had a very quick look at the code, it seems like this isn't currently possible with the library.

Use boost-ci

This repository uses its own outdated copy of the boost-ci scripts. It could use the boost-ci scripts directly, and passively gain from improvements to said scripts.

basic_command_line_parser::options() may store address of temporary

Hi,

I've stambled accross a bug in my application about unrecognized options. After several minutes and checks I've realized it comes from Boost Program_Options because the basic_command_line_parser::options function store the address of a const-reference passed as argument. And since temporaries can bind to const-reference the library did use a dangling pointer.

It is not mentioned in the documentation that user must specify a valid reference.

I propose that options() and positional() make a copy (as it's backward compatible) or to take a non-const reference as it explains correctly the ownership to the caller (but not backward compatible)

Example of code that may reproduce the bug:

#include <boost/program_options.hpp>

namespace po = boost::program_options;

po::options_description create()
{
	po::options_description desc;

	desc.add_options()
		("verbose", po::bool_switch());

	return desc;
}

int main(int argc, char** argv)
{
	po::variables_map vm;
	po::store(po::command_line_parser(argc, argv).options(create()).run(), vm);
	po::notify(vm);
}

Offending code https://github.com/boostorg/program_options/blob/develop/include/boost/program_options/detail/parsers.hpp#L37

More robust common_config_file_iterator

common_config_file_iterator::common_config_file_iterator has a little problem: One of the args is std::set, which is incompatible between libc++ and libstdc++. As a result, the function, if compiled with {GCC, Clang}, is incompatible with {Clang, GCC). This can be fixed without breaking anything by moving it to the header part and declaring it static. What are your opinions about it?

Use library as header only?

Is it possible to use the library as header only for example by defining a macro?
Would it be in principle be possible? (e.g. by systematically moving code from the cpp files to the hpp files).

Is a header only version of the library being considered?

Fails to build the .lib on msvc toolchain

master branch of the superproject (boostorg/boost@43468c7) fails to produce the .lib files for program options, causing the build of my own library tests to fail:

https://ci.appveyor.com/project/vinniefalco/beast/build/master%20(%231328)

msvc.link libs\beast\bin\example\echo-op\msvc-14.0\debug\threading-multi\echo-op.exe
LINK : fatal error LNK1181: cannot open input file 'bin.v2\libs\program_options\build\msvc-14.0\debug\threading-multi\boost_program_options-vc140-mt-gd-1_65.lib

Performing git checkout boost-1.64.0 resolves the issue. The problem has been bisected with certainty, indicating these defective commits:

Superproject: boostorg/boost@025ccc0

program_options: 1f9413f

Furthermore we have identified another critical issue, @vprus has not yet joined the #boost channel on cpp-lang Slack: http://cpplang.diegostamigni.com/ Please resolve this!

options cannot be stored in variables

It seems like storing options in variables doesn't work.

Sample code (based on tutorial):

#include <boost/program_options.hpp>
using namespace boost::program_options;

#include <iostream>
using namespace std;

/* Auxiliary functions for checking input for validity. */

/* Function used to check that 'opt1' and 'opt2' are not specified
at the same time. */
void conflicting_options(const variables_map& vm,
  const char* opt1, const char* opt2)
{
  if (vm.count(opt1) && !vm[opt1].defaulted()
    && vm.count(opt2) && !vm[opt2].defaulted())
    throw logic_error(string("Conflicting options '")
      + opt1 + "' and '" + opt2 + "'.");
}

/* Function used to check that of 'for_what' is specified, then
'required_option' is specified too. */
void option_dependency(const variables_map& vm,
  const char* for_what, const char* required_option)
{
  if (vm.count(for_what) && !vm[for_what].defaulted())
    if (vm.count(required_option) == 0 || vm[required_option].defaulted())
      throw logic_error(string("Option '") + for_what
        + "' requires option '" + required_option + "'.");
}

int main(int argc, char* argv[])
{
  try {
    string ofile;
    string macrofile, libmakfile;
    bool t_given = false;
    bool b_given = false;
    string mainpackage;
    string depends = "deps_file";
    string sources = "src_file";
    string root = ".";

    options_description desc("Allowed options");
    desc.add_options()
      // First parameter describes option name/short name
      // The second is parameter to option
      // The third is description
      ("help,h", "print usage message")
      ("output,o", value(&ofile), "pathname for output")
      ("macrofile,m", value(&macrofile), "full pathname of macro.h")
      ("two,t", bool_switch(&t_given), "preprocess both header and body")
      ("body,b", bool_switch(&b_given), "preprocess body in the header context")
      ("libmakfile,l", value(&libmakfile),
        "write include makefile for library")
        ("mainpackage,p", value(&mainpackage),
          "output dependency information")
          ("depends,d", value(&depends),
            "write dependencies to <pathname>")
            ("sources,s", value(&sources), "write source package list to <pathname>")
      ("root,r", value(&root), "treat <dirname> as project root directory")
      ;

    variables_map vm;
    store(parse_command_line(argc, argv, desc), vm);

    if (vm.count("help")) {
      cout << desc << "\n";
      return 0;
    }

    conflicting_options(vm, "output", "two");
    conflicting_options(vm, "output", "body");
    conflicting_options(vm, "output", "mainpackage");
    conflicting_options(vm, "two", "mainpackage");
    conflicting_options(vm, "body", "mainpackage");

    conflicting_options(vm, "two", "body");
    conflicting_options(vm, "libmakfile", "mainpackage");
    conflicting_options(vm, "libmakfile", "mainpackage");

    option_dependency(vm, "depends", "mainpackage");
    option_dependency(vm, "sources", "mainpackage");
    option_dependency(vm, "root", "mainpackage");

    cout << "two = " << vm["two"].as<bool>() << "\n";
    cout << "depends = " << depends << "\n";
    cout << "depends = " << vm["depends"].as<string>() << "\n";
  }
  catch (exception& e) {
    cerr << e.what() << "\n";
  }
}

And here is an example console printout:

$ ./Gmame.exe -p e -d fg
two = 0
depends = deps_file
depends = fg

It seems like the provided storage variable is just being ignored? If this is incorrect somehow then the tutorial needs to be updated as well.

Building using boost 1.68 on Windows using MSVC 2017.

List of non BOOST-prefixed macros

The following macros are missing a BOOST_ prefix, which is against Boost library guidelines:

./boost/program_options.hpp:#ifndef PROGRAM_OPTIONS_VP_2003_05_19
./boost/program_options.hpp:#define PROGRAM_OPTIONS_VP_2003_05_19
./boost/program_options/config.hpp:#endif // PROGRAM_OPTIONS_CONFIG_HK_2004_01_11

The short name is limited to 1 char

Version 1.73.0

Documentation (https://www.boost.org/doc/libs/1_73_0/doc/html/boost/program_options/option_description.html#id-1_3_31_9_7_1_1_2_5-bb):

The 'name' parameter is interpreted by the following rules:
if there's no "," character in 'name', it specifies long name
otherwise, the part before "," specifies long name and the part after -- short name.

Code, options_descriptions.cpp, line 205:

if (last_name.length() == 1) {
                m_short_name = '-' + last_name;
                m_long_names.pop_back();

This limitation is not mentioned in the docs.
I would prefer that short names of several characters are allowed, but otherwise the limitations should be at least mentioned.
Side note: the possibility of having several long names separated by colons is not mentioned there, either.

Builds on cygwin (32 and 64-bit) fail due to missing putenv() definition

Likely a missing include or macro in the build environment. Identified with new CI build suite.
See: https://ci.appveyor.com/project/jeking3/program-options/build/job/6cwpgdbjt75iw334

libs\program_options\test\parsers_test.cpp: In function 'void test_environment()':
674libs\program_options\test\parsers_test.cpp:255:46: error: 'putenv' was not declared in this scope
675     putenv(const_cast<char*>("PO_TEST_FOO=1"));
676                                              ^
677
678    "g++"   -std=c++03 -m64 -O0 -fno-inline -Wall -g  -DBOOST_ALL_NO_LIB=1  -I"." -c -o "bin.v2\libs\program_options\test\parsers_test.test\gcc-6.4.0\debug\cxxstd-03-iso\link-static\target-os-cygwin\parsers_test.o" "libs\program_options\test\parsers_test.cpp"
679
680...failed gcc.compile.c++ bin.v2\libs\program_options\test\parsers_test.test\gcc-6.4.0\debug\cxxstd-03-iso\link-static\target-os-cygwin\parsers_test.o...

klocwork analysis finding: memory leak

Problem Description:
44 int parse_cmd_options(int argc, char **argv) {
45 po::options_description desc{"Options"};
46 desc.add_options()
47 ("help", "Convolution Options:")
48 ("mb,n", po::value(&mb), "Batch size")

klocwork report: Memory leak. Dynamic memory stored in 'po::value ( &sw)' allocated through function 'value' at line 48 is lost at line 46

The boost version we used is 1.69
Any comments for this issue?

Enable Coverity Scan integration

Now that the ci PR was merged, we can enable Coverity Scan integration. As admin of the repository you will need to go to scan.coverity.com and sign in with your github account, and do "Add Project" -> "Register my GitHub Project" -> select the boostorg/program_options project to add. After that, you need to take the project token on the project settings page and put it into your Travis CI settings for the boostorg/program_options builds, and make them private (there's a toggle):

COVERITY_SCAN_TOKEN (set to the token from coverity scan)
COVERITY_SCAN_NOTIFICATION_EMAIL (set to your email so you get notified on completed builds)

At some point I might put together some better instructions on how to do this with pictures...

Also recommend setting up a weekly cron on develop and master in travis CI.

Skip unknown options while parsing env vars

When using parse_environment() It will be convenient to skip environment variables not recognized as program options that still have the specified prefix.

At the moment all the environment variables that start with the specified prefix are collected and a subsequent call to store() will raise a unknown_option exception

exception thrown: bad_lexical_cast

Hi,

we discovered, that boost crashes with "bad_lexical_cast" if we provide an empty "string" as parameter.
Tested with boost 1.58.0 and 1.63.0

Cli input to reproduce: sleep ""

gdb Backtrace (catch throw) with boost_ver: 1.58.0

#0  0x00007ffff2cbbd90 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x000000000049a12e in boost::throw_exception<boost::bad_lexical_cast> (e=...) at path/gcc48/include/boost-1_58_1/boost/throw_exception.hpp:69
#2  0x00007ffff739ea91 in boost::conversion::detail::throw_bad_cast<std::string, unsigned int> () at path/gcc48/include/boost-1_58_1/boost/lexical_cast/bad_lexical_cast.hpp:92
#3  0x00007ffff739e123 in boost::lexical_cast<unsigned int, std::string> (arg="") at path/gcc48/include/boost-1_58_1/boost/lexical_cast.hpp:42
#4  0x00007ffff739d901 in boost::program_options::validate<unsigned int, char> (v=..., xs=std::vector of length 1, capacity 1 = {...})
    at path/gcc48/include/boost-1_58_1/boost/program_options/detail/value_semantic.hpp:89
#5  0x00007ffff739d44c in boost::program_options::typed_value<unsigned int, char>::xparse (this=0x70fff0, value_store=..., new_tokens=std::vector of length 1, capacity 1 = {...})
    at path/gcc48/include/boost-1_58_1/boost/program_options/detail/value_semantic.hpp:167
#6  0x00007ffff4c6f0b5 in boost::program_options::value_semantic_codecvt_helper<char>::parse(boost::any&, std::vector<std::string, std::allocator<std::string> > const&, bool) const ()
   from path/gcc48/lib/x86_64-linux-gnu/libboost_program_options-gcc48-mt-1_58_1.so.1.58.1
#7  0x00007ffff4c6b1da in boost::program_options::store(boost::program_options::basic_parsed_options<char> const&, boost::program_options::variables_map&, bool) ()
   from path/gcc48/lib/x86_64-linux-gnu/libboost_program_options-gcc48-mt-1_58_1.so.1.58.1
#8  0x00007ffff74a08f8 in program_name::cli::namespace_version::bindCommandline (tokens=..., startIdx=0, opts=..., popts=..., vmap=...)

content of 'boost::program_options::basic_parsed_options const&' :

{options = std::vector of length 1, capacity 1 = {{string_key = "time", position_key = 0, value = std::vector of length 1, capacity 1 = {""}, original_tokens = std::vector of length 1, capacity 1 = {""}, 
      unregistered = false, case_insensitive = false}}, description = 0x7ffff788b620 <program_name::cli::namespace_version::POConsoleInput::s_sleepOptions>, m_options_prefix = 1}

Thank you in advance

boost program options: win64: bcp namespace renamed version: .lib file of program_options for .dll is not created

Between boost 1.63.0 and 1.65.1 line 12 of file 'libs/program_options/build/Jamfile.v2' has been changed:
1f9413f

This change is the reason why the *.lib file for the program_options *.dll file is not created on win64/win32.

Please consider reverting the change mentioned above partially and put back the definition of the flag BOOST_PROGRAM_OPTIONS_DYN_LINK=1:

diff -ruN boost_1_65_1.orig/libs/program_options/build/Jamfile.v2 boost_1_65_1/libs/program_options/build/Jamfile.v2
--- boost_1_65_1.orig/libs/program_options/build/Jamfile.v2	2018-11-20 15:18:48.469951300 +0100
+++ boost_1_65_1/libs/program_options/build/Jamfile.v2	2018-11-22 10:27:15.108147800 +0100
@@ -11,6 +11,10 @@
 
 boost-lib program_options
     : $(SOURCES).cpp
-    : # See https://svn.boost.org/trac/boost/ticket/5049
+    : <link>shared:<define>BOOST_PROGRAM_OPTIONS_DYN_LINK=1 # tell source we're building dll's
+      # See https://svn.boost.org/trac/boost/ticket/5049
       <target-os>hpux,<toolset>gcc:<define>_INCLUDE_STDC__SOURCE_199901
-    ;
\ No newline at end of file
+    :
+    : <link>shared:<define>BOOST_PROGRAM_OPTIONS_DYN_LINK=1
+    ;
+

Similar to issue: #60