|
|
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.
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.
>>* Adaptive formatting (first field width)
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
Show an example of "hardcoded" program name.
>>* Unified exception class
>
> I think such class exists already.
OK, but change exception name from "error" to "program_options_error"
>>* Put add_options() ascii args first
>
> It's completely up to reviewers.
>>* Mandatory options
>
> Good idea. Output formatting is the only issue with me.
I like your format.
>>* Optional "option present" parameter to add_options()
>
> I'd like to see some use cases before adding this feature.
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.
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.
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