To reproduce, add the following registration to vdb_print/main.cc:
openvdb::Grid<openvdb::tree::Tree4<openvdb::Vec3H, 4, 3, 3>::Type>::registerGrid();
This will fail to build with a no match for operator+ error on GCC 7.3.1 but building with Clang 16 reveals more information:
openvdb/openvdb/math/Vec3.h:540:43: note: candidate template ignored: requirement 'std::is_arithmetic_v<openvdb::v11_0::math::internal::half>' was not satisfied [with S = float, T = openvdb::v11_0::math::internal::half]
inline Vec3<typename promote<S, T>::type> operator+(const Vec3<T> &v, S scalar)
This appears to be due to #1688 because of the enable_if because std::is_arithmetic is true for a hardcoded list of system types that does not include half.
I've attempted to come up with a fix, but I've ran into two issues so far. Specializing std::is_arithmetic is undefined behavior, so we'll need to define an alternative template check. Secondly, this would create a circular dependency of sorts between Math.h and Types.h, since the latter is where the half type, either internal to OpenVDB or externally imported from Imath, is defined.
To reproduce, add the following registration to vdb_print/main.cc:
openvdb::Grid<openvdb::tree::Tree4<openvdb::Vec3H, 4, 3, 3>::Type>::registerGrid();
This will fail to build with a
no match for operator+
error on GCC 7.3.1 but building with Clang 16 reveals more information:This appears to be due to #1688 because of the
enable_if
becausestd::is_arithmetic
is true for a hardcoded list of system types that does not include half.I've attempted to come up with a fix, but I've ran into two issues so far. Specializing
std::is_arithmetic
is undefined behavior, so we'll need to define an alternative template check. Secondly, this would create a circular dependency of sorts betweenMath.h
andTypes.h
, since the latter is where thehalf
type, either internal to OpenVDB or externally imported from Imath, is defined.