To allow people to cherry-pick just a subset of them if other code
defines literals that may conflict. I first did that the same way as
STL (so both namespaces inline), only to subsequently discover the
horror that all literals are implicitly available in the enclosing
Math namespace, thus preventing no conflicts at all. So the Literals
namespace isn't getting inline, only the inner ones.
This is also in preparation for introduction of
Literals::ConstexprColorLiterals that would provide a constexpr variant
of the _srgbf literals at the expense of having a large LUT in a header
file.
Need to make a constexpr style data for the UI library and it involves
various multiplications and such, so took that as an opportunity to
enable constexpr on all operators. No other functions such as max() so
far, as I don't really need those yet.
After a few abandoned iterations that involved adding constexpr
overloads only to the Vector2, Vector3 and Vector4 subclasses I ended up
with a rather minimal solution that makes the base Vector constexpr
already, and just about 50 extra lines in total.
In the original code from 2010, to avoid redundant code, the const
operations were delegating to compound assignment operations, i.e.
operator*() being implemented by making a copy of itself and then
delegating to operator*=(). Thus, as far as a Debug build is concerned,
one extra indirection for each. The new solution is *also* one
indirection (which is needed in order to expand the variadic sequence)
so it's not worse in Debug in any way, however it's one indirection less
in the Vector2, Vector3 and Vector4 subclasses as there it delegates
directly to the internal implementation instead of the base class
operator. On GCC at least, there's no measurable impact on build times
either -- the whole project builds in ~2:22 both before and after this
change.
The way the change is done also allows the new code to be compiled out
if C++14 constexpr is enabled, where the functions would simply delegate
to the compound assignments. I'm not planning to touch that any time
soon either.
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.
In particular verify also the compound assignment operators and that
they correctly return a reference to self. And make sure the
non-mutating operators can be called on const instances.
The tests were mostly written back in 2010 and it shows. It survived all
that time because I didn't need any larger refactor of the math library
until now, but I'm going to make some changes and it'll be embarrassing
to introduce nasty regressions because the test coverage was lacking.
For some reason a lot of these got forgotten in
b2c353bf21. Also adding a comment
explaining the difference, because it's likely to stop being obvious few
months from now.
Also adjusting two tests which were calling rotation() on matrices that
actually didn't have a correct rotation part, and it only slipped
through because of the bug in isOrthogonal().
Co-authored-by: John Turner <7strbass@gmail.com>
Need them for the UI. Will eventually need the sRGB literals too, not
sure what to do there yet, std::pow() is only constexpr in C++26. I'll
be probably long retired when *that* version becomes the min spec for
Magnum.
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.
There's Containers::Triple now for this instead. Printing a message to
Error in case of a failure might have made sense back in 2010, but now
it absolutely doesn't, so it's additionally wrapped in an Optional now.
Also looks like the actual use without "convenient" std::tie() is a lot
less verbose. Haha.
Using Containers::Pair allows me to make certain Range APIs constexpr
that weren't possible in C++11 before. Compared to std::pair it's also
trivially copyable, which is a nice property when storing it in various
growable containers.
As usual, the <Corrade/Containers/PairStl.h> include is in place to help
people with porting, although in many cases this change will be
breaking. I had to do it at some point anyway, so the earlier it is the
better.
Instead of defining the same types and vaguely risking little
differences. Typedefs that don't exist in Magnum.h (such as integer
quaternions) and typedefs that differ from Magnum.h (such as
using Vector<4, T> instead of Vector4<T>) stay as typedefs, to make it
clear what *deliberately* differs and what not.
Typedefs that didn't conflict with the template types in Math (such as
Vector3us) are removed entirely, as the typedef from Magnum.h can be
used directly in that case, without any `using`.
I did this back in 2010 because it "felt like the right thing to do",
given that all of Magnum depended on Math and not vice versa. But,
strictly speaking, Math already uses typedefs from Magnum/Types.h so why
it couldn't also bring in the Corrade namespace, and the
Debug/Warning/Error names too. Having to type out Corrade:: in all these
was really just a waste of time, weird inconsistency in docs and an
extra roadblock for whoever might want to contribute anything there.
Partially needed to avoid build breakages because Corrade itself
switched as well, partially because a cleanup is always good. Done
except for (STL-heavy) code that's deprecated or SceneGraph-related APIs
that are still quite full of STL as well.
It should be returning twice the value, this is the half-angle. Sad that
this went unnoticed for so long, extra bad points for me to have a
complicated test but not actually verifying that the returned value
makes sense, sigh.
A *nasty* option would be to just fix it, but -- even though there's a
chance nonbody ever used it since nobody ever complained -- it would
introduce breakages to any code that fixed it and that's something to
definitely not do in a trusted codebase. So it's instead deprecated,
firing an annoying warning to whoever might have called it, and there's
a (temporary) replacement called halfAngle() that does exactly the same
but is named appropriately.
Then, once the deprecated angle() is removed (the usual deprecation
period, so a year or the span of two releases, whichever takes longer)
and enough time passes (so another year at least), I'll reintroduce it
with a correct return value.
Vladimír Vondruš