[Python-Dev] #ifdeffery (original) (raw)

Ilya Sandler ilya at bluefir.net
Mon Aug 23 17:07:42 CEST 2004

On Fri, 13 Aug 2004, Michael Hudson wrote:

"Raymond Hettinger" <python at 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 WITHTSC 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.

More information about the Python-Dev mailing list