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?
