[Python-Dev] #ifdeffery
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 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
More information about the Python-Dev
mailing list