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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-05-22 09:24:49

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-Mana
>ged_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.

> >>* add_options() should be able to parse arguments (also, %args%)
> >
> > That's a bit controversial. I don't yet see the 100% right approach.
>
> See
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Add_Options_
>Should_Be_Able_To_Parse_Arguments_-_Program_Options_Suggestion

I get your motivation. I'll think about implementation.

> >>* 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? 

> >>* 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");

> >>* Unified exception class
> >
> > I think such class exists already.
>
> See
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Unified_Exce
>ption_Class_-_Program_Options_Suggestion
>
> OK, but change exception name from "error" to "program_options_error"

I'm almost indiffirent and will be happy to leave this question to others.

> >>* Put add_options() ascii args first
> >
> > It's completely up to reviewers.
>
> See
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Add_Options_
>Should_Be_Able_To_Parse_Arguments_-_Program_Options_Suggestion
>
> >>* Mandatory options
> >
> > Good idea. Output formatting is the only issue with me.
>
> See
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Mandatory_Op
>tions_-_Program_Options_Suggestion
>
> I like your format.

Great! We've agreed.

> >>* Optional "option present" parameter to add_options()
> >
> > I'd like to see some use cases before adding this feature.
>
> See
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Optional_Opt
>ion_Present_Parameter_To_Add_Options_-_Program_Options_Suggestion
>
> E.g., "grep -f file" -- we want file name, and "pattern-in-file" mode

I understand your motivation now, and need only decide on exact interface. 

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

> >>* User exception
> >
> > If you have practical need to them, I'll add them.
>
> See
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?User_Excepti
>on_-_Program_Options_Suggestion
>
> No - this was just a workaround for lack of integrated argument processing.

OK.

Thanks again for such a comprehensive review!
- Volodya

>
>
>      - Chuck
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost