The MAGNUM_GL_ABSTRACTSHADERPROGRAM_SUBCLASS_DRAW_IMPLEMENTATION() and
MAGNUM_GL_ABSTRACTSHADERPROGRAM_SUBCLASS_DISPATCH_IMPLEMENTATION() *is*
documented so that one stays not underscored.
Compared to Corrade, the improvement in compile time is about a minute
cumulative across all cores, or about 8 seconds on an 8-core system (~2
minutes before, ~1:52 after). Not bad at all. And this is with a
deprecated build, the non-deprecated build is 1:48 -> 1:41.
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.
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>
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.
The perf cost is just too great for these to be enabled always. The only
place where the assertions are kept always is in the batch APIs -- there
it's assumed the function is called on large enough data to offset this
overhead, plus since it's often dealing with large blocks of data the
memory safety is more important than various FP drifts which were the
usual case why other assertions were firing.
Certain Clang-based IDEs (CLion) "emulate" a compiler by inheriting all
its defines, which means one gets __clang__ defined but also __GNUC__
set to 11 or whatever, breaking all these assumptions.
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.
I don't know why, but marking the output of copy constructor of any
subclass or output of conversion operator of any class as constexpr
causes MSVC to complain about non-constant expression.
Probably just another bug.
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.
Vladimír Vondruš