ok , so now we know why that __BORLANDc__ thing is needed.
Well, it's a decision then to support Borland with pch or not.
But keep the following in mind. Say the some other compilers (Digital Mars or whatever) also need special stuff for pch in the code, then we can end up with a list of such #ifdef do whatever is needed in here for that specifi compiler #endif structures, and that will make the code less easier to read.
My point of view on this is, first we should have standard compliant code, so it's as portable as can be. Pch is not part of the standard (I think), that's why I am stressing on the point to do includes correct, because then you at least have correct standard code.
CB code has decided to use the pch feature of GCC, and therefor you find things like :
#include "the pch header"
#ifndef CB_PRECOMP
blablabla
#endif
more blablabla
where blablabla and more blablabl is header inclusion directives.
So, support BorlandC : yes or no. CB sources itself *only* support gcc, so in CB sources that Borland stuff is ready to go out of the door.
When you want to enable Borland pch, it is sufficient to do it in that pch header (sdk.h), and for pch support that header should be included first. And then the blablabla stuff.
I think wx pch header probably does similar thing, so also that points that it is not needed to do in our sources or wizard generated sources.
Oh, new post already before this one is ready, with interesting information :
But AFAIK, newer BCC (Turbo C++ Explorer 2006's compiler) supports PCH creation using a Header file. So that bad hack is necessary only for BCC 5.5.
Bye bye BCC5.5 ;-)
When a user is creating a bigger project starting from the wizards code, it can happen he wants to to pch stuff with his code, well that's the users choice, I feel that the code generated from our wizards should NOT take that into account. We can not, and should not, predict all possible uses or ideas a user might have in mind.