Using a tuple was very useful, helpful and exciting as I had to make an
explicit comment about what element is what, and then having to remember
the order in all places that accessed the tuple.
Using a struct however is rather boring as the fields are just named
there, I don't need any complex std::get<4>() and extra comments
explaining what is where and it's just not so adventurous anymore. The
build time of a non-deprecated MagnumGL library also dropped from 5.9
seconds to 5.85. SAD!
All the tests were updated to explicitly check that non-null-terminated
strings get handled properly (the GL label APIs have an explicit size,
so it *should*, but just in case). Also, because various subclasses
override the setter to return correct type for method chaining and the
override has to be deinlined to avoid relying on a StringView include,
the tests are now explicitly done for each leaf class, instead of the
subclass
The <string> being removed from the base class for all GL objects may
affect downstream projects which relied on it being included. In case of
Magnum, the breakages were already fixed in the previous commit.
Compile time improvement for the MagnumGL library alone is 0.2 second or
4% (6.1 seconds before, 5.9 after). Not bad, given that there's three
more files to compile and strings are still heavily used in other GL
debug output APIs and all shader stuff. For a build of just the GL
library and all tests, it goes down from 28.9 seconds to 28.1. Most
tests also still rely quite heavily on std::stringstream for debug
output testing, so the numbers still could go further.
This used to somehow get dragged along with <string> on all platforms we
tested on, but once we get rid of <string> we'd have to include
<algorithm> instead. Not acceptable, also it's much shorter and less
error-prone this way.
It doesn't make the test any simpler, easier to understand or less
error prone, on the contrary. And it would stop testing the intended
code path once file callbacks are implemented inside the importer.
Got done in 7ced4740fd and
f3fc17e2b0 for CGL and OpenAL, but ever
since Travis decided we're not worthy of using their services, I didn't
have a chance to check the warning in the iOS build. Now I have.
It's quite easy if WEBGL_debug_renderer_info is present, but if it isn't
then our only hope is to check for ANGLE-specific extensions. Which may
cause some false positives, but since we need to enable various
workarounds for ANGLE to avoid issues, it's better than having the
detection too conservative.
The original ANGLE detection based on line size is probably not so
relevant anymore, but let's keep it there.
This test is run only on Android because natively CMake treats SIGABRT
as a failure always, even if I want to just check the output. So it
got outdated. Sigh.
Well, I can't tell if it's just 32-bit x86 Android, but it definitely
works well on my ARM64 device.
Also updated the defines to use the consistent CORRADE_TARGET_* macros
instead of the platform-specific mess.