iox #1067 create command line parser abstraction

[elfenpiff]

Pre-Review Checklist for the PR Author

1. [x] Code follows the coding style of CONTRIBUTING.md
2. [x] Tests follow the best practice for testing
3. [x] Changelog updated in the unreleased section including API breaking changes
4. [x] Branch follows the naming format (iox-#123-this-is-a-branch)
5. [x] Commits messages are according to this guideline
   • [x] Commit messages have the issue ID (iox-#123 commit text)
   • [x] Commit messages are signed (git commit -s)
   • [x] Commit author matches Eclipse Contributor Agreement (and ECA is signed)
6. [x] Update the PR title
   • Follow the same conventions as for commit messages
   • Link to the relevant issue
7. [x] Relevant issues are linked
8. [x] Add sensible notes for the reviewer
9. [x] All checks have passed (except task-list-completed)
10. [x] Assign PR to reviewer

Notes for Reviewer

Required for the Windows command line feature in the upcoming iceoryx 2.0. This provides the building blocks to replace and unify all the command line parsing algorithms in all applications with a simple struct based interface. With this the requirement for the library getopt.h is removed and we have the same simplistic command line parsing approach on all platforms.

Furthermore, this class provides a lot of error handling, boundary checking etc. which is not present at the moment. Invalid arguments are most of the time only poorly checked and this may lead to crashes. With those classes this should be a problem of the past.

Most likely the command line parser will not become a safety certified class therefore the tests most not perform a MC/DC coverage. Nevertheless I tried to be as diligent as possible.

Checklist for the PR Reviewer

• [ ] Commits are properly organized and messages are according to the guideline
• [ ] Code according to our coding style and naming conventions
• [ ] Unit tests have been written for new behavior
  • [ ] Each unit test case has a unique UUID
• [ ] Public API changes are documented via doxygen
• [ ] Copyright owner are updated in the changed files
• [ ] PR title describes the changes

Post-review Checklist for the PR Author

1. [ ] All open points are addressed and tracked via issues

References

• Closes #1067

[codecov[bot]]

Codecov Report

Merging #1102 (ce7f38f) into master (6a58416) will decrease coverage by 1.70%. The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master    #1102      +/-   ##
==========================================
- Coverage   77.39%   75.68%   -1.71%     
==========================================
  Files         367      375       +8     
  Lines       14248    14566     +318     
  Branches     1992     2072      +80     
==========================================
- Hits        11027    11025       -2     
- Misses       2590     2909     +319     
- Partials      631      632       +1     

Flag	Coverage Δ
unittests	75.35% <0.00%> (-1.70%)	:arrow_down:
unittests_timing	15.33% <0.00%> (-0.35%)	:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...st/include/iceoryx_dust/internal/cli/arguments.inl	0.00% <0.00%> (ø)
...de/iceoryx_dust/internal/cli/option_definition.hpp	0.00% <0.00%> (ø)
...clude/iceoryx_dust/internal/cli/option_manager.inl	0.00% <0.00%> (ø)
iceoryx_dust/source/cli/arguments.cpp	0.00% <0.00%> (ø)
iceoryx_dust/source/cli/command_line_parser.cpp	0.00% <0.00%> (ø)
iceoryx_dust/source/cli/option.cpp	0.00% <0.00%> (ø)
iceoryx_dust/source/cli/option_definition.cpp	0.00% <0.00%> (ø)
iceoryx_dust/source/cli/option_manager.cpp	0.00% <0.00%> (ø)
iceoryx_hoofs/source/concurrent/loffli.cpp	80.00% <0.00%> (-5.72%)	:arrow_down:

[elBoberido]

I can't promise to look at this anytime soon

[elfenpiff]

@elBoberido this is alright ... but I hoped that I maybe can bribe you with coffee, cookies, cake and chocolate.

[elfenpiff]

@elBoberido

Could you please add a small document describing all of this?

You are right this is a pretty nifty idea.

[elfenpiff]

@elBoberido @FerdinandSpitzschnueffler

I feel like this could be split into two PRs, one with the more imperative like API of command_line_parser.hpp and a second one with the macros adding a more declarative like API on top.

Option A If it makes the review process in this stage easier for you I will do this. I would keep this PR open but remove the macro, OptionManager and the tests for the macro. But I fear then only around ~300 lines will vanish from those 3100 lines.

Option B Or I could also go for the following PRs:

1. Design Document
2. CommandLineOptionSet with tests
3. CommandLineArgumentParser & CommandLineOptionValue with tests
4. Macro.

Option C Leave it as it is.

Before I would go for A or B I would incorporate as much of the comments as possible otherwise we will have a hard time tracking them.

What should I do?

[elBoberido]

@elBoberido @FerdinandSpitzschnueffler

I feel like this could be split into two PRs, one with the more imperative like API of command_line_parser.hpp and a second one with the macros adding a more declarative like API on top.

Option A If it makes the review process in this stage easier for you I will do this. I would keep this PR open but remove the macro, OptionManager and the tests for the macro. But I fear then only around ~300 lines will vanish from those 3100 lines.

Option B Or I could also go for the following PRs:

1. Design Document

2. CommandLineOptionSet with tests

3. CommandLineArgumentParser & CommandLineOptionValue with tests

4. Macro.

Option C Leave it as it is.

Before I would go for A or B I would incorporate as much of the comments as possible otherwise we will have a hard time tracking them.

What should I do?

Since this is already quite heavily reviewed, I guess option C would be the best

[elfenpiff]

@FerdinandSpitzschnueffler @elBoberido when you both approved this PR I would not merge it instantly. Then I would go over the history and squash some commits like merge master.

I do not want to rebase and force push until you reviewed everything - to make life easier.

You can also write approved as comment and I start the squashing and then you can approve it properly.

[elBoberido]

You challenged me with the struct size ... now I throw my code in the ring :)

https://gist.github.com/elBoberido/86ec2d69912a47a5ba7cf09acba9de4e

The resulting struct has only 8 bytes of additional data ... on the plus side, the parser front-end is even simpler ... the secret is once again to prefer factories over constructors :)

[elfenpiff]

You challenged me with the struct size ... now I throw my code in the ring :)

https://gist.github.com/elBoberido/86ec2d69912a47a5ba7cf09acba9de4e

The resulting struct has only 8 bytes of additional data ... on the plus side, the parser front-end is even simpler ... the secret is once again to prefer factories over constructors :)

Alright you mastered the challenge! And you inspired me, I used your idea and reduced the base size of the user defined command line struct to 16 - not to 8 like you. The reason is that this command line struct stores by default the binary name which require additional 8 byte since I store the const char *.

This shouldn't pose any problem since argv[0] is valid as long as one is in main (so for the whole runtime).

[flynneva]

@elfenpiff @elBoberido @dkroenke any chance we could get this merged in? Would be super useful elsewhere 😄

[elBoberido]

@elfenpiff @elBoberido @dkroenke any chance we could get this merged in? Would be super useful elsewhere smile

@flynneva with the introduction of iceoryx_dust we have a nice place for code which does not need to fulfill all the strict requirements for code which will be certified. @elfenpiff will continue with the effort to merge this PR