search

bfgroup / Lyra

A simple to use, composable, command line parser for C++ 11 and beyond
https://bfgroup.github.io/Lyra/
Boost Software License 1.0
483 stars 58 forks source link

Add a feature comparison with other parser libraries #31

Open eyalroz opened 4 years ago

eyalroz commented 4 years ago

There are several popular C++ command-line parsers other than Lyra - some probably even more popular if we count GitHub stars: cxxopt, CLI11, the venerable Boost program_options and possibly others.

A developer finding this repository may be impressed by the "composable parsing" feature, showcased in the README.md, but has no idea whether how the feature set of Lyra compares to that of other popular options.

As a service to potential adopters, I suggest/ask that you create such a comparative table. It would be a good fit as a wiki page

As an example and inspiration, have a look at this table, comparing several unit-test frameworks for C++.

grafikrobot commented 4 years ago

I was already thinking of doing that. So thanks for the push :-)

eyalroz commented 4 years ago

It seems that every one of these libraries has some things I like but misses some things I need.

grafikrobot commented 4 years ago

It seems that every one of these libraries has some things I like but misses some things I need.

If you have specific features you want please add github issues for them. I'm always looking to make this library more functional and easier to use.

eyalroz commented 4 years ago

If you have specific features you want please add github issues for them. I'm always looking to make this library more functional and easier to use.

So, I was hoping for a comparison table - or just a full list of features - to decide whether to try Lyra out. I guess I could just assume everything not in the documentation is not implemented...

But since you made this suggestion: Does Lyra support:

etc.

grafikrobot commented 4 years ago

If you have specific features you want please add github issues for them. I'm always looking to make this library more functional and easier to use.

So, I was hoping for a comparison table - or just a full list of features - to decide whether to try Lyra out. I guess I could just assume everything not in the documentation is not implemented...

Oh, I will definitely make a comparison table.. Will take a while, as in a couple weeks, to compose one. As there's a fair amount of research involved in that. Since most of the argument parsing libs don't already have a nice list of features (I have a list of 12 of them for such a comparison).

But since you made this suggestion: Does Lyra support:

* Initial parsing of arguments which have not been specified? i.e. saving them as strings/vectors of strings for each appearance/bools/vectors of bools?

I don't know what that precisely covers. My gut tells me yes. But without an example I can't be definite.

* Returning the unparsed arguments for further parsing?

No. The information is there are part of internal interfaces though. So it should be fairly easy to add.

* Option groups?

Also not sure what that means concretely.

* Subcommands?

Yes, although not easily at the moment. But I just checked in something that makes it better supported in a test branch: https://github.com/bfgroup/Lyra/blob/c70f4ba16de48bfc90fcc4796306a801b4f11613/examples/doc_commands.cpp

* Receiving its input different than an (int, char**) pair?

Yes, and no :-) Currently it allows for "int, char**" and an "initializer_list". But it's trivial, as in 3 lines of code, to add support for arbitrary sequences. I.e. I'll add that for the next release. What other input are you interested in?

eyalroz commented 4 years ago

Sorry for the belated reply.

Parsing unspecified arguments

Suppose I told the library I have switches a and b and options foo and bar which take an argument. On the command line, I specify:

./my_prog -b -c --foo=123 --quux=456

the library could give up and say "unknown switch 'c'`, or it could say "ok, I've got a switch c, I won't do anything interesting with it but I'll register it as having been specified". An extreme form of this approach is to parse the command-line first, with the only thing you can specify being a flavor of assumptions regarding arguments (e.g. can a two-hyphen option be a switch or must it take an option?) - and then letting the user worry about the parse results.

Note that this direction is the opposite of another useful direction to take parsing in, which is the specification of arbitrary argument type, type-specific parsing, direct storage in a typed argument provided by the user via a reference or a pointer etc.

Option groups

That's for bunching together options when printing the usage information, and giving each group a title.

Other interesting features