STINNER Victor <vstin...@python.org> added the comment:
Raymond: > We're wasted a lot of dev time on something that never promised much value in > the first place. I'm one of the first to advocate to replace ugly macros with clean static inline functions. Macros are evil and can be too easily misused. On PR 15216, Benjamin and Raymond advised to replace the macro with a function. I'm also a believer that one day, we could replace duplicated C functions accepting variant of C "integers" types with a single larger type: * signed: replace (char, short, int, long, long long, ssize_t) with intmax_t * unsigned: replace (unsigned char, unsigned short, unsigned int, unsigned long, unsigned long long, size_t) with uintmax_t Sadly, it seems like such change has a small performance loss, and so cannot be done in "performance critical" code. I consider that longobject.c is such performance critical code. -- I converted some macros of the Python C API to static inline functions, like Py_INCREF() or _PyObject_GC_TRACK(): https://vstinner.github.io/split-include-directory-python38.html Compared to macros, static inline functions have multiple advantages: * Parameter types and return type are well defined; * They don't have issues specific to macros: see GCC Macro Pitfals https://gcc.gnu.org/onlinedocs/cpp/Macro-Pitfalls.html ; * Variables have a well defined local scope ; * GDB is able to retrieve then name when read the current C stack ("backtrace"). -- Again, I advice to add a small comment in longobject.c macros to explain that converting them to functions would loose performances. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue37812> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
