modified option template #285
Conversation
|
looks like some issues with the single_file generation due to commenting out some code in Optional.hpp. I will fix it later if this is a useful direction. |
|
I think this is a good direction to go. I was beginning to think about ways to remove the explicit inclusion of the optional. |
Codecov Report
@@ Coverage Diff @@
## master #285 +/- ##
==========================================
- Coverage 100% 99.75% -0.25%
==========================================
Files 12 12
Lines 2880 2892 +12
==========================================
+ Hits 2880 2885 +5
- Misses 0 7 +7
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #285 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 12 12
Lines 2887 2928 +41
=====================================
+ Hits 2887 2928 +41
Continue to review full report at Codecov.
|
|
I think this is working mostly how I intended now. Got into some strange corners with different compilers. As near as i can figure Gcc allows narrowing conversions using {} syntax in some circumstances, other compilers do not. Which isn't necessarily a big problem since it wasn't supposed to in template code, but for certain compilers gcc <5.0 and gcc 7 in C++17 it issued a warning in unevaluated context. I haven't traced this yet but since it was fixed in later compilers I am assuming it was a bug of some sort. Now also ran into some issues with visual studio 2015 and the type_trait is_assignable, so that led to some "interesting" issues with some peculiarly designed classes to them which explicitly deleted all constructors and assignment operators but some particular ones. So in VS2015 it was saying things were assignable but then when you actually tried the assignment it would generate a compile errors. Which kind of made the trait not so useful. I tried making some different forms of the assignable trait but it must be something with the compiler cause whatever I tried did the same thing. So in the end I just disabled the tests for VS 2015 and earlier. I don't actually think this affects the actual usage much since it is pretty strange classes that trigger it, that were designed to target very specific overloads. In actual code it would be pretty easy to work around. |
|
@henryiii I think this is ready for review. |
include/CLI/TypeTools.hpp
Outdated
| // Check for streamability | ||
| // Based on https://stackoverflow.com/questions/22758291/how-can-i-detect-if-a-type-can-be-streamed-to-an-stdostream | ||
|
|
||
| template <typename S, typename T> class is_streamable { | ||
| template <typename SS, typename TT> | ||
| template <typename T, typename S = std::ostringstream> class is_streamable { |
There was a problem hiding this comment.
Should we rename this to is_ostreamable?
… some notes about it in the README.md remove the test from visual studio 2015 vs2015 doesn't seem to properly deal with is_assignable in the cases we care about so make a standalone version that is more direct in what we are doing add version to appveyor and add some notes to the readme fix a few test cases to make sure code is covered and test a few other paths remove unneeded enum streaming operator add some diagnostic escapes around trait code to eliminate gcc Wnarrowing warnings work specification of the template operations remove optional add some templates for options conversions add the two parameter template for add_option
henryiii
force-pushed
the
option_template
branch
from
0c024df
to
3cd5c1e
Compare
|
Rebased. It looks like the |
|
I guess there are a few oddities about appending string_view to a std::string, It compiles now on visual studio with C++17 and on gcc 9 at least in MSYS now. |
henryiii
force-pushed
the
option_template
branch
from
81a7813
to
44349e3
Compare
|
This almost works if you remove the special string_view patch. Except on GCC 9. Any ideas? |
|
I think I fixed it. had to convert lexical cast to take a const std::string & instead so it wasn't converting a temporary variable to a string_view. Out of curiosity I tried making the value a string_view for add_option. It compiled fine but doesn't work, since the input vector of strings to the callback is constructed on the fly as is deleted soon after, so that will never work. though I do believe the |
…to allow string_view in a few cases
This PR modifies one of the add_option templates allowing two template parameters to allow direct specification of the conversion type if it is not desired to be the same as the assignment type.
For example if you were assigning to variant, you could specify the assignment as a string, int, double, enum, etc.
Also add overloads of lexical cast for types which can take assignment from double or int.
What this would allow is the complete removal of any mention or inclusion of optional from CLI11, and still maintain support for optional types.
Optional<string>optional<double>oroptional<int>all work with no additional code, and other optional types can be made to work using the two parameter template as long as the underlying type has a lexical cast conversion.@henryiii Not sure if this is a direction you want to take, but it could completely get rid of a file and add some additional capabilities that we have used in our applications.
If you think it a good direction I will add some more tests to make sure everything works as advertised with the two parameter template.