-
Notifications
You must be signed in to change notification settings - Fork 67
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
mul(a,b,c) with visual studio 2017 release candidate #5
Comments
As a quick workaround, you can simply delete the
clause, which isn't necessary in C++14. I might go ahead and update the whole library in a bit to rely on C++14 features. Microsoft is claiming that they should have FULL C++98/11/14 compatibility (even two phase lookup!) for the actual release of Visual Studio 2017. GCC and Clang have had it for a couple of years. It's probably time. |
Yes, tested and it works. Just removing the specification of the return leads to successful compilation for code with both 2015 and 2017. Given the compiler deduces the type anyways, this seems to be an acceptable solution rather than just a 'workaround'. Any reason to not simply close the issue? |
It's a breaking change for anyone still compiling with a C++11 compiler, which means I should probably bump the major version number, and if I'm going to declare linalg v3.0 and a dependency on C++14, I kinda want to go ahead and update a number of things. |
One suggestion. You might want to try variadic templates. Worked great on some test code I wrote recently. If you are interested, I can upload a few test cases I wrote on this. |
Looks like somewhere along the way I added an explicit workaround. |
Only hit one snag with visual studio 2017 RC.
With existing projects that worked fine with earlier compiler (20150), I now get the compiler error:
which refers to the following line of code:
This routine is typically used in lines of code that multiply 3 matrices together such as:
As a temporary workaround, i just commented out this implementation of mul(...) and replaced it with a specific one takes 3 float3x3s since that's the only use case i need at the moment.
Sure, that works. However, ideally would rather have a general mul that takes an arbitrary number of matrices of any compatible types. Any ideas? Wait for MS to fix compiler? or is there something that can be reworked within the linalg.h implementation?
note I'm submitting this issue primarily for awareness, this is not an urgent issue for me.
thanks
The text was updated successfully, but these errors were encountered: