[Boost-users] ProgramOptions: explicit empty string argument

Subject: [Boost-users] ProgramOptions: explicit empty string argument
From: Akim Demaille (akim_at_[hidden])
Date: 2015-01-29 10:20:43

Hi,

I would like to be able to support an empty optional
argument for long options.  This is something that is
supported by gnu getopt_long and argp.  Consider for
instance a simplified version of the first simple example
program:

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

int main(int ac, char* av[])
{
 namespace po = boost::program_options;
 using namespace std;

 po::options_description desc("Allowed options");
 desc.add_options()
   ("help", "produce help message")
   ("compression",
    po::value<string>()->implicit_value(""),
    "set compression level")
   ;

 po::variables_map vm;        
 po::store(po::parse_command_line(ac, av, desc), vm);
 po::notify(vm);    

 if (vm.count("help"))
   cout << desc << "\n";
 else if (vm.count("compression"))
   cout << "Compression level was set to " 
        << vm["compression"].as<string>() << ".\n";
 else 
   cout << "Compression level was not set.\n";
}

when I run it, in "typical cases", I have:

$ ./a.out
Compression level was not set.
$ ./a.out --compression=foo
Compression level was set to foo.
$ ./a.out --compression foo
Compression level was set to foo.
$ ./a.out --compression
Compression level was set to .

all of this is fine.  However, how can I explicitly pass
the empty string?

$ ./a.out --compression=
libc++abi.dylib: terminating with uncaught exception of type boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::program_options::invalid_command_line_syntax> >: the argument for option '--compression' should follow immediately after the equal sign
zsh: abort      ./a.out --compression=

Of course I could simply to my user that there is a special
token, say '-', that means "empty", but it is still more
complex than simply accepting the empty string to mean the
empty string.

Thanks!

(There are some stack overflow questions, but they do not
address this particular point, --foo='').