Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

illegal storage class in quaternion.hpp #282

Closed
Vectrobe opened this issue Dec 2, 2014 · 5 comments
Closed

illegal storage class in quaternion.hpp #282

Vectrobe opened this issue Dec 2, 2014 · 5 comments
Assignees
Labels
Milestone

Comments

@Vectrobe
Copy link

Vectrobe commented Dec 2, 2014

as the title suggests, if said file is included in any way GLM will not compile, couple examples being glm\ext.hpp and glm\gtc\type_ptr.hpp, either files have to be modified to not include the header

error C2071: 'glm::tquat<T,P>::operator glm::tmat3x3<T,P>' : illegal storage class glm\gtc\quaternion.hpp 116
error C2071: 'glm::tquat<T,P>::operator glm::tmat4x4<T,P>' : illegal storage class glm\gtc\quaternion.hpp 117

@Groovounet
Copy link
Member

With wish compile do you have thus issue?

@Vectrobe
Copy link
Author

Vectrobe commented Dec 2, 2014

VS110 C++11 x86-64

@plasmacel
Copy link

Explicit conversion operators are an unsupported C++11 feature in MSVC11 (Visual Studio 2012).
See http://msdn.microsoft.com/en-us/library/hh567368.aspx

Sorry at the time of the commit I didn't try it with previous MSVC versions. However it is a core C++11 feature, it seems Microsoft only adapted it in Visual Studio 2013.

After a short research: it is supported by and above Visual C++ 2013 (MSVC12), GCC 4.5, Clang 3.0 and Intel C++ Composer XE 13.0.

We should release something like a 0.9.6.1 hotfix and enable this feature with some macro predefinition like GLM_FORCE_CPP11 for the present.

@Groovounet
Copy link
Member

Thanks for the research!

I have a GLM_HAS_{CPP_FEATURE} mechanism that I am going to us for this feature to resolve the problem for GLM 0.9.6.1.

Thanks for contributing,
Christophe

@Vectrobe
Copy link
Author

Vectrobe commented Dec 3, 2014

general rule of thumb is to not use experimental language components without at least researching it's support for compatibility, if you want or need to have such features it's a good idea to have them in a second branch of which you could merge to the main when it has adequate support.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants