Hi there.
The discussion on http://bugs.python.org/issue20440 started me thinking that
much of this
bikeshedding could be avoided if we weren't constrained to writing macros for
all of this stuff.
For example, a
Py_INLINE(PyObject *) Py_Incref(PyObject *obj)
{
Py_INCREF(obj);
return obj;
}
could be used in a Py_Assign() function, if a new reference were wanted:
Py_INLINE(void) Py_Assign(PyObject ** target, PyObject *obj)
{
PyObject *tmp = *target;
*target = tmp;
Py_DECREF(tmp);
}
So that you could then safely write code like
Py_Assign(&MyVar, Py_Incref(obj));
This would also allow you to stop writing various super macros to try to cater
to all possible permutations.
Now, Larry Hastings pointed out that we support C89 which doesn't support
Inlines. Rather than suggesting here that we update that compatibility
requirement,
how about adding a Py_INLINE() macro.? This would be like Py_LOCAL_INLINE()
except that it would drop the "static" keyword, unless inline isn't supported:
#if defined(_MSC_VER)
#define Py_INLINE(type) __inline type
#elif defined(USE_INLINE)
#define Py_INLINE(type) inline type
#else
#define Py_INLINE(type) static type
#endif
The only question is with the last line. How many platforms actually _do_not_
have inlines? Would writing stuff like this be considered problematic for
those platforms? Note, that I'm not suggesting replacing macros all over the
place, only for new code.
Another question is: Is "static inline" in any practical way different from
"inline"?
It would be great to get rid of macros in code. It would be great for debugging
too!
K
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
