The macro, which is enabled when preprocessing the headers for
single-header libs, excluded the TypeForSize specializations, making
these two not work with Math::gather() and Math::scatter(). It's done
correctly in Vector2 and Color, not sure why not here.
Technically speaking there are many more opportunities to mark things as
C++14 constexpr, such as various operators, but doing so would make them
impossible to optimize with various (SIMD) intrisnics unless basically
providing two separate implementations for them, one scalar, slow and
constexpr and the other fast but not compile time, and dispatching with
std::is_constant_evaluated() or some such from C++20.
In other words, such functions cannot and will not be marked as
constexpr in C++17 or older anyway, because the preference is and still
should be runtime perf rather than doing excessive work at compile time,
where it's hard to debug or reasonably test etc etc., and the more you
rebuild the more you'll hate the cost of extra compile time caused by
that.
Co-authored-by: Stanislaw Halik <sthalik@misaki.pl>
The MAGNUM_GL_ABSTRACTSHADERPROGRAM_SUBCLASS_DRAW_IMPLEMENTATION() and
MAGNUM_GL_ABSTRACTSHADERPROGRAM_SUBCLASS_DISPATCH_IMPLEMENTATION() *is*
documented so that one stays not underscored.
So they can be used in StridedArrayView member function slicing the same
way as the mutable overloads. Pointer, Triple and other low-level
containers do the same thing and this is one of the prime use cases for
the slicing functionality, so it's silly it didn't actually work.
Same as done for Containers::StaticArray some time ago. Since it's not a
potentially dangerous operation, it's not made as an overload of the
from() function, but instead a regular constructor. It's however kept
explicit for now, even though it eventually might not need to be -- I'm
not sure about potential consequences yet.
This complier is making my hair gray. Fortunately the out-of-class
operator doesn't conflict with the in-class one, so it's purely an
additive workaround. Adding extra checks to all subclasses to be sure
this works correctly in all cases and not just in the base class.
Except for a vector and a row matrix multiplication operator, which
doesn't make sense to be a member. These are all now significantly
shorter thanks to not having to repeat that many template parameters,
and they can make use of direct access into the _data array for better
debug perf.
Despite what the standard tries to say. I bet a large portion of
<type_traits> is impossible to implement without it, which is why all
STL implementations define it there already.
I spent a significant amount of time reinventing the wheel, i.e.
figuring out how to use a cross product to calculate distance of a point
to a line. Only to subseqently have a breakthrough discovery of
Distance::linePoint() that actually does the same.
The distance APIs and 2D and 3D cross-products are now linked together
the math snippet is clarified, and both the 2D and 3D distance use the
same equation, saving one unnecessary vector subtraction. The
equivalence of the two equations is listed directly on that Wolfram
link.
The old one is deprecated, and will be removed in a future release.
Unfortunately, to avoid deprecation warnings, all use of NoInit in the
Math library temporarily have to be Magnum::NoInit This will be cleaned
up when the deprecated alias is removed.
And the Vector3 version 5% slower in Release, on GCC at least. FFS,
what was I thinking with the gather() things. Nice in user code,
extremely bad in library code.