This new API is built on top of std::variant. This allows us to
store many different event types in a space-efficient way and access
the active event type in a type-safe manner that eliminates the
categories of UB that are possible with unions.
Co-authored-by: kimci86 <kimci86@hotmail.fr>
This change was made in 359fe90 due to recommendations from tooling.
On its face this change makes sense since it removes a copy that
isn't always necessary. In practice it caused ergonomic issues due
to now being forced to make a copy of the render states when needed.
The performance gains of eliding this copy are unsubstantiated. We
have not done any profiling to measure its impact. For lack of such
measurements I'd rather err on the side of improved user experience.
If future benchmarks prove this copy is rather expensive then we
can reconsider removing it with that evidence in mind.
While I don't suspect there are any uninitialize variable bugs
present, it's still good to err on the side of safety and provide
an initial value nonetheless.
When dealing with calculations that are fundamentally two dimensional
it's helpful to use a 2D data type as much as possible rather than
decomposing the calculations into x and y components. The more we use
vector operations the better chance we have of easiliy reasoning about
what the code is doing.
Fixed formatting issues per review
Implemented copy constructor since operator= is implemented
Reverted operator=, add NOLINT for copy constructor per review
Fixed clang-tidy escape in examples
Fixed OSX clang-tidy escapes
CMake doesn't require absolute paths so we can safely remove
SRCROOT and let implicit relative pathing achieve the same result
with less work on our part.
Similar to sf::Time, sf::Angle provides a typesafe API for working
with angles and provides named functions for converting to and from
degrees and radians.
This removes the sfml- prefixed targets from the export set. The sfml-
prefixed targets are still available within the build tree but not to
downstream users thus making this an API breaking change when compared
to the 2.x releases. To keep things consistent, usage of the sfml-
targets were replaced with their namespaced counterparts.
This has a number of benefits:
1. It's more idiomatic. Modern CMake libraries are expected to
have namespaced targets.
2. Namespaced targets are less likely to collide with user-defined
targets. No one will accidentally define a SFML:: target.
3. If a namespaced target is not found by CMake, configuration
will immediately stop.
