Chuck Messenger wrote:
* Library-managed default values
I think it good idea. Need to flesh some details a bit.
See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Library-Managed_Default_Values_-_Program_Options_Suggestion
Replace default_value() with optional 3rd arg to parameter(); hardwired [...] is fine.
OK, I think we've mostly agreed. See the wiki.
I have new thoughts -- see wiki. Basically, simplify things by eliminating paramter() and default_value() -- turning them into regular arguments -- and by combining the first 2 string args. This would make for much less typing.
* Adaptive formatting (first field width)
See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Adaptive_For matting_-_First_Field_Width_-_Program_Options_Suggestion
We can't ignore that looks matter. Ugly won't fly.
The question is: what if first field width is larger than maximum width? What can we do?
Then let the long column be out of alignment. There could be a function to set the max column width.
* program_name() and %progname%
I'm unsure on both of them. See my comments on Wiki
See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Program_Name _-_Program_Options_Suggestion
Show an example of "hardcoded" program name.
For example: options_description desc("Usage: my_program 1.0.1 <args> OPTIONS\n"
" OPTIONS");
As on wiki: what if I change the name of my program? (which happens alot). It's a natural thing for program_options to extract the program name, since you're already passing it argv[0].
* Mandatory options
Good idea. Output formatting is the only issue with me.
See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Mandatory_Options_-_Program_Options_Suggestion
I like your format.
Great! We've agreed.
The only thing is to figure out how to specify your format. Perhaps with something like:
options_description desc("Usage: %progname% %args% OPTIONS\n"
" MANDATORY OPTIONS:\n"
"%mandatory_options%"
" OPTIONS:\n"
"%optional_options%");This could be the default string. (obviously, don't use "optional_options" literally :-)
* add_options() should use references rather than pointers
That's style issue, and I'm not partial. Let's hear other opinions.
See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Add_Options_ Should_Use_References_Rather_Than_Pointers_-_Program_Options_Suggestion
I don't agree. "Pointer for return value" is C semantics. In C++, pointers denote optional values. Non-const references are for return values.
Ehm... the "pointer for return values" rule is from TC++PL, IIRC.
TC++PL is Stroustrup, right? I think I found the quote you're thinking of. In section 5.5 (3rd edition):
To keep a program readable, it is often best to avoid functions that
modify their arguments. Instead, you can return a value from the
function explicitly or require a pointer argument:int next(int p) { return p+1; }
void incr(int *p) { (*p)++; }
void g()
{
int x = 1;
increment(x);
x = next(x);
incr(&x);
} The increment(x) notation doesn't give a clue to the reader that x's
value is being modified, the way x=next(x) and incr(&x) does.
Consequently, "plain" reference arguments should be used only where
the name of the function gives a strong hint that the reference
argument is modified.I hate to disagree with Stroustrup, but ... in this case, it's pretty obvious that increment(x) is going to change x. What he's saying is that passing the address can serve as an aid to comprehension in ambiguous situations.
I'd argue that in the case of parameter(), it isn't ambiguous. But, then again, I can see that a programmer could be confused as to which parameter was the default value, if care wasn't taken. Perhaps this argues in favor of your default_value() call.
Anyway, I can accept that many people (maybe even most, or even everyone but me) agree with your semantics of "use pointer for return value". Maybe others will pipe in...
- Chuck
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
