What is the sense of setView(getView())?

[sharethis]

Debugging my application which uses the last SFML 2.0 snapshot, I stumbled upon a line in RenderTarget.cpp. It reads:

// Set the default view
setView(getView());

Since "getView()" returns "m_view" and "setView()" simply sets "m_view", it the line above make any sense to me.

////////////////////////////////////////////////////////////
void RenderTarget::setView(const View& view)
{
    m_view = view;
    m_cache.viewChanged = true;
}


////////////////////////////////////////////////////////////
const View& RenderTarget::getView() const
{
    return m_view;
}

Could you please explain what this is supposed to do? I am just curious and want to find the bug in my own application.

[sharethis]

I figured it out. "setView()" also set "m_cache.viewChanged" true which internally results in a call to "applyCurrentView()". It sets the viewport and the projection matrix to the default.

[Weeve]

couldn't this be made more efficient by just changing m_cache.viewChanged to true? to avoid pulling the data from the view, and changing it again, when only one bool change is needed? (20 cycles on the CPU versus 1?) but since the rune only once, it may not be worth the trouble

[cire]

couldn't this be made more efficient by just changing m_cache.viewChanged to true?

Unlikely.  Trust your optimizer.  Since setView and getView are likely to be inlined, there should be no difference in the code.

Actual generated code:

; 305  :         // Set the default view
; 306  :         setView(getView());

        mov     BYTE PTR [edi+345], 1

[Laurent]

Honestly, I never waste my time with such questions that will obviously not make any difference at all. I prefer to write clean and maintainable code. For example, if one day I add another line to the setView function, I'll be happy because the current code will still work. Whereas your "optimized" code won't.