On 16.12.15 16:53, Random832 wrote:
> At the risk of bikeshedding, this needs do { ... } while(0), or
> it almost certainly will eventually be called incorrectly in an
> if/else statement. Yes, it's ugly, but that's part of the cost
> of using macros.
Yes, of course, and the patch for issue20440 uses this idiom. Here it is
omitted for clearness.
> If it were implemented as below, then it could evaluate ptr only
> once at the cost of requiring it to refer to an addressable
> pointer object:
> PyObject **__tmpp__ == &(ptr);
> PyObject *__tmp__ = *__tmpp__;
> *__tmpp__ = (new_value);
> PY_DECREF(__tmp__);
>
> I'm not entirely sure of the benefit of a macro over an inline
> function.
Because the first argument is passed by reference (as in Py_INCREF etc).
> Or why it doesn't INCREF the new value, maintaining
> the invariant that ptr is an owned reference.
Because in the majority of using cases stealing a reference is what is
needed. Otherwise we would virtually always need to decref a reference
just after using this macro. And couldn't use it as Py_XXX(obj->attr,
PySomething_New()).
> I think "SET" names imply that it's safe if the original
> reference is NULL. This isn't an objection to the names, but if
> it is given one of those names I think it should use Py_XDECREF.
Originally I proposed pairs of functions with and withot X in the name
(as Py_DECREF/Py_XDECREF). In this poll this detail is omitted for
clearness. Later we can create a new poll if needed.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4