As we are now using absolute includes, there is no need to prefix
everything with "magnum<Namespace>" etc. All generated configuration
files are renamed to configure.h and their path is included _before_
everything else to avoid accidental collisions.
The only places where they aren't absolute are:
- when header is included from corresponding source file
- when including headers which are not part of final installation (e.g.
test-specific configuration, headers from Implementation/)
Everything what was in src/ is now in src/Corrade, everything from
src/Plugins is now in src/MagnumPlugins, everything from external/ is in
src/MagnumExternal. Added new CMakeLists.txt file and updated the other
ones for the moves, no other change was made. If MAGNUM_BUILD_DEPRECATED
is set, everything compiles and installs like previously except for the
plugins, which are now in MagnumPlugins and not in Magnum/Plugins.
The pointer conversion can be done only explicitly, thus the users will
always know what they are doing. With that change, perfectly valid
things like this couldn't be done (the result of a + b is kept until the
semicolon):
Vector3 a, b;
void foo(float* data);
foo((a + b).data());
Moreover this conversion wasn't even properly tested, leading to issues
as in mosra/corrade@781f5df38a7b1b366f3de477dd5fe641eca6ed20.
This reverts commit add989703e.
No Vector<size, T> and std::initializer_list versions yet, as the
algorithm for it is pretty complicated and I'm not sure that they will
be used frequently enough to deserve their existence.
There are more cases that should be fixed, but this is the most
problematic one, as this might look completely innocent:
Vector2 a, b;
float* c = (a + b).data();
Unlike this, which looks suspicious:
Vector2& c = a + b;
Operators that are part of Vector are operating only with the same type
as Vector itself, operators for multiplying/dividing integral vectors
with floating-point numbers and vectors are now out-of-class and enabled
only for integer vectors. It allows better control (e.g. multiplying
integer and floating-point vector will _always_ result in floating-point
one). Thoroughly tested integer/FP operations and also reworked and
tested operator and funciton reimplementations in subclasses, both for
value correctness and result type correctness.
Also fixed unary RectangularMatrix::operator-() and Vector::operator-()
documentation (was stating that the operation is done in-place, which is
impossible.
First, removed functions which can be done with Vector's member
functions and functions from Functions.h. More flexibility and less
redundant code which leads to easier SIMD implementation later.
Vector4 a;
Float b = a.maxAbs(); // before
Float b = Math::abs(a).max(); // now
Second, removed all functions from RectangularMatrix which are
implemented in Vector and added conversion from RectangularMatrix to
Vector and back. Also for more flexibility and less redundant code (i.e.
reusing SIMD-optimized Vector::max() instead of writing it again).
Matrix4x3 a;
Float b = a.max(); // before
Float b = a.toVector().max(); // now
Comparing squared length to 1 is not sufficient to compare within range
[1 - epsilon, 1 + epsilon], as e.g. Quaternion with dot() = 1 + 1e-7
when converted to matrix has column vectors with dot() = 1 + 1e-6, which
is just above 1 + epsilon. Thus it's needed to compare sqrt(dot()) in
range [1 - epsilon, 1 + epsilon] or dot() in range [1 - 2*epsilon +
epsilon^2, 1 + 2*epsilon + epsilon^2]. Because epsilon^2 is way off
machine precision, it's omitted, thus dot() in all isNormalized()
implementations is now compared this way:
abs(dot() - 1) < 2*epsilon;
As there is no Magnum::TypeTraits struct anymore, there is no need to
have redundant name in it. Hopefully Doxygen will handle the difference
between this and Corrade's TypeTraits.h properly.
Square matrices already had that, (dual) quaternions too, making that
the default also with complex numbers. Updated the documentation to
reflect that.
It is now possible to implicitly create one-element Vector and also
explicitly fill more-element Vector with one value without any ambiguous
overload conflicts:
Vector<1, int> a1 = 1; // calls implicit constructor
//Vector<3, int> a3 = 1; // error!
Vector<1, int> b1(1); // still calls the implicit constructor, the
// explicit is disabled for one-element vector
Vector<3, int> b3(1); // calls the explicit "filling" constructor,
// the implicit is disabled for only one argument
The downside of this is that now specifying improper element count in
constructor doesn't lead to static_assert with human readable error, but
rather cryptic "no match" error.
Vladimír Vondruš