boost::program_options doesn't allow naming the argument in a straightforward way

[grumbel@…]

When using boost::program_options, there is no straightforward way to set the name of a boost::program_options::value<>():

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

int main()
{
  boost::program_options::options_description desc;

  desc.add_options()
    ("width", boost::program_options::value<int>(),
     "Give width");

  std::cout << desc << std::endl;

  return 0;
}

The above code gives:

  --width arg           Give width in pixels

What it should allow is replacing the "arg" name with something more descriptive like PIXELS:

  --width PIXELS           Give width in pixels

For example via boost::program_options::value<int>("PIXELS").

Even the tutorial makes "use" of this non-existant feature:

http://www.boost.org/doc/libs/1_39_0/doc/html/program_options/tutorial.html

The output at the bottom of the page shows "--optimization n" instead of "--optimization arg", same with "path".

There is a way to accomplish a different arg name by inheriting from boost::program_options::typed_value<> as documented at:

​http://stackoverflow.com/questions/1249646/when-using-boostprogramoptions-how-does-one-set-the-name-of-the-argument

But considering that naming the argument is a extremely common use case, this should be doable in a much more straightforward manner, such as an additional name argument to po_value().

[Vladimir Prus]

As I've said on SO, I this this functionality is not actually going to help users of command-line very much, and not plan to implement this.

[grumbel@…]

Sorry, but thats just plain idiotic. *EVERY* single tool that I know of that can be accessed via command line makes use of custom argument names in the help output, ls, emacs, xterm, firefox, blender, gimp, gcc, make, .... I don't think I have ever seen one that doesn't. As mentioned even the boost tutorial itself makes use of that feature. And I don't quite see why it shouldn't be implemented, it would just mean an additional argument to po_value<>().

The "fix" via inheritance of course works, but that seems more like a dirty workaround for a bug then the way it should be.

[Vladimir Prus]

I am afraid I am not willing to continue this discussion with a person who cannot be bothered to express his opinion in a civil way. Reopening the issue will not help here.

[suggestion]

Maybe you two should try to fix the underlying interpersonal communication layer first ;) I'm pretty sure you two can fix this in a friendly private communication and close the bug later.

[anonymous]

Please change at least "path" to "arg" in the tutorial. I was going crazy trying to find out how it was achieving that.