Chris Thrasher

A similar but less visually displeasing solution is to reimplement `sf::Texture` in terms of `std::shared_ptr`. This entails moving most of `sf::Texture`'s code into a private implementation class then changing `sf::Texture`...

https://github.com/SFML/SFML/issues/2507#issuecomment-1501208439 I just learned that `sf::Sound` (which contains a pointer to `sf::SoundBuffer`) solves this lifetime problem by registering the sound within the sound buffer such that the sound buffer can...

I'm leaning towards removing that complexity from `sf::Sound` for the sake of simplicity and consistency with `sf::Text` and `sf::Sprite`. The code works and seldom gets touched so it's hard to...

> As such, I'd err on the side of user-friendlyness over performance, especially as long as we don't have evidence that we can't afford the latter. Do you think we...

https://github.com/SFML/SFML/compare/master...lifetimes I had another idea for managing lifetimes. First of all, the above branch does not remove the existing APIs for assigning a font to a text nor changes the...

https://github.com/SFML/SFML/compare/master...lifetimes I rebased my `lifetimes` branch on `master` and made some further simplifications.

> Should we close this issue or is there still some alternative approach to helping with lifetime issues? The lack of consensus leads me to believe SFML 3 won't change...

If I understand correct, this PR would make sure bytes always get swapped around but what about the case where the machine's endianness matches network endianness? In that case we...

https://github.com/ChrisThrasher/SFML/commit/26ae62e694ef7866a1fe69d1a0ef91f902b973ae This inspired me to write tests that make sure we're using the correct network ordering. Let me know if you can run your code with these tests and see...

https://github.com/SFML/SFML/compare/master...ChrisThrasher:SFML:test_network_order