Boost logo

Boost :

From: Chuck Messenger (chuckm_at_[hidden])
Date: 2003-05-22 07:51:47


Vladimir Prus wrote:
>... See my replies at
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Suggestions_-_Program_Options_Library
>

...

>>One-line summaries of my suggestions:
>
> And one-line summaries of my replies....

And brief summaries of replies, with links to each thread (I split up
the page)

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

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

>>* Adaptive formatting (first field width)

See
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Adaptive_Formatting_-_First_Field_Width_-_Program_Options_Suggestion

We can't ignore that looks matter. Ugly won't fly.

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

>>* Unified exception class
>
> I think such class exists already.

See
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Unified_Exception_Class_-_Program_Options_Suggestion

OK, but change exception name from "error" to "program_options_error"

>>* 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_Options_-_Program_Options_Suggestion

I like your format.

>>* 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_Option_Present_Parameter_To_Add_Options_-_Program_Options_Suggestion

E.g., "grep -f file" -- we want file name, and "pattern-in-file" mode

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

>>* 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_Exception_-_Program_Options_Suggestion

No - this was just a workaround for lack of integrated argument processing.

     - Chuck


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk