From fdf590e4f03130c95bf47af52a1e37622129ffbe Mon Sep 17 00:00:00 2001 From: agentmarketbot Date: Sun, 26 Jan 2025 23:12:34 +0000 Subject: [PATCH] Use PyDataType_ELSIZE macro for dtype itemsize Replace direct access to PyArray_Descr.elsize with the recommended PyDataType_ELSIZE macro to get the element size of a dtype. This change follows NumPy's best practices for accessing dtype properties and improves maintainability as it uses the official API. The rest of the changes are just indentation fixes to maintain consistent code style. --- libs/numpy/src/dtype.cpp | 44 +++++++++++++++++++++------------------- 1 file changed, 23 insertions(+), 21 deletions(-) diff --git a/libs/numpy/src/dtype.cpp b/libs/numpy/src/dtype.cpp index 83a2bd2..abca660 100644 --- a/libs/numpy/src/dtype.cpp +++ b/libs/numpy/src/dtype.cpp @@ -89,7 +89,9 @@ python::detail::new_reference dtype::convert(python::object const & arg, bool al return python::detail::new_reference(reinterpret_cast(obj)); } -int dtype::get_itemsize() const { return reinterpret_cast(ptr())->elsize;} +int dtype::get_itemsize() const { + return PyDataType_ELSIZE(reinterpret_cast(ptr())); +} bool equivalent(dtype const & a, dtype const & b) { // On Windows x64, the behaviour described on @@ -129,42 +131,42 @@ class array_scalar_converter { public: static PyTypeObject const * get_pytype() { - // This implementation depends on the fact that get_builtin returns pointers to objects - // NumPy has declared statically, and that the typeobj member also refers to a static - // object. That means we don't need to do any reference counting. - // In fact, I'm somewhat concerned that increasing the reference count of any of these - // might cause leaks, because I don't think Boost.Python ever decrements it, but it's - // probably a moot point if everything is actually static. - return reinterpret_cast(dtype::get_builtin().ptr())->typeobj; + // This implementation depends on the fact that get_builtin returns pointers to objects + // NumPy has declared statically, and that the typeobj member also refers to a static + // object. That means we don't need to do any reference counting. + // In fact, I'm somewhat concerned that increasing the reference count of any of these + // might cause leaks, because I don't think Boost.Python ever decrements it, but it's + // probably a moot point if everything is actually static. + return reinterpret_cast(dtype::get_builtin().ptr())->typeobj; } static void * convertible(PyObject * obj) { - if (obj->ob_type == get_pytype()) { - return obj; - } else { + if (obj->ob_type == get_pytype()) { + return obj; + } else { dtype dt(python::detail::borrowed_reference(obj->ob_type)); if (equivalent(dt, dtype::get_builtin())) { return obj; } - } + } return 0; } static void convert(PyObject * obj, pyconv::rvalue_from_python_stage1_data* data) { - void * storage = reinterpret_cast*>(data)->storage.bytes; - // We assume std::complex is a "standard layout" here and elsewhere; not guaranteed by - // C++03 standard, but true in every known implementation (and guaranteed by C++11). - PyArray_ScalarAsCtype(obj, reinterpret_cast(storage)); - data->convertible = storage; + void * storage = reinterpret_cast*>(data)->storage.bytes; + // We assume std::complex is a "standard layout" here and elsewhere; not guaranteed by + // C++03 standard, but true in every known implementation (and guaranteed by C++11). + PyArray_ScalarAsCtype(obj, reinterpret_cast(storage)); + data->convertible = storage; } static void declare() { - pyconv::registry::push_back( - &convertible, &convert, python::type_id() + pyconv::registry::push_back( + &convertible, &convert, python::type_id() #ifndef BOOST_PYTHON_NO_PY_SIGNATURES - , &get_pytype + , &get_pytype #endif - ); + ); } };