Visual Studio 2015 with Update 1 complains in build of the current master branch. It seems VS2015 fails to evaluate a function pointer to a constant.
Here is the error message.
C:\projects\dart\dart/dynamics/Addon.h(63): error C2131: expression did not evaluate to a constant (compiling source file C:\projects\dart\dart\dynamics\BallJoint.cpp) [C:\projects\dart\build\dart\dart-core.vcxproj]
yes, i ran into this too. it seems like the most likely cause of this is the constexpr static declarations in addon.h. apparently vs2015's support of constexpr is evolving. notice the link below :
particularly the looking forward section, where they say there are still numerous bugs remaining, some of which pertain to pointers-to-members in constant expressions.
So sad VS2015 hasn't completed constexpr yet. I hope the next update fix this, and it's before DART 6.0 release.
i know, it's unfortunate how long it's taking them to become compliant with the standard.
are there any plans to address this?
I don't think there is a way to address this unless VS2015 fixes the bug. One possible way could be not using constexpr, but it is now required feature for DART 6.0 since #531.
Please note that this is an issue for the current master branch (that will be DART 6.0) but not for DART 5.1 or less.
this isn't an issue with 5.1 so i guess we can close it, although 5.1 has other problems (Eigen alignment assertions).
The Eigen alignment issue should be addressed by #606.
I would like to leave this issue open to inform this to other users. Someone who tries to build master branch with VS2015 might want to know about this.
Excellent! Thanks JS.
I hope the constexpr issue is addressed in VS2015 Update 2 CTP.
oh, goody. i'll test it.
The issue seems not resolved yet. I still get the same errors.
Visual Studio 2015 Update 2 still can't build with constexpr for function pointers.
If this is becoming a problem, it may be possible to block out those expressions for Visual Studio, and avoid using them in code. Their original purpose was to enable us to use some macros for implementations of classes derived from Addon, but my new implementation (currently being called Aspect) almost completely eliminates the use of those macros.
I should be dropping a huge pull request tomorrow with the new Aspect implementation. To be honest, though, Visual Studio isn't known to be great with templates, and the Aspect implementation is extremely template heavy, so we might end up eliminating one problem while introducing a dozen new ones. I'll start testing the implementation in VS as soon as it's finished.