Add a feature comparison with other parser libraries

[eyalroz]

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]

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

[eyalroz]

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

[grafikrobot]

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]

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:

• 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?
• Returning the unparsed arguments for further parsing?
• Option groups?
• Subcommands?
• Receiving its input differently than via an int and char** pair?

etc.

[grafikrobot]

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]

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

• Allowing arbitrary user code (e.g. via lambdas) to be triggered by certain events, in the middle of parsing - which may effect the rest of the parse; i.e. not just custom parsers of strings.
• Aliases for long option names.
• Aliases for switches.
• Ability to only take a typed destination data structures, with the parser determining option names and other settings on its own
• Support for use of std::optional<T>s for options whose argument type is T, with nullopt representing absence
• Support for the use of (arbitrary? fixed-type?) contains for options which may be used multiple times
• Support for string->string sequences/maps/multimaps as inputs
• Support for ini-file-style inputs (i.e. the separator is a newline, all options followed by =)
• Configurable separators