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.
This silences an MSVC warning about lsbDelta and rsbDelta not being
initialized. Whether or not this fixes any bugs, it provides a
better user experience if nobody sees those warnings.
Character traits are only standardized for character types of which
std::uint8_t is not. All major C++ implementations happen to define
this specialization but because it is not standard C++ they are
allowed to remove it as LLVM has done by deprecating this specialization
in LLVM 18. It is slated for removal in LLVM 19. To avoid compilation
errors and to get ahead of any deprecation warnings when LLVM 18 ships
we need to define our own std::uint8_t character traits.
SFML 4 will have access to C++20's std::u8string which should let us
remove this code.
sf::RenderWindow still inherits a virtual destructor from a base
class so there's no need to explicitly declare a virtual destructor.
I added a test to ensure this property was not broken.
The purpose of those was to make it obvious that an action is needed to
update KeyCount or ScancodeCount when adding more enumerators, but we
rarely touch those enumerations so it is not worth adding those
technical names to the public API.
Those values are not valid Key or Scancode values, so it doesn't make
sense for them to have Key or Scancode type.
Moving them out of their enum makes it possible to write exhaustive
switch case statement without having to write a case for those values.
Making them unsigned int allows to use them as array size without having
to do a static_cast.
std::array lets us have a single source of truth for array size
rather than needing separate constants or magic numbers that have
to stay in sync with the underlying array.
This class hides a lot of its logic in the private section of the
classes and uses friends to access them so there is little accessible
in the public interface for testing.
In a few places I left references to the old name where appropriate.
There are also many CMake references to "OSX" that we have to keep
using since CMake does not offer alternative names for those variables
and target properties.
This glyph class should most definetely be a struct. There aren't any
functions into it. This PR is more of a philosophy question than
anything else. I think we should make an argument for and against here
too.
Dates back to 2009 when 78247bd38 was written. I'm going to assume
the situation has improved in the last 14 years. There are SFML
users who weren't even alive in 2009...
This fails to link on MinGW. Until that can be resolved we can go
back to a normal constant. Because this is just an integer it doesn't
matter all that much whether it's const or constexpr.
Addressed CI complaints
Addressed review comments, CI issues
Reverted files exempted from linting
Fixed missing comma
Fixed clang-format escape
Disabled spurious readability-non-const-parameter
Addressed review comment
Moved NOLINT inside namespace per review
Remove const from function argument decls
Fixed rebase and formatting issues
Fixed macOS CI issues
Funny how the addition of a forward declaration resulted in
accidentally disabling move semantics for two types. We ought to
be careful that build time improvements don't have runtime
performance impacts.
Because this class is implemented with unique pointers, copy semantics
are implicitly deleted. This can be verified by the type trait tests
which continue to affirm that these types are noncopyable.
- Aligned mappings
- ScanDash -> ScanHyphen
- Numpad keys include Numpad
- *Equals -> *Equal
- Key 29/42 are Backslash
- Key 45 is Non-US Backslash
- Add additional media & more scancodes
- Rename ScanAgain to ScanRedo
- Rename ScanMute to ScanVolumeMute
- Add the missing F-key mappings for macOS
- Fix mapping in Windows code
- Correctly handle numpad keys on Windows for isKeyPressed
- Refactorings
- Use mapping for Linux from different key config
- Refactor some mapping code
- Fix map initialization
- Layout independent keys also don't have unicode characters, so it
makes more sense to translate them first and use unicode as fallback
- Fix iteration limits on Windows
- Consistently use 'Scancode' instead of 'ScanCode' everywhere
- Use 'delocalize' instead of 'unlocalize'
- Fix conversion warnings
- Remove unused mapping function
- Hide parameters for non-applicable iOS functions
- Update documentation
- Add Android InputImpl scancode function stubs
By deleting this constructor overload, it fails to compile if
you pass a temporary font to this parameter slot. That includes
code like
sf::Text text("", sf::Font());
but more importantly it prohibits code like this
sf::Font getFont()
{
sf::Font font;
// load a font...
return font;
}
sf::Text text("", getFont());
The same idea can be applied to setFont() to prevent setting fonts
from a temporary.
Credit to Jonny for the idea
Co-authored-by: JonnyPtn <jonathan.r.paton@googlemail.com>
