How much time does it takes you to compile Irrlicht?

[vitek]

It's chapter 6.8, member pointers. It's really an astonishing document.

If you are worried about optimization for this case, then any time the Irrlicht library declares an offset member pointer it should include the appropriate header. As you already know, Irrlicht does not use offset member pointers.

But esp. interface includes should contain all necessary headers because they either require them anyway due to inline implementations and because otherwise the enduser would be required to include additional headers anyway, at least in the majority of cases.

First off, not true. In many cases the user of a class only needs the compiler to know the size of the object and its layout. They do not need definitions for all of the classes that can be used with that class type. Think about my example of the SMaterial structure. The user of the SMaterial almost _never_ needs to know the definition of ITexture. They assign the texture pointer that is returned from the video driver and that is it. Think about the IVideoDriver interface. Just because the user needs a definition for the abstract video driver class does not mean that they need [or even want] a definition for the IImageLoader or IImageWriter interfaces. I'd be willing to bet most applications don't directly access either of these interfaces at all.

Also, isn't this what the Irrlicht.h header is for? It includes every one of the Irrlicht interface class headers.

Normally the interface class headers would use forward declarations and include the minimal headers required so that it will compile when included into an empty source file. Then a package or library header is made that includes all of those interface headers. If the library user cares about compile times, then they include only the necessary files to compile each source file. If they care only about ease of use, then they just include the library header. This gives the user the most flexibility.

By the way, I happened to work for a company that made professional C++ class libraries. I can remember specific instances where changing unnecessary includes to a forward declarations significantly reduced end user compile times. I don't mean 20 seconds, I mean hours.

[vitek]

Each interface header ONLY #includes header files it needs to compile.

Again, not true. Examples of where a forward declaration would work in place of an include as of Irrlicht 1.1...

• IAnimatedMesh.h doesn't need IMesh.h
• IAnimatedMeshSceneNode.h doesn't need IAnimatedMeshMD2.h or IShadowVolumeSceneNode.h
• ICameraSceneNode.h doesn't need SViewFrustrum.h
• IEventReceiver doesn't need ILogger.h or KeyCodes.h; both enums can be forwarde declared
• IImageLoader.h doesn't need IReadFile.h or IImage.h
• IImage.h doesn't need rect.h or position2d.h
• IGUIImage.h doesn't need ITexture.h
• IGUIWindow.h doesn't need IGUIButton.h
• IMeshManipulator.h doesn't need IMeshBuffer.h
• IMeshLoader.h doesn't need IReadFile.h or IAnimatedMesh.h
• IMeshBuffer.h doesn't need SMaterial.h, aabbox3d.h, irrArray.h or S3DVertex.h
• IMesh.h doesn't need IMeshBuffer.h
• IParticleAffector.h doesn't need IAttributeExchangingObject.h or SParticle.h
• IParticleEmitter.h doesn't need IAttributeExchangingObject.h or SParticle.h
• IParticleSystemSceneNode.h doesn't need IParticleEmitter.h or IParticleAffector.h
• ITriangleSelector.h doesn't need triangle3d.h, aabbox3d.h or matrix4.h
• ITexture.h doesn't need IImage.h, dimension2d.h or EDriverTypes.h
• ITerrainSceneNode.h doesn't need SMeshBufferLightMap.h, irrArray.h or IMesh.h
• IShadowVolumeSceneNode.h doesn't need IMesh.h
• ISceneManager.h doesn't need ITerrainSceneNode.h or SceneParameters.h, SMaterial.h, irrArray.h
• IrrlichtDevice.h doesn't need IFileSystem.h, IVideoDriver.h, EDriverTypes.h, IGUIEnvironment.h, IEventReceiver.h, ISceneManager.h, ICursorControl.h, IVideoModeList.h, ITimer.h, ILogger.h or IOSOperator.h
• IVideoDriver.h doesn't need rect.h, ITexture.h, matrix4.h, IReadFile.h, SMaterial.h, SLight.h, IImageLoader.h, IImageWriter.h SExposedVideoData.h, IMaterialRenderer.h, triangle3d.h EDriverTypes.h or IGPUProgrammingServices.h [others could be removed if parameter types were changed from value to const reference]
• SMaterial.h doesn't need ITexture.h

Remember that just removing the include and replacing it with a forward declaration isn't enough. You would need to fix any source files that expect the include to be in the original interface header. If you just make the change and recompile, the compiler will tell you where you need to go next.

Note that this doesn't include unnecessary includes in the implementation headers and source. Many of those could be stripped down also, but doing that would only affect the build time of the Irrlicht library itself. It would have no effect on the build time of a project that just used the headers and linked the Irrlicht library.

There are _many_ forward declarations used in the Irrlicht interface headers. If you look at the implementations of many of the classes you will see that some code is using forward declarations everywhere they can [IMeshCache.h, IGUIEnvironment.h], some code is not [IrrlichtDevice.h, ITriangleSelector.h], and there is still other code that has a little of both [IVideoDriver.h, ISceneManager.h]. Clearly someone was using forward declarations for a lot of the interface headers. Either they stopped working on the code or they just stopped doing it for some reason.

[elander]

I agree 100% with Vitek on this. It helps you making better code by controlling include dependencies and reducing them to the minimum. If you want to include everything then just have:

#include <irrlicht.h>

Or even, for a more fine control:

#include <irrCore.h>
#include <irrIO.h>
#include <irrXml.h>
#include <irrDevice.h>
#include <irrVideo.h>
#include <irrScene.h>
#include <irrGui.h>

[zenaku]

You are right about the headers you list. I think we had a miscommunication

IAnimatedMesh.h doesn't need IMesh.h

My point was that if you are going to implement a CAnimatedMesh, you will invariably need to include IMesh.h also, so you might as well include it in the IAnimatedMesh.h file. For the most part that's the way it is now. Each implementation file only needs to #include the interface file it's impementing.

Then again not everyone is implementing their own CAnimatedMesh. If you just want to reference IAnimatedMesh you probably don't need to #include IMesh.h.

Point taken vitek

[mandrav]

Another way would be to use precompiled headers on VC, but that would be a platform specific build optimization.

Precompiled headers are supported by gcc too so there goes your cross-platform barrier .

I didn't find any debug option activated in CodeBlocks. What i did find was -O3 and -expensive-optimizations flags set. The strange thing is that it took alomst the same time : 4min13s.

Damn i can't believe GCC is being beaten by M$.

What you should understand is that the compiler is taking long to build irrlicht because of these optimizations.
Try rebuilding irrlicht without these switches and you 'll see it building really *fast*.
So, if you 're worried about build times because you 're adding new features to irrlicht and you need to recompile all the time then remove these optimizations to speed up development. When you 're done, rebuild once with the optimizations turned on and you 're good to go .

Finally, vitek is right in everything he said about #includes and forward declarations.

[vitek]

Precompiled headers are supported by gcc too so there goes your cross-platform barrier

Wow. GCC 3.4 and later does support PCH. I didn't know that. Still there are other compilers out there that don't support PCH, so it is still a platform dependent build optimization. :)

[juliusctw]

it takes my computer 45 sec to compile the source, i have the new amd dual