??? 03/23/10 17:34 Read: times |
#174439 - Create a Compiler header Responding to: ???'s previous message |
Per Westermark said:
Another thing here is that compiler vendor X may decide to change the memory layout of their data structures between versions of the compiler, in which case the source code will recognize the compiler but fail to notice that the manually corrected code isn't correct anymore. Add the version Per Westermark said:
Another thing - exactly how readable is code with a lot of #ifdef sprinkled? quite readable by using top-down programming methodology instead of mixing in bottom-up. Create a header file for example #ifdef KEIL // KEIL compiler # define Reentrant(x) x reentrant # define Sfr(x,y) sfr x = y # define Sfr16(x,y) sfr16 x = y # define Sbit(x,y,z) sbit x = y ^ z # define Interrupt(x,y) x interrupt y # define At(x) _at_ x # ifdef __C51__ // C51 Compiler # define far xdata // far is for C251 only # endif #endif // End of KEIL #ifdef RAISONANCE // RAISONANCE compiler # define Reentrant(x) x reentrant # define Sfr(x,y) sfr x = y # define Sbit(x,y,z) sbit x = y ^ z # define Interrupt(x,y) x interrupt y # define At(x) _at_ x # ifdef __C51__ // C51 Compiler # define far xdata // far is for 251 only # endif #endif // End of RAISONANCE Per Westermark said:
And how much time do you save by testing your #ifdef section and documenting it, compared to just writing portable code? Takes quite a bit of time in the beginning, but using top-down methodology, one can keep using compiler.h and put that in their toolbox. Thereby, reducing the overall time in the long run. Per Westermark said:
If a new programmer gets involved in the project - do you think the new programmer will be more comfortable trying to read through your documentation about special cases, or instead seeing traditional portable code? Even better that a new programmer learn top down programming instead of picking up bad habits to begin with. |