Repository navigation
code.h uses MS-only C++ extensions #101907
Description
Activity
Rather than replace all the
.opcodeand.opargwith SHOUTY MACROS, how about:typedef union { uint16_t cache; struct { uint8_t code; uint8_t arg; } op; } _Py_CODEUNIT;Then
i.opargbecomesi.op.argwhich is still readable.Do we want that to be the API then? And so we should remove the macros entirely?
If we're going to have macros, I'd rather they be the only place we have to make a change like this.
Personally, I'd say get rid of the macros.
At least the uses of them. We should probably keep the declarations in case any third-party code is using them.
- added a commit that references this issue
on Feb 14, 2023 - added 2 commits that reference this issue
on Feb 20, 2023
Issue #100222 added a struct to
Include/cpython/code.h(which is included by default byPython.h) that is not compliant C++:The struct member requires a name, as only anonymous structs are currently permitted in standard C++.
(And since the original issue invokes PEP 7, I'll do the same and point out that "The public C API should be compatible with C++". The intention of this clause is that standard C++ can
#include <Python.h>, which is currently broken.)Linked PRs
_Py_OPCODEand_Py_OPARGmacros #101912