Add constexpr and boost::variant workarounds for vs2015. #772
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If you see our regression tests it looks like the majority of them compiles with VS2015:
https://www.boost.org/development/tests/develop/developer/geometry.html
Therefore I checked how much effort would it take to make all of them to compile. It seems that it was not much. VS2015 doesn't have full
constexprsupport andboost::variant's is implemented using dummy template parameters instead of parameter pack.For
constexprit was sufficient to disable it in some places and add explicitly initialize class member in other.In order to analyze types of
boost::variantI decided to not use Boost.MPL as it was before but instead to check raw template parameters, i.e. to check if they are geometries or not. This works for both dummy parameters and types that are not geometries. And while currently non-geometries are not supported in other places of the library we could consider supporting them. An example would be something like:Right now this code would not compile. At least I think it would not. But I don't see a semantic reason why it shouldn't. So in the future we could consider expanding the change done in this PR to the whole library.
What do you think about these workarounds?
Does it make sense to support vs2015?