Hi Stefan, Stefan Behnel wrote: > Hi, > > Martin C. Martin to-posted: >> Stefan Behnel wrote: >>> 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. >>> >>> 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) >> 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. > > Well, in most cases macros are rather short code snippets, not function > replacing code blocks. So I don't care about their symbols.
That's surprising to me. Don't you think you'd want to step through even short snippets in a debugger? To have them show up as a separate item in a profile, rather than spread around all the places that call them? Same with memory leaks or corruption? > >> - 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. > > Sure, that's why you have to take care when you use them. In my first > sentence, I said "I think there are a couple of very valid cases", I think > that makes the focus clear. > > >> 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 that's definitely not a valid use case of _fqtypename(). Why is that? Isn't pointer arithmetic a valid use case? >> If you want an inline function, why not just declare it inline? > > Because for small code snippets that exist solely for performance reasons, the > overhead of a function defined in Cython may be too high. But if it's declared inline, there's no function call overhead at runtime. Unless you're in a debug build, in which case you'd rather have the overhead to help track down bugs, leaks, etc. Do you mean compile time overhead? Or something else? >> 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? > > Does that imply a 'real' syntax for C macros? No, it implies having Cython distinguish between references & values where appropriate. Best, Martin _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
