From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2019-09-17 16:05:01
On Tue, Sep 17, 2019 at 12:02 AM Vicram Rajagopalan via Boost <
> On Thu, Sep 12, 2019 at 11:01 AM Zach Laine via Boost
> <boost_at_[hidden]> wrote:
> > I agree with a lot of the points raised above about the problematic
> > of Boost.ProgramOptions. I also think Lyra looks interesting.
> Regarding Lyra, I took a look at the Github repo a few weeks ago, but
> as far as I could tell, it hasn't gained much traction. That was just my
> impression from the low number of stars, watches, issues, and pull
> requests. Are there any particular reasons that y'all recommend Lyra
> in particular?
I only just heard about it in this thread.
> Granted, development/maintenance does seem to be active, which
> is a good sign in my book.
> > If you're interesting in solving problems in this space, rather than
> > a straight port, here are some things I would find very helpful, not all
> > which Lyra provides:
> I suppose what I'd really like to see is a de-facto standard; right now,
> it doesn't seem that one exists. Given that Boost.ProgramOptions is
> not a particularly good example to follow, the best use of my time
> may be to contribute to a healthy project. cxxopts is one that caught
> my eye, as it seems more well-known than most other similar
> projects. Does anyone have any impressions of cxxopts (or others)?
IMO, what made libfmt (which became C++20's std::format) a success is that
it took an existing and popular API for string formatting (from Python) and
implemented it efficiently. If you were to do the same thing with Python's
argparse, I think the result would be similar. I say this because all the
libraries above, and probably others besides, are each taking a particular
point of view, API-wise, that has not necessarily caught on. Perhaps one
of them will, I don't know. I *do* know that the argparse API has been
stable for years, and covers every scenario for handling command line
arguments that I have seen.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk