https://svn.boost.org/trac10/ticket/3330 <p> When using boost::program_options, there is no straightforward way to set the name of a boost::program_options::value&lt;&gt;(): </p> <pre class="wiki">#include &lt;iostream&gt; #include &lt;boost/program_options.hpp&gt; int main() { boost::program_options::options_description desc; desc.add_options() ("width", boost::program_options::value&lt;int&gt;(), "Give width"); std::cout &lt;&lt; desc &lt;&lt; std::endl; return 0; } </pre><p> The above code gives: </p> <pre class="wiki"> --width arg Give width in pixels </pre><p> What it should allow is replacing the "arg" name with something more descriptive like PIXELS: </p> <pre class="wiki"> --width PIXELS Give width in pixels </pre><p> For example via <code>boost::program_options::value&lt;int&gt;("PIXELS")</code>. </p> <p> Even the tutorial makes "use" of this non-existant feature: </p> <p> <a href="http://www.boost.org/doc/libs/1_39_0/doc/html/program_options/tutorial.html">http://www.boost.org/doc/libs/1_39_0/doc/html/program_options/tutorial.html</a> </p> <p> The output at the bottom of the page shows "--optimization n" instead of "--optimization arg", same with "path". </p> <p> There is a way to accomplish a different arg name by inheriting from boost::program_options::typed_value&lt;&gt; as documented at: </p> <p> <a class="ext-link" href="http://stackoverflow.com/questions/1249646/when-using-boostprogramoptions-how-does-one-set-the-name-of-the-argument"><span class="icon">​</span>http://stackoverflow.com/questions/1249646/when-using-boostprogramoptions-how-does-one-set-the-name-of-the-argument</a> </p> <p> 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(). </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/3330 Trac 1.4.3 Vladimir Prus Mon, 10 Aug 2009 13:15:40 GMT https://svn.boost.org/trac10/ticket/3330#comment:1 https://svn.boost.org/trac10/ticket/3330#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">wontfix</span> </li> </ul> <p> 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. </p> Ticket grumbel@… Mon, 10 Aug 2009 14:32:37 GMT https://svn.boost.org/trac10/ticket/3330#comment:2 https://svn.boost.org/trac10/ticket/3330#comment:2 <ul> <li><strong>status</strong> <span class="trac-field-old">closed</span> → <span class="trac-field-new">reopened</span> </li> <li><strong>resolution</strong> <span class="trac-field-deleted">wontfix</span> </li> </ul> <p> 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&lt;&gt;(). </p> <p> The "fix" via inheritance of course works, but that seems more like a dirty workaround for a bug then the way it should be. </p> Ticket Vladimir Prus Mon, 10 Aug 2009 16:42:31 GMT https://svn.boost.org/trac10/ticket/3330#comment:3 https://svn.boost.org/trac10/ticket/3330#comment:3 <ul> <li><strong>status</strong> <span class="trac-field-old">reopened</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">wontfix</span> </li> </ul> <p> 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. </p> Ticket suggestion Tue, 18 Aug 2009 08:25:06 GMT