GLM_FORCE_PURE doesn't work with C++11 after 68c7e7e50b

[johnbeard]

After upgrading to 0.9.9.3 (Arch), code which sets GLM_FORCE_PURE can no longer be built. This includes, for example, KiCad.

Reverting 68c7e7e fixes it. This only occurs with C++11 (i.e. constexpr is available) and if GLM_FORCE_PURE is defined. C++14 works.

Attached is a simple example that doesn't compile.

Sample compilation error:

/usr/lib/ccache/bin/c++    -std=c++11 -o CMakeFiles/glm_test.dir/main.cpp.o -c /home/john/temp/glm-test/main.cpp
In file included from /usr/include/glm/ext/vector_bool2.hpp:5,
                 from /usr/include/glm/vec2.hpp:5,
                 from /usr/include/glm/glm.hpp:116,
                 from /home/john/temp/glm-test/main.cpp:6:
/usr/include/glm/detail/type_vec2.hpp:90:40: error: ‘constexpr const T& glm::vec<2, T, Q>::operator[](glm::vec<2, T, Q
>::length_type) const’ cannot be overloaded with ‘constexpr T& glm::vec<2, T, Q>::operator[](glm::vec<2, T, Q>::length
_type) const’
   GLM_FUNC_DECL GLM_CONSTEXPR T const& operator[](length_type i) const;
                                        ^~~~~~~~
/usr/include/glm/detail/type_vec2.hpp:89:34: note: previous declaration ‘constexpr T& glm::vec<2, T, Q>::operator[](gl
m::vec<2, T, Q>::length_type) const’
   GLM_FUNC_DECL GLM_CONSTEXPR T& operator[](length_type i);

err.txt
glm_test.tar.gz

[johnbeard]

The issue here is a difference in what constexpr means in C++11 and C++14 onwards:

• In C++11, constexpr is an implicit const on non-static member functions (NSMF): C++11/dcl.constexpr:8
• From C++14, you can have constexpr NSMFs that are non-const C++14/dcl.constexpr:8.

So this means that:

glm/glm/detail/type_vec2.hpp

Lines 89 to 90 in ddebaba

	GLM_FUNC_DECL GLM_CONSTEXPR T& operator[](length_type i);
	GLM_FUNC_DECL GLM_CONSTEXPR T const& operator[](length_type i) const;

Becomes, in C++11:

 constexpr T& operator[](length_type i) const;    // const is implicit here
 constexpr const T& operator[](length_type i) const;

Which differs only in return type.

In C++14 onwards, it's OK, there is a a const/non-const to differentiate the two:

 constexpr T& operator[](length_type i);
 constexpr const T& operator[](length_type i) const;

I'm not sure exactly what the logic in setup.hpp should be. I don't think any C++ versions under C++14 should be using constexpr on NSMFs where the only difference between two is const and the the return type (because the const will be implied). How the Intel and VC compilers handle this, I don't know.

glm/glm/detail/setup.hpp

Lines 281 to 288 in ddebaba

	#elif (GLM_LANG & GLM_LANG_CXX14_FLAG)
	# define GLM_HAS_CONSTEXPR 1
	#else
	# define GLM_HAS_CONSTEXPR ((GLM_LANG & GLM_LANG_CXX0X_FLAG) && GLM_HAS_INITIALIZER_LISTS && (\
	((GLM_COMPILER & GLM_COMPILER_INTEL) && (GLM_COMPILER >= GLM_COMPILER_INTEL17)) || \
	((GLM_COMPILER & GLM_COMPILER_GCC) && (GLM_COMPILER >= GLM_COMPILER_GCC6)) || \
	((GLM_COMPILER & GLM_COMPILER_VC) && (GLM_COMPILER >= GLM_COMPILER_VC15))))
	#endif

[walkthetalk]

is there any workaround?

[stef]

is there any workaround?

you could revert 68c7e7e

[johnbeard]

You can also build with C++14 or later or unset GLM_FORCE_PURE (but this may have implications for portability, I think).

[Groovounet]

This issue should be fixed in the master branch for GLM 0.9.9.4 release.

Thanks for reporting

[stef]

thanks for fixing! do you have an estimate when 0.9.9.4 will come out?