.length() functions in types are confusing with length(x) functions.

[Groovounet]

Add GLM_FORCE_SIZE_FUNC to use size_t size() instead of length_t length().

[richardeakin]

I noticed that some function implementations are using the length() method (such as here). Won't this cause compile errors if GLM_FORCE_SIZE_FUNC is used, making length() undefined?

Apologies for the noise if you're already aware, and thanks again for change.

[Groovounet]

Damn, stupid overlook.
I'll fix it.

[Groovounet]

This should be fixed.

Thanks for reporting,
Christophe

[richardeakin]

Awesome, nice solution.

[richardeakin]

Sorry to be the carrier of bad news always, but I found some other places that are still directly using length(), they look to be mainly in the debug asserts, which are using it like this->length().

/Users/r/code/graphics/glm/glm-git/glm/detail/type_vec2.inl:58:30: error: no member named 'length' in 'glm::tvec2<unsigned int, 0>'
                assert(i >= 0 && i < this->length());
                                     ~~~~  ^
...

Other thing is, is there any way to make use of some of the tests with this flag on? I see .length() is used in there, but then you possibly don't want to use detail::component_count(x) directly in the tests..

[Groovounet]

It should be fixed now, until the next one (:p), and I have added a test.

Thanks,
Christophe

[nickeb96]

fyi you will have issues with vec.length() and length(vec) in C++17 when the uniform call syntax is implemented.