[Python-Dev] #ifdeffery

[Michael Hudson]

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