-
Notifications
You must be signed in to change notification settings - Fork 353
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Type size refactor #325
Type size refactor #325
Conversation
This is getting closer but wanted to see the coverage and let people start taking a look. |
Codecov Report
@@ Coverage Diff @@
## master #325 +/- ##
======================================
Coverage 100% 100%
======================================
Files 12 12
Lines 3186 3331 +145
======================================
+ Hits 3186 3331 +145
Continue to review full report at Codecov.
|
Please rebase and force-with-lease, please. CI should be fixed. You might need to run pre-commit, but unlikely. |
ac30471
to
a2ef17d
Compare
clang tidy is not exactly intuitive what was going on there. It is a nice check but it would be helpful if the actual warning was displayed along with the code, not sure if that is possible or this was a diff of some kind. |
I think clang-tidy should print info messages while it builds, then the check that fails is just a diff. So if you look back in the build log, you should see a reason, I think. |
Yeah I guess it does, I was just looking at the step that showed the failure didn't occur to me to check the build for the warning. I should look into how you did that, might be useful to some of our other projects. |
a427b1e
to
034de9f
Compare
The basics of this PR are working through the details of isolating type size and expected size and allowing them to have a min and max independently. In doing so this addresses #330, #322, and #296, and gets at #257, though I think with a little more work it might be possible to handle that without specifying the template arguments on add_option. That will have to wait for a while though. There is also probably better treatment of #305 in this PR. There was some slightly odd behavior left in place to make sure it was consistent with previous behavior, that might be able to be taken out in a 2.0 release if desired. |
…y number to be entered for the min and max and don't make a distinction between flags and other types.
…ome typename keywords
…al<std::vector<X>> is supported using the full template of add_option.
…d value which would otherwise be empty
… to parsing state.
cc76c94
to
1ab5e5b
Compare
If merged this PR will refactor the type_size and expected size and the multiOptionPolicy so they work independently and allow more flexible types in add_option.
Also rework add_complex to actually allow things like
--comp 4+2i
or--comp -1.7-5j
in addition to the current pair of doubles support.