program_options, description string formatting question
Hi, Is it possible to generate a description in the following format using program_options? It is a more compact format than the program_options default. It helps keep the left hand column's max length smaller, thus preventing some excess wrapping in the description column. Compact format: [-h/--help] display usage [-p/--purpose arg] model-selection or prediction [model-selection] -d/--drug arg HIV drug to be tested [-t/--thresholds arg] low and high thresholds for drug resistance Please use only one or two values. [10] Program Options Default: -h [ --help ] display usage -p [ --purpose ] arg (=model-selection) model-selection or prediction -d [ --drug ] arg HIV drug to be tested -t [ --thresholds ] arg Thresholds for high and low resistance . Please use only 1 thresholds. In the compact case, drug is a required option, but the others are optional. So, drug does not get brackets. Also, default arguments are placed brackets at the end of the descriptor. Such as, [10] for thresholds Thanks, Ed
Ed Johnson wrote:
Hi,
Is it possible to generate a description in the following format using program_options?
[...] I was in the process of writing a message asking for something similar, when I saw this ;) I was only thinking about the location of the default value though, instead of -t [ --min-trunc ] arg (=1.77635683940025e-15) Minimum desired truncation error per site of the effective basis I am putting the default as part of the description text: -t [ --min-trunc ] arg Minimum desired truncation error per site of the effective basis [default 1.77635683940025e-15] but a way to achieve this automatically would be great. Also, an overload of options_description_easy_init::operator() that takes a std::string as the last parameter would be really useful, save having to use .c_str() ugliness. By the way, there was never any response to the query at http://thread.gmane.org/gmane.comp.lib.boost.user/21083/focus=21084 concerning multiple boolean switches. If no one else does first sometime I'll get around to trying the solution I suggested in the root mail (a new class derived from value_semantic) - but I'm not even sure if that is the correct way to achieve it. Regards, Ian
participants (2)
-
Ed Johnson -
Ian McCulloch