I thought I went over all these several years ago already, but
apparently not or maybe back then not all websites were HTTPS-ready. Now
they mostly are, except for maybe one or two.
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>
And for the new half-float literals add a deinlined variants. I know,
it's worse than having it inline, but you're already suffering by using
this compiler at all so it doesn't make it that much worse.
Unlike _rgb and _rgbf these are not constexpr, but I'll eventually add
table-based constexpr variants into a new ConstexprLiterals namespace
for all sRGB and half-float variants.
Improve related links for the literals, and don't say "calls" because it
doesn't do that anymore, and it'd imply it inherits the same issues with
not checking for hexadecimal colors or not checking length.
This means I don't get the parsed number as an integer but have to parse
it myself from individual chars, on the other hand it allows me to check
that it's indeed hexadecimal and has correct length, because writing a
24-bit color literal with _rgbaf, or forgetting one digit, etc. was a
common source of accidental bugs.
The new code is larger and more complex, so I verified that it doesn't
have too large effect on compile times. On GCC the MathColorTest built
in ~1.20 seconds before and ~1.25 after, on Clang it was 1.24 vs 1.26.
So there's a minor increase, but it's small enough to warrant the
increased robustness. In total, the whole codebase with tests builds in
~120 seconds both before and after, so I suppose unless the codebase
consists of just color literals alone (which could be the case for e.g.
some stylesheets), it's completely fine.
And it found bugs in some test code already. Fix for those is in next
commit.
The original behavior was extremely imprecise. I remember hitting this
in the UI library, where it was happily telling me that a vector is
zero, and I spent ages debugging only to replace it with an equality
comparison that behaved correctly. Let's fix that properly.
I think I tried this at least once in the past already, and failed the
same way. So just document that it's missing to prevent me from wasting
time on this again in the future.
The MAGNUM_GL_ABSTRACTSHADERPROGRAM_SUBCLASS_DRAW_IMPLEMENTATION() and
MAGNUM_GL_ABSTRACTSHADERPROGRAM_SUBCLASS_DISPATCH_IMPLEMENTATION() *is*
documented so that one stays not underscored.
Am I overdoing it? Most unpremultiplication code I found doesn't even
deal with treating alpha being zero correctly, while here I'm handling
also the cases of RGB channels going over alpha, and for packed
formats trying to match precision of the same done with pack()/unpack().
The equations were using some strange undefined `a` which made it look
like it's dealing with alpha. Just turn that into a constant like
Wikipedia does, and link there as well. Additionally, one of the `c`'s
wasn't correctly a lowercase bold vector.
Similarly as done in Aug 2024 in Corrade. When these were a part of the
function signature, they ended up being encoded into the exported
symbol. There are still cases of StridedArrayView slice() having
enable_if in the signature, which amounts to about 18 kB symbols in all
libMagnum*-d.so libraries, but apart from that this is the state before:
$ strings libMagnum*-d.so | grep enable_if | grep -v slice | wc -c
29591
And this is after. All of those are coming from STL, thus from
old or deprecated APIs that still use std::vector, std::tuple and such,
and from the few std::sort() uses.
$ strings libMagnum*-d.so | grep enable_if | grep -v slice | wc -c
4103
In a non-deprecated build it's just this, which is a 10x reduction.
Can't really do much about these maybe exceút for implementing my own
swap() specializations (sigh?), but I think it's fine.
$ strings libMagnum*-d.so | grep enable_if | grep -v slice | wc -c
2904
I also made it consistently use
typename std::enable_if<..., int>::type = 0
instead of
class = typename std::enable_if<...>::type
because the former works correctly also in presence of overloads and
having it used consistently everywhere makes it easier to grep & change
later. All SFINAE is now also excluded from Doxygen output, because it
doesn't make much sense there. It's better to just explain the
restriction in words than with this nasty hack.
They're not parsed since 6b22a11170
(2020), so there's no point in keeping those workarounds. They're only
kept in utility application sources as they're parsed for pages, and in
tweakable implementations where it's easier to just copypaste the whole
ifdef expression from the header every time instead of modifying it to
not include DOXYGEN_GENERATING_OUTPUT.
Because that apparently cannot work without #include <initializer_list>,
and even though that particular include is maybe just 30 lines, I refuse
to do that because it'd soon make the MagnumMath.hpp single tip over 10k
preprocessed lines again.
Fuck you, C++.
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.
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.
Vladimír Vondruš