The headers managed by wxSmith should remain there, rather than be moved to kodersdialog.cpp, because first, they do not have to do with precompilation, and second, if kodersdialog.h is used by any other compilation unit, the other compilation unit will not need to include the same headers, avoiding duplication of #include statements.
Not true : have a look at the "C++ coding standards" book from Sutter/Alexandrescu or in other books of Sutter or Meyers, you always want to minimize dependencies.
Example : Morton initially used a wxCombobox, so the Koderdialog.hpp was including that header. Now when wx changes something to that header every client of our header dialog needs to rebuild. What do the clients care about how our dialog was implemented. If the include was just in the cpp file, our file needs to rebuild (since some part of it's implementation changed, or something he depends upon) and the kodersdialog do not need to rebuild.
It is already bad enough that C++ doesn't seperate interface from implementation (when I changed from combobox to a wChoice to avoid a wx bug on linux) the client needed to recompile, and once again they should not, but here's it's the fault of C++.
Look at the PUBLIC interface of the kodersdialog, this is the only part a client will use, there's no sign in there of buttons, choices, text ctrl's or whatever. So avoid 'leaking' that to the outside. And with pointers and references together with forward declarations you can achieve that.
Look at STL for example they provide a special header for that iosfwd, so no need to include in headers the iostream ...
Now let's be silly, and assume there would be some quirky method in the interface that would need let's say a button, a choice, ... And I said quirky, so passing by value (bye bye performance) ;-)
Then your argument says, well I don't need to include anything anymore : not good and dangerous.
1) not good :
maybe I just needed that function with the button and I don't call the choice one --> I do not need that include from choice, no sir, I just asked for a button, no extra choice's or me.
2 dangerous :
- the button and choice were included by the kodersdialog. In "MY" file wich included that kodersdialog, I myself also use a button (just imagine it's some sort of interesting structure or class, let's forget about the gui aspect), BUT I forgot to add the include for the button, I compile. Everything compiles nicely, no not thanks to me, thanks to that kodersdialog !!!
NOTE : I do not call that button method, or switching back to the original case, nothing in the public interface related to buttons.
Nice new version of the kodersdialog (hint : no more buttons in there -> so no include of it in the header), I surely want that. I compile -> error button not known. Why why why, I used to work before, ok time to spend some prescious time to find out, who in the past gave me that include of button --> nice headers traversals to find out. Forget about, correct solution : I include it myself.
Does this sound stupid, maybe, but it's a fact of life, it has happend/happens to all of us. Those gurus I mentioned above, they were willing to spend time, effort and book space to it because it matters.
The client should always include what he needs.
This should be the way :
#include <wx/button.h>
Button MyButton;
// do something with that button
KodersDialog MyDialog;
MyDialog.MethodUsingAButtonByValue(MyButton);
And if I would use that choice function also, well I include the stuff needed to be able to use that function.
Cheers.
