[boost] Re: Formal Review: Command Line & Config library

From: Chuck Messenger (chuckm_at_[hidden])
Date: 2003-05-22 15:05:53

Vladimir Prus wrote:
> 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