Allow subcommands Apps to be extracted and merged

[phlptp]

A bit of background.
I am working on moving to CLI11 from boost::program_options. The main reason being to move away from a dependency on a compiled boost library which was giving us problems in terms of portability.

So CLI11 is what we chose to move to. This required adding some additional capabilities to CLI11 to match the required functionality, We think CLI11 will give us the needed capabilities and quite a few that will ultimately make our code simpler and more capable.

In some of our programs, the command line processing happens in several layers. An outer layer doing some things that build other objects pulling in objects from several different components that are mostly independent of each other, With boost::program_options this mainly meant just passing the command line arguments between all the different options or just passing the resulting parse map to the different options to deal with processing. The nature of CLI11 make this paradigm a little more complicated in some aspects but also opportunities for cleaning things up and simplifying. One needed feature was a way to merge parse options together from various different sources. One option is to pass a main App to the different component to add their own options into, but this means the objects are dependent on some higher level which might not always be the case. So what I want to do is have the component objects build a CLI::App then have a higher level object merge them if it wants to, or the modules can parse options or option strings directly.

I will submit a PR with one option for this in a couple days but I wanted to start a discussion on this and see if there was other things that might be impacted or considered. The idea is basically to replace the unique_ptr storage of subcommands with shared_ptr. Add a set of get_subcommand_ptr functions just like get_subcommand to actually retrieve the shared_ptrs, and an additional function to add a subcommand from a shared_ptr. Closely related is an ability to add nameless subcommands, that behave similarly to groups in some ways basically commands that don't match in the main App fall down to all nameless subcommands. I think this will mean no changes to existing functions, just internal changes and some additional overloads and functionality.

Basically talking about adding two things that will make an ability to modularize the options and App for parsing options.

• ability to extract add, and reuse subcommands
• ability to add subcommands that don't have a name so don't trigger on a subcommand argument but can be triggered from any option that doesn't match in the parent.

[henryiii]

Thank you for the details. Overall, this sounds like an excellent addition.

The choice of unique_ptr was to make it clear that a user was not supposed to gain ownership of a pointer (and, in general, you should use unique pointer wherever it is possible). Moving to shared_ptr is fine with a reason. Accessing the shared pointers should be clear, such as your get_subcommand_ptr function. You could overload the add_subcommand function, or have an add_existing_subcommmand or similar.

The nameless subcommands are fine. It will be interesting to see the composition possibilities this opens up. The help printing might be a little tricky here, as nameless subcommand options probably (?) should be combined with the parent App when printing help.

The most important thing for both additions is some tests that verify that the behavior you expect is tested, this provides examples and ensures that the library doesn't break your use case in the future. An example in the examples folder would be nice too (and most of those run with the tests, too, IIRC).

[phlptp]

Playing with the help printing the most straightforward things seems to be to have them print out similarly to groups since they have their own description, with the exception that positional arguments in the nameless subcommand get printed with the subcommand instead of with the main list of positionals, You could probably make it do otherwise but that would add a number of loops and checks in that part of the code and I was trying to minimize that.

the get_subcommand function needed an overload with an index to be able to get all possible subcommands. (should there be a get_subcommand_count() or something of that nature? )