It worked flawlessly when crosscompiled from Linux, but compiling that
natively causes the linker to loudly complain about undefined references
to ConfigurationValue structs. I think it worked well under 4.9.2 (but
that mess had a slew of other ugly problems, such as complete inability
to produce non-crashing C++11 code under x64). The linker error is
caused only because I tried to reduce binary bloat, so I'm just
disabling that for MinGW and screw that. No problem under MSVC.
Useful for squeezing out last bits of performance, e.g. in this case:
Vector3 a;
a[0] = something++;
a[1] = something++;
a[2] = something++;
In the code all elements are first zeroed out and then overwritten
later, thus it might be good to avoid the zero-initialization:
Vector3 a{Math::NoInit};
a[0] = something++;
a[1] = something++;
a[2] = something++;
This will of course be more useful in far larger data types and arrays
of these.
Some classes are by default constructed zero-filled while other are set
to identity and the only way to to check this is to look into the
documentation. This changes the default constructor of all classes to
take an optional "tag" which acts as documentation about how the type is
constructed. Note that this result in no behavioral changes, just
ability to be more explicit when writing the code. Example:
// These two are equivalent
Quaternion q1;
Quaternion q2{Math::IdentityInit};
// These two are equivalent
Vector4 vec1;
Vector4 vec2{Math::ZeroInit};
Matrix4 a{Math::IdentityInit, 2}; // 2 on diagonal
Matrix4 b{Math::ZeroInit}; // all zero
This functionality was already present in some ugly form in Matrix,
Matrix3 and Matrix4 classes. It was long and ugly to write, so it is
now generalized into the new Math::IdentityInit and Math::ZeroInit tags,
the original Matrix::IdentityType, Matrix::Identity, Matrix::ZeroType
and Matrix::Zero are deprecated and will be removed in the future
release.
Math::Matrix<7, Int> m{Math::Matrix<7, Int>::Identity}; // before
Math::Matrix<7, Int> m{Math::IdentityInit}; // now
It is often annoying to write e.g. this, especially in generic code:
T dot = Math::Vector<size, T>::dot(a, b);
When this is more than enough and the compiler can infer the rest from
the context:
T dot = Math::dot(a, b);
There are more downsides and confusing cases (you can call
Math::Vector<3, T>::dot(), Math::Vector3<T>::dot() and Color3::dot() and
it is still the same function), so I made these as free functions in
Math namespace. You can now also abuse ADL for the calls, but I would
advise against that for better readability:
T d = dot(a, b); // dot?! what on earth is dot? and what is a?
The only downside found when porting is that you need to specify the
type somehow when having both parameters as initializer lists:
T d = dot({2.0f, -1.5f}, {1.0f, 2.5f}); // error
T d = dot(Complex{2.0f, -1.5f}, {1.0f, 2.5f}); // okay
But that's probably reasonable (and it's also highly corner case,
the functions were used this way only in tests).
The original static member functions are of course still present, but
marked as deprecated and will be removed at some point in future.
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
Vladimír Vondruš