Feature suggestions for Boost's program_options
Greetings Boost developers, [ Disclaimer: I'm new to this list - I joined by Vladimir Prus' suggestion that I raise my feature ideas here on the list. I've read the posting guidelines, and I haven't seen any discussion of program_options (at least not by Vladimir himself) for at least a year back in the list archives, so I think my post is legit. ] I've been using Boost's program_options library for several months now. It mostly does the job (that's a compliment...) - but there are some features whose lack is really bugging me. For some of them (especially Feature Idea 1) I actually work around by taking some options as unparsed remainders, sticking them in a string->string map and parsing them myself. Without further ado, and in decreasing order of importance to me: -------------------------------- Feature Idea 1: Support specifying multiple alternative long option names, using comma-separation. Right now we can specify, for example, "include-path,I" - one short form, one long form. Why not allow specifying "include-path,include-dir,headers-path,I" ? Only the first long option name would be printed as part of the usage information, to not complicate things overmuch, and merely tolerate alternative phrasing. Feature Idea 2: Have a (new?) parser which supports taking "semi-parsed command-line options" as input: A map from string keys to string values, or to optional<string> values to represent options without an argument as well. This is actually very close to environment parsing, except that the environment parser gets its "map" from, well, the environment variables. So the implementation might be simply exposing the existing functionality with a slightly richer interface. Feature Idea 3: A facility for pretty-printing parsed options to an std::ostream, in which the option description starts the line, and the option value (not the name used for parsing) is printed after it. There is some pretty-printing for the usage info to the console, so why not this? (Argument against this idea: Choosing a default is a very touchy subject. Counter-argument: ... but that's also somewhat true of printing usage information; and nobody has to use this default, it would be entirely optional.) Feature Idea 4: Support three rather than just two levels of describing options: name, for the command line; short description, for listing values (see Feature Idea 3; long description for the usage info. Feature Idea 5: Create a variant of update_with which doesn't just set the option value, but creates a link of sorts between the variable which the app would use and the variable_map entry. With this in place, further changes to the variable map automagically affect the app variable. -------------------------------- So, - What do you think about these suggestions, in principle? - If you find some of them relevant, can you help estimate the necessary development effort and possible negative implications/caveats to consider? - Assuming a feature idea is both relevant and feasible, is it customary to request implementation by the maintainer? Commit yourself to implementing it vis-a-vis statement of statement of partiality to accepting a patch? Some other practice? Thank you for getting through the long(ish) email and for your hard work, Eyal Rozenberg DB architecture group CWI Amsterdam
Am 07.08.2016 um 18:58 schrieb Eyal Rozenberg:
So,
- What do you think about these suggestions, in principle? Sound useful, and quite clear. - If you find some of them relevant, can you help estimate the necessary development effort and possible negative implications/caveats to consider? Have you looked at the code and checked that? Boost is an open source community, so the easiest way would probably be to just write it yourself. - Assuming a feature idea is both relevant and feasible, is it customary to request implementation by the maintainer? Commit yourself to implementing it vis-a-vis statement of statement of partiality to accepting a patch? Some other practice?
I think not. You can just fork the library on github, implement the features and create a pull request there. Though unlike my first PRs, they need to be clean, i.e. one feature per PR. If you do that, i.e. implement the feature, write a test and add documentation, there's not much reason for the maintainer to not accept that. You can of course flag the PR as WIP, so that you show what you want to do and discuss it before wirting all the tests etc. And of course once you started you'll probably get more help than with a feature request. Please keep in mind, that most of the maintainers are really busy, so while they'd probably be glad to help you, they can't spend the time to add whole new features.
Thank you for getting through the long(ish) email and for your hard work, Eyal Rozenberg DB architecture group CWI Amsterdam
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 07-08-16 19:48, Klemens Morgenstern wrote:
- If you find some of them relevant, can you help estimate the necessary development effort and possible negative implications/caveats to consider? Have you looked at the code and checked that? Boost is an open source community, so the easiest way would probably be to just write it yourself.
I have just started to look through the code. I find that it is mostly pre-C++11-style, perhaps even pre-C++03-style, coding; under-use of generics and STL algorithms etc. In the bottom line, I feel that implementation might not be overly hard, but it will also not be pretty, piling the bit-of-a-mess higher by a bit more, even with my best attempts. Yet I will certainly not have the time to suggest a major refactoring. Which leaves me a bit uncertain what to do. I had assume there is some Boost-wide coding standard and/or best practices guide, which would tell me among other thing that if I do X I also need to do Y and support Z and adhere to the use of constructs W1 and W2 and so on. Isn't there?
I think not. You can just fork the library on github, implement the features and create a pull request there.
I've done the fork, but I don't know how to build it independently of the rest of Boost (or with dependence on a release version of Boost not including the library). Is there reasonable documentation on this? I've heard the suggestion to use bcp and pull some of all-of-Boost; is that better' worse?
Though unlike my first PRs, they need to be clean, i.e. one feature per PR. If you do that, i.e. implement the feature, write a test and add documentation,
One PR per feature - no problem. Testing, documentation for my code - also no problem. What about lack of testing for the code earlier to mine?
there's not much reason for the maintainer to not accept that. You can of course flag the PR as WIP, so that you show what you want to do and discuss it before wirting all the tests etc.
Also a good idea. Note, though, that some of the existing functionality is not covered by tests itself.
Am 09.08.2016 um 11:23 schrieb Eyal Rozenberg:
On 07-08-16 19:48, Klemens Morgenstern wrote:
- If you find some of them relevant, can you help estimate the necessary development effort and possible negative implications/caveats to consider? Have you looked at the code and checked that? Boost is an open source community, so the easiest way would probably be to just write it yourself.
I have just started to look through the code. I find that it is mostly pre-C++11-style, perhaps even pre-C++03-style, coding; under-use of generics and STL algorithms etc. In the bottom line, I feel that implementation might not be overly hard, but it will also not be pretty, piling the bit-of-a-mess higher by a bit more, even with my best attempts. Yet I will certainly not have the time to suggest a major refactoring. Which leaves me a bit uncertain what to do.
I had assume there is some Boost-wide coding standard and/or best practices guide, which would tell me among other thing that if I do X I also need to do Y and support Z and adhere to the use of constructs W1 and W2 and so on. Isn't there?
I think not. You can just fork the library on github, implement the features and create a pull request there.
I've done the fork, but I don't know how to build it independently of the rest of Boost (or with dependence on a release version of Boost not including the library). Is there reasonable documentation on this? I've heard the suggestion to use bcp and pull some of all-of-Boost; is that better' worse? You can't really. You just replace the program_options directory in boost/libs and work in that one. Your IDE may be able to create a
Well, you probably wouldn't want to do the refactorin even if you had the time, since people are still using this library with C++98. On the other hand: you could put a feature in which requires C++11 and put it inside an #ifdef using boost.config. Not as nice, but you could do that. You find the library requirements here: http://www.boost.org/development/requirements.html The coding guidelines are rather relaxed, your code will have to be accepted by the maintainer. Boost is based on peer-reviews not strict coding standards. If you have a draft (or something hacked) he'll tell you how he'd like it to look. project in the existing directory (eclipse can). If you call 'b2' in .../program_options/test, it will run the test, in .../program_options/doc it will build the doc. If you want to just build the library, you call 'b2 --with-program_options' in the boost-root library. If you want to build the doc, you'll need to setup boostbook first, there's a tutorial here: http://www.boost.org/doc/libs/1_61_0/doc/html/boostbook/getting/started.html
Though unlike my first PRs, they need to be clean, i.e. one feature per PR. If you do that, i.e. implement the feature, write a test and add documentation,
One PR per feature - no problem. Testing, documentation for my code - also no problem. What about lack of testing for the code earlier to mine?
Well, if the previous code is not tested but accepted, it isn't your responsibility to add them. Though no one will object if you do it, I guess.
there's not much reason for the maintainer to not accept that. You can of course flag the PR as WIP, so that you show what you want to do and discuss it before wirting all the tests etc.
Also a good idea. Note, though, that some of the existing functionality is not covered by tests itself.
If you add tests there you'll have a very happy maintainer.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 8/9/2016 5:23 AM, Eyal Rozenberg wrote:
On 07-08-16 19:48, Klemens Morgenstern wrote:
- If you find some of them relevant, can you help estimate the necessary development effort and possible negative implications/caveats to consider? Have you looked at the code and checked that? Boost is an open source community, so the easiest way would probably be to just write it yourself.
I have just started to look through the code. I find that it is mostly pre-C++11-style, perhaps even pre-C++03-style, coding; under-use of generics and STL algorithms etc. In the bottom line, I feel that implementation might not be overly hard, but it will also not be pretty, piling the bit-of-a-mess higher by a bit more, even with my best attempts. Yet I will certainly not have the time to suggest a major refactoring. Which leaves me a bit uncertain what to do.
Current libraries being pre-C++11 serve the purpose that the library can be used by developers who are not compiling with C++11 on up features. Of course nothing prevents someone from creating a C++11 on up library for Boost if they like.
I had assume there is some Boost-wide coding standard and/or best practices guide, which would tell me among other thing that if I do X I also need to do Y and support Z and adhere to the use of constructs W1 and W2 and so on. Isn't there?
Nothing much like that exists officially. Personally I have almost always found best practices to be laughable. One man's "best practices" often turn out to be some other programmer's taboos.
I think not. You can just fork the library on github, implement the features and create a pull request there.
I've done the fork, but I don't know how to build it independently of the rest of Boost (or with dependence on a release version of Boost not including the library). Is there reasonable documentation on this? I've heard the suggestion to use bcp and pull some of all-of-Boost; is that better' worse?
Firstly a PR always goes against the 'develop' branch of a library. Secondly the usual way of testing the developer branch changes you may make is to change the rest of the Boost to the develop branch and pull the latest for the 'develop' branch. This is much easier than trying to use bcp and pull just what you may need.
Though unlike my first PRs, they need to be clean, i.e. one feature per PR. If you do that, i.e. implement the feature, write a test and add documentation,
One PR per feature - no problem. Testing, documentation for my code - also no problem. What about lack of testing for the code earlier to mine?
Test in the 'develop' and 'master' branch are periodically being run for all libraries.
there's not much reason for the maintainer to not accept that. You can of course flag the PR as WIP, so that you show what you want to do and discuss it before wirting all the tests etc.
Also a good idea. Note, though, that some of the existing functionality is not covered by tests itself.
You can always create a PR for such situations if you like, with appropriate tests you feel should be run as part of a library's test suite.
participants (3)
-
Edward Diener -
Eyal Rozenberg -
Klemens Morgenstern