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

Subject: Re: [boost] Feature suggestions for Boost's program_options
From: Eyal Rozenberg (eyalroz_at_[hidden])
Date: 2016-08-09 05:23:37

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.