[program_options] Checkin candidate
The next version of the program_options library is available from http://zigzag.cs.msu.su:7813/program_options/ or http://zigzag.cs.msu.su/~ghost/program_options/ The primary change in this version is support for unicode command line and config file parsers. Please see http://zigzag.cs.msu.su:7813/program_options/html/program_options.howto.html... and the new "unicode_test.cpp" file in the "test" directory. I believe that now all major changes are finished and the library is ready to be added to CVS. If nobody find any showstoppers within a week, I'll go ahead. I'd appreciate any comments on this version. Thanks in advance, Volodya
Vladimir Prus ha escrito:
The next version of the program_options library is available from
http://zigzag.cs.msu.su:7813/program_options/ or http://zigzag.cs.msu.su/~ghost/program_options/
Documentation -> Introduction -> last sentence: "Now let's see some examples of the library usage in the ???." I guess the ??? needs to be replaced. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
1. Is it possible to expand --help so that it also gives the default values of options? Obviously, it's not likely to tell defaults that it doesn't no about, but at least the ones specified by default_value()? 2. What was the resolution to the earlier problem of confusing a negative parameter value with an option?
Neal D. Becker wrote:
1. Is it possible to expand --help so that it also gives the default values of options? Obviously, it's not likely to tell defaults that it doesn't no about, but at least the ones specified by default_value()?
I need to think about it. The biggest issue I see that that it would mean that if you have option of type T then T would be required to have operator<<, which might be too severe limitation.
2. What was the resolution to the earlier problem of confusing a negative parameter value with an option?
I think I've fixed that. See the attached. - Volodya
Vladimir Prus wrote:
Neal D. Becker wrote:
1. Is it possible to expand --help so that it also gives the default values of options? Obviously, it's not likely to tell defaults that it doesn't no about, but at least the ones specified by default_value()?
I need to think about it. The biggest issue I see that that it would mean that if you have option of type T then T would be required to have operator<<, which might be too severe limitation.
2. What was the resolution to the earlier problem of confusing a negative parameter value with an option?
I think I've fixed that. See the attached.
- Volodya
It's a small point, but here's my opinion. You say something like: "If option requires a value and following -<number> doesn't match an option, then parse it as an argument". I would suggest "If option requires a value then parse *any* following string, including -<number> as a value, unconditionally".
Neal D. Becker wrote:
It's a small point, but here's my opinion. You say something like: "If option requires a value and following -<number> doesn't match an option, then parse it as an argument".
I would suggest "If option requires a value then parse *any* following string, including -<number> as a value, unconditionally".
So the different would be that -a -b where both "a" and "b" are allowed option and "-a" requires a value, will be reported as invalid value of option "-a" not as missing value on the command line? Why do you think that's better? - Volodya
Vladimir Prus wrote:
Neal D. Becker wrote:
It's a small point, but here's my opinion. You say something like: "If option requires a value and following -<number> doesn't match an option, then parse it as an argument".
I would suggest "If option requires a value then parse *any* following string, including -<number> as a value, unconditionally".
So the different would be that
-a -b
where both "a" and "b" are allowed option and "-a" requires a value, will be reported as invalid value of option "-a" not as missing value on the command line? Why do you think that's better?
There are 2 choices: 1) Don't correctly parse some correct cases or 2) Give confusing error message for incorrect case. You'll agree #2 is better than #1. So: -a -3 where -3 is a valid option, and -a takes a value. I suppose if you decide it's better to parse -3 as an option, then you do have a workaround: -a=-3 I'm not sure what gnu getopt does in this case (although it seems to always do the right thing (TM), because I'm sure I've used this and never noticed a problem).
Neal D. Becker wrote:
There are 2 choices:
1) Don't correctly parse some correct cases
or
2) Give confusing error message for incorrect case.
You'll agree #2 is better than #1.
Yes, I do agree.
So:
-a -3
where -3 is a valid option, and -a takes a value.
Well... if we agree that "-a -3" is a correct case, then it should be handled. The reason why I'm suspicious is that it's clearly ambiguous, and I prefer to handle ambiguity as error. OTOH, "token following option with value is always value" is a simple rule, which is good. Things get more messy if "-a" has *optional* value. Should we parse "-3" as value, or as option. In fact, I wonder if we should have optional values at all, but that's a topic for a separate post.
I'm not sure what gnu getopt does in this case (although it seems to always do the right thing (TM), because I'm sure I've used this and never noticed a problem).
Jonathan say getopt does what your propose, which does qualify as good argument. I've made the change in revision 289. Thanks, Volodya
On Fri, May 07, 2004 at 10:56:25AM +0400, Vladimir Prus wrote:
Neal D. Becker wrote:
It's a small point, but here's my opinion. ?You say something like: "If option requires a value and ?following -<number> doesn't match an option, then parse it as an argument".
I would suggest "If option requires a value then parse *any* following string, including -<number> as a value, unconditionally".
So the different would be that
-a -b
where both "a" and "b" are allowed option and "-a" requires a value, will be reported as invalid value of option "-a" not as missing value on the command line? Why do you think that's better?
It's certainly what I'd expect, and what getopt() does IIRC. Try "grep -B -a foo bar" and you get an error due to "-a" not being a number (at least with GNU grep) jon
From: Vladimir Prus <ghost@cs.msu.su>
Neal D. Becker wrote:
1. Is it possible to expand --help so that it also gives the default values of options? Obviously, it's not likely to tell defaults that it doesn't no about, but at least the ones specified by default_value()?
I need to think about it. The biggest issue I see that that it would mean that if you have option of type T then T would be required to have operator<<, which might be too severe limitation.
Require that all default_value()'s provide a default value string either from operator << or explicitly when supplying the default value? default_value(x) -> must support operator <<(x) default_value(x, "x") -> no need for operator <<(x) -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart wrote:
From: Vladimir Prus <ghost@cs.msu.su>
Neal D. Becker wrote:
1. Is it possible to expand --help so that it also gives the default values of options? Obviously, it's not likely to tell defaults that it doesn't no about, but at least the ones specified by default_value()?
I need to think about it. The biggest issue I see that that it would mean that if you have option of type T then T would be required to have operator<<, which might be too severe limitation.
Require that all default_value()'s provide a default value string either from operator << or explicitly when supplying the default value?
default_value(x) -> must support operator <<(x) default_value(x, "x") -> no need for operator <<(x)
Good idea!
Neal D. Becker wrote:
Require that all default_value()'s provide a default value string either from operator << or explicitly when supplying the default value?
default_value(x) -> must support operator <<(x) default_value(x, "x") -> no need for operator <<(x)
Good idea!
True. I've just comitted/uploaded revision 288 which produces the following (don't forget to use fixed font when viewving ;-) ) Usage: options_description [options] Allowed options: --help : produce help message --optimization arg (=10) : optimization level -I [ --include-path ] arg : include path --input-file arg : input file The (=10) is meant to give default value. The only problem I've found is that we need to specify empty default value string for std::vector, which leads to code like this: ("second", value< vector<int > >()->default_value(vector<int>(1, 1), "")) Ok, maybe we just need 'vector_value' function which will take care of default values. Please consider this change experimental... we need to see if any problems will show up. - Volodya
Vladimir Prus wrote:
Neal D. Becker wrote:
Require that all default_value()'s provide a default value string either from operator << or explicitly when supplying the default value?
default_value(x) -> must support operator <<(x) default_value(x, "x") -> no need for operator <<(x)
Good idea!
True. I've just comitted/uploaded revision 288 which produces the following (don't forget to use fixed font when viewving ;-) )
Usage: options_description [options] Allowed options: --help : produce help message --optimization arg (=10) : optimization level -I [ --include-path ] arg : include path --input-file arg : input file
The (=10) is meant to give default value. The only problem I've found is that we need to specify empty default value string for std::vector, which leads to code like this:
("second", value< vector<int > >()->default_value(vector<int>(1, 1), ""))
Ok, maybe we just need 'vector_value' function which will take care of default values.
You also have the choice of not using default_value. main() { value (1,1); //set default outside of program_options program_options.... So I don't think the case you show above is a serious problem. (Nobody forces you to use default_value if it's not convenient).
Vladimir Prus wrote:
Usage: options_description [options] Allowed options: --help : produce help message --optimization arg (=10) : optimization level -I [ --include-path ] arg : include path --input-file arg : input file
The (=10) is meant to give default value. The only problem I've found is that we need to specify empty default value string for std::vector, which leads to code like this:
("second", value< vector<int > >()->default_value(vector<int>(1, 1), ""))
Ok, maybe we just need 'vector_value' function which will take care of default values.
The default value could simply be given as a string in that case: "(1,1)" or whatever. You could also use the OutputFormatters library when it is accepted into Boost. (In that case, you just wait for your automated solution.) -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart wrote:
Vladimir Prus wrote:
Usage: options_description [options] Allowed options: --help : produce help message --optimization arg (=10) : optimization level -I [ --include-path ] arg : include path --input-file arg : input file
The (=10) is meant to give default value. The only problem I've found is that we need to specify empty default value string for std::vector, which leads to code like this:
("second", value< vector<int > >()->default_value(vector<int>(1, 1), ""))
Ok, maybe we just need 'vector_value' function which will take care of default values.
The default value could simply be given as a string in that case: "(1,1)" or whatever. You could also use the OutputFormatters library when it is accepted into Boost. (In that case, you just wait for your automated solution.)
In the highly likely case when the default value of vector is empty vector, output formatters will provide not very nice result. I still think that ultimately we'd need 'vector_value', since ("second", vector_value<int>()) is a lot better than ("second", value< vector<int > >()->default_value(vector<int>(), "")) - Volodya
I believe that now all major changes are finished and the library is ready to be added to CVS. If nobody find any showstoppers within a week, I'll go ahead. I'd appreciate any comments on this version.
I needed to apply to following patch to compile under Mac OS X. It appears that environ isn't available to dynamically linked libraries, instead _NSGetEnviron() must be used. - Mike --- parsers.cpp Thu May 06 16:25:14 2004 +++ parsers.msl.cpp Thu May 06 13:27:07 2004 @@ -34,6 +34,11 @@ #include <unistd.h> #endif +#if defined(__APPLE__) && defined(__DYNAMIC__) +#include <crt_externs.h> +static char** environ = *_NSGetEnviron(); +#endif + using namespace std; namespace boost { namespace program_options {
Thanks in advance, Volodya _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--- parsers.cpp Thu May 06 16:25:14 2004 +++ parsers.msl.cpp Thu May 06 13:27:07 2004 @@ -34,6 +34,11 @@ #include <unistd.h> #endif +#if defined(__APPLE__) && defined(__DYNAMIC__) +#include <crt_externs.h> +static char** environ = *_NSGetEnviron(); +#endif + using namespace std; namespace boost { namespace program_options {
Michael LaSpina wrote:
I believe that now all major changes are finished and the library is ready to be added to CVS. If nobody find any showstoppers within a week, I'll go ahead. I'd appreciate any comments on this version.
I needed to apply to following patch to compile under Mac OS X. It appears that environ isn't available to dynamically linked libraries, instead _NSGetEnviron() must be used.
Thanks! Applied in revision 286. - Volodya
participants (6)
-
Joaquín Mª López Muñoz -
Jonathan Wakely -
Michael LaSpina -
Neal D. Becker -
Rob Stewart -
Vladimir Prus