[somehow this got detached from the original thread...]
On Mar 23, 2008, at 2:06 AM, 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.
>
> (Perhaps you meant that it won't arise in practice, but that's
> different.)
One can already do this in Cython. <void*> or <PyObject*>
>> 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.
Removing the ref-count overhead should be easy to do. Perhaps I'll do
it this afternoon.
> 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")
>
> Ie allow raw C in any function using some syntax (could be a "with-
> block"
> as well), 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.
This avoid the whole issue of name mangling... and to automatically
parenthesis arguments we would have to (essentially) write a C parser.
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
