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.