On Mar 21, 2008, at 7:16 AM, Martin C. Martin wrote: > Macros in C have a lot of problems, so I think it's best to avoid them > whenever possible. In particular: > > - The symbols they define don't show up in the debugger, memory > profiler, or other tools. > - They work at the textual level, so it's easy to get incorrect > behaviour if you forget to add extra parenthesis that aren't needed in > normal C. > - When using them to define an inline "function," they can't always be > used all places a function can. > > In your example: > > #define _fqtypename(o) (((PyTypeObject*)o)->ob_type->tp_name) > > _fqtypename(a + b) expands to: > > (((PyTypeObject*)a + b)->ob_type->tp_name) > > And by C's precedence rules, the cast applies to "a" *before* "b" > is added. > > If you want an inline function, why not just declare it inline? > > The use cases discussed on the list recently were to get around the > fact > that Cython doesn't know all that much about C or C++. Why not just > teach it more? > > No language that learned from C, such as Java and Python, include > macros. C++ tries hard to provide language support for all idioms > that > C needs them for, and there's even some talk of deprecating macros in > C++ (IIRC). > > So, I think the response should be to teach Cython about references, > rather than macros. What do people think? > > Best, > Martin > > Stefan Behnel wrote: >> Hi, >> >> since William brought up this topic lately, I think there are a >> couple of very >> valid cases where you want to define a macro in C and use it as a >> function in >> Cython. This currently means: >> >> 1) write a macros.h file to hold the macro >> 2) add a 'cdef extern from "macros.h"' to your favourite .pxd file >> to define >> your macros in Cython >> >> So this requires you to keep track of two files for things that >> may just be a >> couple of lines in C. >> >> I think this is so common that it would help if you could write >> inline C code >> in a .pxd file and have it written into your generated C file >> automatically. I >> could imagine a syntax like this: >> >> # macros.pxd >> MACROS = """ >> #define _isString(obj) (PyString_CheckExact(obj) || \ >> PyUnicode_CheckExact(obj) || \ >> PyObject_TypeCheck(obj, >> &PyBaseString_Type)) >> >> #define _fqtypename(o) (((PyTypeObject*)o)->ob_type- >> >tp_name) >> """ >> >> cdef inline from MACROS: >> cdef int _isString(object obj) >> cdef char* _fqtypename(object t) >> >> Instead of an '#include "macros.h"', this would write the string >> given by >> MACROS verbatimly into the C file, directly behind the #include >> section. It >> could also keep track of the strings in a set to make sure they >> are only >> written out once, even when cimported redundantly at various places. >> >> Any comments on this?
Cython already has inline functions and will soon support many more C+ + idioms, which should cover 90% or more what macros are used for, and in a much cleaner way. In fact, both of the examples you give can be done just fine this way. Allowing arbitrary chunks of C in strings in pxd files seems ugly as well as encouraging bad hacks. If one really wants to code raw C using another file seems much more natural. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
