Re: [Python-Dev] #ifdeffery
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.
Ilya Sandler <ilya@bluefir.net> writes:
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?
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 <wink>. -- Tim Peters, comp.lang.python
Michael Hudson wrote:
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 :-)
I'd like to stress that last point. Ilya, please do consider contributing a patch. As you say, it is technically trivial, but probably too much effort for any by-standing volunteer. I only committed the original patch because I considered the feature "mostly harmless", and because it had been sitting on SF for several years. I certainly won't touch this unless a) somebody reports a REAL bug, and Jeremy doesn't fix that, or b) somebody contributes another patch. Actually writing a patch, and testing it (including the two recompilations that will take) is too much effort, so I rather write a longish email seeking volunteers... Regards, Martin
Martin> Actually writing a patch, and testing it (including the two Martin> recompilations that will take) is too much effort, so I rather Martin> write a longish email seeking volunteers... Teach them to fish... Skip
participants (4)
-
"Martin v. Löwis" -
Ilya Sandler -
Michael Hudson -
Skip Montanaro