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