Switching the iterator comparison used lowers the requirement for
iterators from *RandomAccessIterators* to *ForwardIterators*, which is a
benefit. It is also more accurate; instead of saying "if `begin` is less
than the end, stop." it states "if `begin` is not equal to end, stop."
Additionally, the old '<' did not protect us from undefined behavior because it is
undefined to compare two iterators relationally that are not:
1. past the end
2. within the array
sf::Exception can use the inheriting constructors functionality instead of a constructor delegating to the parent constructor.
I removed Exception.cpp as it is not needed anymore.
Initially we had 3 of 4 Android CI jobs running the tests. Various
problems caused us to disable testing in 2 of those 3 jobs. Now
we're dealing with the last Android CI job failing to run the tests.
Because this is blocking CI and because the value of running these
tests it not especially high, I am removing this testing
infrastructure. We can reconsider this decision in the future if a
more reliable solution is found.
This is a reversion of most of 2386653.
I also added a type trait test to check whether the conversion operator is marked explicit.
this change has the advantage of being clearer imo as it is a conversion operator for conersions not a constructor.
and also it allows users to take the address of convesion operator which I don't know if someone might find that useful.
If `GLEXT_glGetInfoLog` fails then `log` is left unchanged which
can lead to a reading from an uninitialized buffer on the following
line. Initializing the buffer ensures this never happens. While I
was touching this code I elected to switch to `std::array` as well
since SFML has made previous efforts to stop using C-style arrays
and I wanted to continue that effort.
- Only fail the Mesa 3D arch check, if it's been enabled
- Add a cross-compilation CI job for Windows ARM64
- Fix ARM64 architecture detection for the Ninja generator
CMake supports a number of strings for truthy and falsey values.
ON/OFF and TRUE/FALSE are the most popular but 1/0 is also supported.
This is mostly a style choice but I'm inclined to believe that ON/OFF
is the most popular option and I'm generally in favor of style
choices that better align with the community at large.
