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
