forward declaration header files
![](https://secure.gravatar.com/avatar/eb3fe37da4a199eb4e3b479d8a57f808.jpg?s=120&d=mm&r=g)
Ok, it looks like we need to have a chat about these "*forward.h" files I see cropping up that keep killing my rebuild times when I try to do class-level refactoring.
I realize the intent was to reduce #include dependencies, but they actually make the problem far worse: since a whole lot of unrelated stuff is grouped in one file that everyone includes, adding or removing a class requires a rebuild of fricking EVERYTHING...
And, really, do you need a header file for this? --
class Foo; class Blah;
No, you do not. It's wasteful. All it asserts is that the classes (or structs) Foo and Blah definitely exist somewhere, to keep the compiler happy and avoid ambiguity.
You can perfectly well put that directly in files where Foo or Blah are used opaquely without losing any maintainability (if either class gets removed or renamed, you'll need to edit those files regardless).
Best thing is the files that only use Foo and not Blah won't need to be recompiled if Blah is removed or renamed anymore...
So, please, STOP USING THESE BLOODY FORWARD HEADERS. I am removing xml/xml-forward.h today. I don't want to see any new ones cropping up.
-mental
![](https://secure.gravatar.com/avatar/214fe9a0ecb4aed8994e8618ade6f5a8.jpg?s=120&d=mm&r=g)
MenTaLguY wrote:
So, please, STOP USING THESE BLOODY FORWARD HEADERS. I am removing xml/xml-forward.h today. I don't want to see any new ones cropping up.
-mental
Exactly! Let's lose these things. Expecially for definitions that don't need to be known about outside of their scope.
I think that splitting interface & impl would give a much better result in speeding things up. But even then, only when it makes sense.
Bob
participants (2)
-
Bob Jamison
-
MenTaLguY