Subject: Re: [boost] Feature suggestions for Boost's program_options
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-08-09 08:53:45
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
> 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?
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:
The coding guidelines are rather relaxed, your code will have to be
accepted by the maintainer. Boost is based on peer-reviews not strict
If you have a draft (or something hacked) he'll tell you how he'd like
it to look.
>> 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
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:
>> 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
> > 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:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk