Add support for std::span (C++20) #1327
Open
+681
−53
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Main goal of this Pull Request is to add support for converting
glm::vec,glm::matandglm::quatto<span>'sstd::spanbut there are few more changes. The goal is to have a a single non-owning object to access underlying data (similar tostd::string_view).Changes
glm/gtx/span.hppstd::spanfor C++20 (tested with__cpp_lib_span)std::mdspanfor C++23 (tested with__cpp_lib_mdspan) - untested as GCC does not support it right now (see C++23 support list)std::valarrayto have something for older C++ versions, but it copies the underlying datatest/gtx/gtx_span.cpp) inspired bytest/gtx/gtx_range.cppglm/gtx/range.hppto useglm::typefromglm/gtx/type_trait.hppconstexprand[[nodiscard]]glm::typeto get number of elements instead if calculating it just for rangestest/gtx/gtx_range.cpp) to include more typesglm::typefromglm/gtx/type_trait.hppeasier to useelements(calculated ascols*rowsfor convenience)glm::type<glm::vec<...>>did not havecolsandrowsglm::type<glm::mat<...>>still hascomponenets=cols, which is the reason forelementsglm::components<T>(T const&)fromglm/gtx/range.hppas it returnsglm::type<T>::elements(which is previous behaviour)const,volatileand&in type provided toglm::type<...>as those would use the fallback zeroesglm::type<glm::vec3>returns correct values butglm::type<const glm::vec3>does notconstthere by usingdecltypelikeconst glm::vec3 value{}; const auto components = glm::type<decltype(value)>::components; assert(components == 3);GLM_ENABLE_CXX_23GLM_FORCE_CXX23but otherwise works likeGLM_ENABLE_CXX_20GLM_LANG_CXX23_FLAGandGLM_LANG_CXX23inglm/detail/setup.hppI was also thinking about adding concepts but it would not work for older C++ versions. It may be something for future Pull Request as you can use it like
void someFunc(glm::concept::vec auto v)whereglm::vec3andglm::i32vec3would work but notglm::vec2.Missing or problems
std::spanis used asstd::span<T>(with dynamic extent) while it may bestd::span<T,N>std::span<float, 3>as an argument and passglm::vec3but notglm::vec2GLM_ENABLE_CXX_??values so hopefully C++ versions are coveredstd::spantest (test/gtx/gtx_span.cpp) - there are no tests forstd::valarrayandstd::mdspanstd::spansupport)glm::typeshould probably handle theconst,volatileand references correctly without the assertion, but it does not do it now so I feel like it should at least tell you#ifndefin case someone depends on the unintuitive behaviorstatic_assertand other used features did not exist before)DISCLAIMER
This is my first Pull Request to project this big and I am proposing new functionality that, as far as I know, was not requested. There were some guesses from me about how some thing should be done.
I've tried to make it compatible for any compiler and C++ version but I have little experience there as well.
I hope there is no problem with me also changing the
glm/gtx/range.hppheader (and its test) as I feel it is easier to read now.No, this is not a "school project". It is something I found is missing in
glmand took it as a good reason to learn more aboutglm's internals.