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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
