On 25/03/2021 18.39, Antoine Pitrou wrote:
On Thu, 25 Mar 2021 20:22:55 +0300 Ivan Pozdeev via Python-Dev <python-dev@python.org> wrote:
On 24.03.2021 19:58, Antoine Pitrou wrote:
On Wed, 24 Mar 2021 19:45:49 +0300 Ivan Pozdeev via Python-Dev <python-dev@python.org> wrote:
How does C++ fare in binary compatibility? Last time I checked it out (about 10 years ago), there was completely none, every compiler's ABI was a black box without any guarantees whatsoever. For any software that's going to dynamically link and exchange binary types with other independently produced software, that's a deal breaker. That depends if you use C++ internally or expose C++ bits in the public API. If you only use C++ internally, binary compatibility is presumably less of an issue.
Python produces and accepts its internal types in API calls and allows extension modules to derive from them -- so it cannot "only use C++ internally" if those are going to become C++ types. (And if not, the point of using C++ is unclear.)
You can use C++ without exposing C++ types in the API. For example, C++ templates could improve the maintainability of the generic "stringlib" routines that are currently based on C macros. Another example is using RAII in function bodies to help cleanup owned references.
C has ways to handle cleanup and ownership better -- at least some compilers do. For example gcc has __attribute__(cleanup(cleanup_function)) for automatic cleanup on scope boundaries. If I recall correctly it works something like this: void Py_auto_decref(PyObject **o) { if (!o || !*o) return; Py_DECREF(*o); *o = NULL; } PyObject * func(PyObject self) { PyObject *spam __attribute__((cleanup(Py_auto_decref))); ... Py_RETURN_NONE; // spam gets automatically decrefed } It's too bad that the feature is not universally available in C99. Christian