On Fri, 13 Aug 2004, Michael Hudson wrote:
"Raymond Hettinger" <python@rcn.com> writes:
P.S. Side rant: Also, in the last few months, the #ifdefs have multiplied. While I understand that some things like time stamping are worthwhile, the code is getting harder to read and maintain because of all this b.s.
Is it really getting worse?
I think there are two qualitatively different sorts of #ifdef mess: feature ones, like the WITH_TSC I've recently been fiddling with recently and portability ones.
Actually, I have a suggestion regarding #ifdef WITH_TSC blocks in ceval.c Most of these blocks look like this: #ifdef WITH_TSC rdtscll(inst0); #endif where rdtscll() is defined in the beginning of ceval.c as follows #ifdef WITH_TSC ... #define rdtscll(var) ppc_getcounter(&var) ... #else /* this section is for linux/x86 */ ... #endif so why not to add a dummy rtdscll() macro to the else section of the above ifdef: #else /* this section is for linux/x86 */ #define rdtscll(var) #endif Then one can simply omit ifdef brackets for rdtscll invocations, removing about 20 ifdefs.... there are probably other places in the code where this trick could be used Does this make sense or am I missing something here? Ilya
The feature #ifdefs aren't (or shouldn't be) that much of a big deal. Ideally, they are documented in Misc/SpecialBuilds.txt and depending on whether they are defined or not, bits and pieces of code are or are not included.