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

Author Topic: move semantics for sf::context  (Read 2991 times)

0 Members and 1 Guest are viewing this topic.

theo

  • Newbie
  • *
  • Posts: 21
    • View Profile
move semantics for sf::context
« on: October 29, 2023, 03:25:21 pm »
Hello,
I'm willing to help out on this one, and in principle it's not hard, this object contains just one unique_ptr, so move constructor and move assignment can be defaulted.
Of course there is a complication. In the moved-from object, the m_context pointer will be nullptr. Fixing the destructor is not too hard: just do nothing if m_context is nullptr (the moved-to instance is owner now):

Context::~Context()
{
    if (m_context)
    {
        if (m_context) // if moved from, m_context will be nullptr. In that case, do nothing.
        {
            if (!setActive(false))
            {
                err() << "Failed to set context as inactive during destruction" << std::endl;
            }
        }
    }
}


But the other two member functions, setActive and getSettings also access this pointer, that is nullptr in the case it is moved from.

My questions:
- is it acceptable to you to just have undefined behaviour (a crash) if setActive and/or getSettings are called on a moved-from instance of sf::Context?

if not:
- for setActive, is it acceptable to just return false on a call on a moved-from instance? Of course, in this case the destructor still has to be altered, otherwise it wil cause the diagnostic every time a moved-from sf::Context object runs out of scope.
- for getSettings, is it acceptable to return a default-constructed ContextSettings on a call on a moved-from instance?

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11030
    • View Profile
    • development blog
    • Email
Re: move semantics for sf::context
« Reply #1 on: November 03, 2023, 12:16:06 am »
I'm willing to help out on this one
Awesome! :)

My questions:
- is it acceptable to you to just have undefined behaviour (a crash) if setActive and/or getSettings are called on a moved-from instance of sf::Context?
In my opinion yes. Accessing moved-from objects is generally undefined behavior.
Then again, I'm not the most experienced person when it comes to these topics, so maybe someone else can also chip in.
Or you can just create a PR and we can discuss details on the PR itself.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

theo

  • Newbie
  • *
  • Posts: 21
    • View Profile
Re: move semantics for sf::context
« Reply #2 on: November 06, 2023, 07:44:53 pm »
OK, thanks. I will make a pull request.

 

anything