yes, cython.inline was pointless in this context and my suggestion was too magic.
Still, until one is able to deal with it automatically, perhaps a decorator or keyword saying that "don't bother to refcount my parameters, I'll take the consequences" that can be used on an inline function would fix some cases? (It is certainly not more "dangerous" than allowing raw C macros). But I'm really only brainstorming here, have nothing against your suggestion (just hope it will become obsolete in time -- DEF might be extended to access GCC defines and so on, but it is not something that should be a priority...). Dag Sverre Seljebotn -----Original Message----- From: Stefan Behnel <[EMAIL PROTECTED]> Date: Sunday, Mar 23, 2008 10:48 am Subject: Re: [Cython] Syntax for writing C macros in a Cython .pxd To: Dag Sverre Seljebotn <[EMAIL PROTECTED]> CC: Cython-dev <[email protected]> Hi, Dag Sverre Seljebotn wrote: > How do you do pointer arithmetic on Python objects? Remember the If you have Python objects stored in an array? Your macro casts the parameter to a pointer types, hence, you can do pointer arithmetic. Show me an example of valid Cython code that uses this function cdef char* _fqtypename(object t) together with pointer arithmetic in a way that breaks its macro definition. >> There currently is a ref-count overhead. When that is removed, I wouldn't > mind > seeing inline functions as a macro replacement in many cases. But I'm > pretty sure even then I see a couple of cases where I'd use macros. Short-term, macros are very useful. Long-term, I don't think they will be necesarry (as C++ demonstrates very well that they are not necessarry in principle). If the period until the long-term goals are several years (which I think it might be) then there is a case for including macro support in pxd files even if it is not "ideal", I think. How about this syntax instead for "purists": @cython.inline def mymacro(x): return raw_c("((MyType*)x)->field") That would be "cython.raw_c()". That's a syntax that allows basically any interaction with C code. However, I would prefer a syntax that stops at the function level so that Cython sees what goes in and out. That's the kind of macro I would want to have support for. It would also support this kind of macro code: #ifdef __GNUC__ /* Test for GCC > 2.95 */ #if __GNUC__ > 2 || (__GNUC__ == 2 && (__GNUC_MINOR__ > 95)) #define unlikely_condition(x) __builtin_expect((x), 0) #else /* __GNUC__ > 2 ... */ #define unlikely_condition(x) (x) #endif /* __GNUC__ > 2 ... */ #else /* __GNUC__ */ #define unlikely_condition(x) (x) #endif /* __GNUC__ */ I don't think you can do much better, even with the huge overhead of adding a Cython specific syntax. BTW, what is the "cython.inline" needed for in your example? Or is that just meant as a replacement for the current "inline" keyword? > Ie allow raw C in any function using some syntax (could be a "with-block" as well) I don't think a "with" block works here. I wouldn't want to allow real C syntax in Cython. A string should be the highest level of raw-C integration. > the same way C compilers can allow native assembler code as a propriotary extension. If a function consists of only a single raw_c instruction, we turn it into a macro instead, automatically paranthezing all arguments...something like that. Too much magic for a simple purpose? Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
