Container options

[phlptp]

If merged this pull request will generalize the types that can be used in add_option to any container.

A container in this case is any type with a value_type member and iterator member, anend() method, a clear() method, and an insert method. This supports all the standard containers, though not stack, or queue since they don't support an insert operation. Should support most other containers as well if they have a similar interface to the standard library ones.

Also support any type with a value_type defined. And supports complex number type (any type with real(), and imag() methods directly in add_option.

One other change is updated google test v1.10.0 to better support templated tests and match the current documentation for google test, so we don't have to figure out where old docs are for getting google test to work.

[phlptp]

Todo:

• test with some boost containers
• make work with something like std::map<std::string, std::pair<int,int>>
• handle the general wrapper types in the type conversion
• remove the vector specific operations
• adjust the priorities for int_constructible and double_constructible classification types
• update readme
• update the book chapter on options to match current master
• get compiling on all tested compilers
• 100% coverage
• merge commits and write a summary commit message

[codecov]

Codecov Report

Merging #423 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master   #423   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files          12     12           
  Lines        3583   3668   +85     
=====================================
+ Hits         3583   3668   +85

Impacted Files	Coverage Δ
include/CLI/Option.hpp	100% <100%> (ø)	⬆️
include/CLI/App.hpp	100% <100%> (ø)	⬆️
include/CLI/StringTools.hpp	100% <100%> (ø)	⬆️
include/CLI/TypeTools.hpp	100% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 967bfe0...063db93. Read the comment docs.

[phlptp]

@henryiii this is getting closer to being ready to go. I am still working on the readme and book probably for a couple days yet.

Had a few questions though. With this PR complex numbers(without requiring the <complex> header be added) are supported directly in add_option. So we can deprecate add_complex, but I wasn't sure if this was something we wanted to do now or in perhaps a later PR.

To handle some options nicely like vector<vector<X>> some sort of user specified segment separator needs to be defined to be able to separate sections on the command line. I was thinking && but I don't have a strong preference.
for examples

--vec 1 2 4 7 && 3 5 --other A

would create a vector with two element vectors one with 4 element and 1 with 2. But I am not sure if && is the best or something else would be better.

[jzakrzewski]

@phlptp Maybe rather something that does not require quoting in standard shells?

[phlptp]

@phlptp Maybe rather something that does not require quoting in standard shells?

That is a very good point that I had not been considering thus far.

[phlptp]

So looking at a list of bash special character
would indicate &~#$*()\{}{};<>/?! would probably not be used since they have different interpretations in shell scripting

That could mean something like %% might work, a single + might work, ++ is used as a subcommand terminator so wouldn't work in this context. # or ## might be possible since this would never begin a line and thus wouldn't be considered a comment line

[phlptp]

I think I am leaning towards %% as a separator for subvector elements. That doesn't seem to be used anywhere else or have meaning in command line contexts.

[jzakrzewski]

Bash, and Windows CMD seems to be OK with that.

BTW: # does not have to be at the beginning of the line to start a comment in bash.

[henryiii]

I don't see any major issues; we can polish a little as we go if needed, but over all looks very good.