Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: SFML Move Semantics  (Read 863 times)

0 Members and 1 Guest are viewing this topic.

unlight

  • Newbie
  • *
  • Posts: 23
    • View Profile
    • Email
SFML Move Semantics
« on: April 14, 2020, 01:40:18 am »
Hi guys,

I was hoping to find some information about the status of move-semantic implementation in SFML. I have seen a bit of discussion regarding C++ standard support and plans on the SFML roadmap, but I am not sure if any concrete decisions have been made, or if anyone is already working on it?

My motivation for asking is because I would be more than happy to work on implementing move semantics for SFML, but only if it fits with SFML's current plans and would be taken seriously / reviewed for merging.

Much love!

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32397
    • View Profile
    • SFML's website
    • Email
Re: SFML Move Semantics
« Reply #1 on: April 14, 2020, 08:30:44 am »
There was a big plan to switch code to a modern C++ standard (starting with writing some unit tests to ensure no regression), but obviously no one has enough free time and motivation to start doing it.

Move semantics don't break API compatibility, so this can be done for SFML 2.6 I guess. Let's do it ;)
Laurent Gomila - SFML developer

unlight

  • Newbie
  • *
  • Posts: 23
    • View Profile
    • Email
Re: SFML Move Semantics
« Reply #2 on: April 18, 2020, 01:15:52 am »
Alright, I will take this on then  :D

Before I start, I would just like to clarify my intentions would be to implement explicit move constructor and move assignment operators for classes that inherit from sf::NonCopyable.

Also, is there a place that the SFML devs usually discuss development when required, or is this forum post appropriate enough?

[EDIT]:

Oh gosh, I just noticed the lengthy discussion on sf::NonCopyable. Am I safe to assume we keep sf::NonCopyable and leave it untouched?

https://en.sfml-dev.org/forums/index.php?topic=21781.15
« Last Edit: April 18, 2020, 01:21:44 am by unlight »

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32397
    • View Profile
    • SFML's website
    • Email
Re: SFML Move Semantics
« Reply #3 on: April 18, 2020, 09:50:08 am »
Quote
Am I safe to assume we keep sf::NonCopyable and leave it untouched?
Yes.
Laurent Gomila - SFML developer

Elias Daler

  • Hero Member
  • *****
  • Posts: 592
    • View Profile
    • Blog
    • Email
Re: SFML Move Semantics
« Reply #4 on: April 24, 2020, 05:11:28 pm »
Move semantics don't break API compatibility, so this can be done for SFML 2.6 I guess. Let's do it ;)
Hmm... but it requires a move to C++11. This is a huge change, it's not just about API?...
Tomb Painter, Re:creation dev | eliasdaler.github.io | @EliasDaler | Tomb Painter dev log

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32397
    • View Profile
    • SFML's website
    • Email
Re: SFML Move Semantics
« Reply #5 on: April 24, 2020, 06:31:37 pm »
Quote
Hmm... but it requires a move to C++11. This is a huge change, it's not just about API?...
What exactly is a huge change? To stop supporting non-C++11 compilers? I don't think it's that huge ;)
Laurent Gomila - SFML developer

unlight

  • Newbie
  • *
  • Posts: 23
    • View Profile
    • Email
Re: SFML Move Semantics
« Reply #6 on: May 27, 2020, 02:04:48 am »
I am currently postponing work on this feature in favour of something that is on the critical path to SFML 2.6. I shall return!

 

anything