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

Subject: Re: [boost] Feature suggestions for Boost's program_options
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-08-09 09:01:55

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.