While inline functions are obviously present to speed up operation, I doubt the speed increase is that vast, or even that inlining takes place on that large of a scale.
Moreover, any advantage from placing implementation in the header files is destroyed by the long wait for the library to be built after every change in a header.
I propose that the implementation be moved completely into .cpp files.
Could I please hear opinions against this?
Interface and Implementation: The Need for Speed
-
hybrid
- Admin
- Posts: 14144
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
Well, inlining is an important feature in OOP since get and set methods would otherwise introduce major performance issues. And implementing container classes and basic data types purely in headers is very common. Take STL which comes in large parts in headers only.
If you'd followed the current trends in compiler development you'd have noticed that currently everything goes into compiling time. Unless you have a very bad compiler you can say that the longer the compilation takes, the better for the code. Profiling optimizations are even compiling code twice to get better performance.
And your chances are very high that if you have to change something in your header it's not just in getters or setters such that you'd have to compile everything dependent on this file again with or without header implementations.
If you'd followed the current trends in compiler development you'd have noticed that currently everything goes into compiling time. Unless you have a very bad compiler you can say that the longer the compilation takes, the better for the code. Profiling optimizations are even compiling code twice to get better performance.
And your chances are very high that if you have to change something in your header it's not just in getters or setters such that you'd have to compile everything dependent on this file again with or without header implementations.
Getters and Setters don't require algorithms or implementation that may change. Inlining them is probably inescapable.
Moreover, the STL is in header files because it is composed of templates, which must be defined in any module that makes use of them.
Larger implementations should be moved to compilable modules. For instance, take this in COpenGLMaterialRenderer.h:
Moreover, the STL is in header files because it is composed of templates, which must be defined in any module that makes use of them.
Larger implementations should be moved to compilable modules. For instance, take this in COpenGLMaterialRenderer.h:
Code: Select all
virtual void OnSetMaterial(SMaterial& material, const SMaterial& lastMaterial,
bool resetAllRenderstates, IMaterialRendererServices* services)
{
if (material.MaterialType != lastMaterial.MaterialType || resetAllRenderstates)
{
if (Driver->hasMultiTextureExtension())
{
Driver->extGlActiveTextureARB(GL_TEXTURE1_ARB);
glDisable(GL_TEXTURE_2D);
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL);
Driver->extGlActiveTextureARB(GL_TEXTURE0_ARB);
}
glDisable(GL_BLEND);
glDisable(GL_ALPHA_TEST);
}
services->setBasicRenderStates(material, lastMaterial, resetAllRenderstates);
}