[SciPy-dev] Changing return types in C API
ndarray at mac.com
Tue Jan 31 21:26:46 CST 2006
This probably belongs to numpy-discussion. More below.
On 1/31/06, David M. Cooke <cookedm at physics.mcmaster.ca> wrote:
> Could we change the API so that PyArrayObject * is used as the return
Exposing the definition of the object structs is discouraged in python
code. See for example a comment in intobject.h /*The type PyIntObject
is (unfortunately) exposed here so we can declare _Py_TrueStruct and
_Py_ZeroStruct in boolobject.h; don't use this. */ In numpy this is
necessary for performance reasons so that accessors can be implemented
as macros. Making return types PyArrayObject * will likely lead
people to use direct access to struct members instead of macros.
> On a similar note: the 'data' member of PyArrayObject's is a char *,
> where it really should be a void *. Being a void pointer would have
> the advantage of not needing the cast in cases like this:
> double *adata = (double)(a->data);
I think you meant (double*)
> It would also mean that accidentally dereferencing the pointer would
> be a compiler error: currently, a->data is valid, but if a->data
> was a void *, it wouldn't be.
Note, however that implicit cast is illegal in C++ and may generate
warnings on some compilers (I think gcc -pedantic would, but not
sure). Another problem with void* is that a->data + n will become
invalid, which is used in many places if I recall correctly.
(a->data + n code is actually suboptimal when n is not constant
because most CPUs have special opcodes for pointer arithmetics that
compilers can generate if n is compile time constant)
More information about the Scipy-dev