I am maintaing a legacy MFC application and I see a pattern exactly like the one on Object-Oriented Programming under Windows book, where the relevant part is:
Persview.h
#ifndef _DEBUG // debug version in persview.cpp
inline CPersDoc* CPersView::GetDocument()
{ return (CPersDoc*)m_pDocument; }
#endif
Persview.cpp
#ifdef _DEBUG
CPersDoc* CPersView::GetDocument() // non-debug version is inline
{
ASSERT(m_pDocument->IsKindOf(RUNTIME_CLASS(CPersView)));
return (CPersView*)m_pDocument;
}
#endif //_DEBUG
I see the pattern widely applied if I search for it on Internet, so I presume it is wizard generated code.
My question is: Is there any advantage or another good reason for the release version being inlined on the .h file and the debug on the .cpp file? Why not put both on the same file next to each other?
For the non-debug build the advantage is that the header file is precisely where an
inline
function definition belongs, so that multiple#include
's only see one definition of it.For the debug build where the function is not inlined, the advantage is that you keep with the convention of declarations and definitions being separate - the definition is where you'd expect to find it.
i.e. You wouldn't put them together in the header file because that is unexpected when not
inline
, and you wouldn't put them together in the source file because that would be wrong when it isinline
.