Back to Suggestions - program options library
The default value needs to be handled directly by the library. For example, currently, we have:
int magic(23); ... desc.add_options() ... ("magic", parameter<int>("value", &magic), "magic value for the program") ;
The usage message then contains the line:
--magic value : magic value for the program
However, I'd like it to contain:
--magic value : magic value for the program 
That is, it should show (or, be able to show) the default value. We should be able to have:
desc.add_options() ... ("magic", parameter<int>("value", &magic, 23), "magic value for the program [%def%]") ;
Note the use of the tag %def% to represent the default value.
That is, I'd like to see the default values in the usage message. Also, I'd like to keep the default value along with the corresponding add_options() line, which is easy to find in the code. It can be a pain to find the declaration of the variable being set, and then to figure out its default value.
- People/Chuck Messenger
Do we need %def% tag? A simpler approach would be to output default value automatically, after the description, or after the parameter name. BTW, it's possible to declare default values in the same line as parameter:
desc.add_options() ... ("magic", parameter<int>("value", &magic).default_value("23")) ;
- People/Vladimir Prus
Oh, good! Then, my suggestion is to show default_value() in your "guided tour" example code.
The only thing is, I think default_value() is really long and redundant - and unnatural to remember. The normal thing I'd expect is a 3rd optional argument to parameter(). Much less typing, less clutter, and easier to remember.
As for formatting -- the main thing I think is that you must at least be able to show the default value in [...].
I'm not sure whether I think it best to always show the default value in [...], or whether to make it user-controllable. On that, my main thought is that by default, the [...] should be shown. The user should have to take some extraordinary measure to suppress the [...]. So, if something like %def% is implemented, then there should be a %nodef% flag, too. If the format string has a %def%, then it overrides the default of putting [...] at the end of the line. If the format string has %nodef%, then the automatic [...] at the end of the line is suppressed.
But, as I said, I'm not sure you need the fanciness of something like %def% and %nodef%. I'd be happy with just putting [...] at the end of every line which has a default_value() parameter. There will always be those who advocate the fancier system which gives more controls. Among that group, 80% would be satisfied with something relatively simple, and the rest will demand something even better and more complex.
So, yet another idea is to provide a mechanism to supply your own formatting functions. Perhaps your main class could have virtual functions for that -- then, document the virtual formatting functions as part of the program_options library interface. Or, probably better, and more in keeping with the STL, would be to supply functors. Then, you could perhaps use the lambda library to good effect, e.g.: