Re: [boost] Feature suggestions for Boost's program_options

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 
>> 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?
>
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.
>> 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: 
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