Library-Managed Default Values - Program Options Suggestion

Library-managed default values

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 [23]

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.:

<pre>