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

Michael Hudson mwh at python.net
Mon Aug 23 17:14:01 CEST 2004

Ilya Sandler <ilya at bluefir.net> writes:

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 WITHTSC blocks in ceval.c Most of these blocks look like this: #ifdef WITHTSC rdtscll(inst0); #endif where rdtscll() is defined in the beginning of ceval.c as follows #ifdef WITHTSC ... #define rdtscll(var) ppcgetcounter(&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?

No, this definitely makes sense to me. I'd prefer to call the macro something more transparent, though. One of the other things I didn't do when porting this stuff to PPC was changing the names so that it's less Pentium specific. Patches welcome :-)

Cheers, mwh

-- Python enjoys making tradeoffs that drive someone crazy . -- Tim Peters, comp.lang.python

More information about the Python-Dev mailing list