Sturla Molden, 25.10.2009 17:10: > Stefan Behnel skrev: >> The page mentions things like dynamic memory allocation happening >> automatically behind the scenes, so that >> >> cdef int a[runtime_size] >> >> would locally allocate memory, as would subsequent slicing, I guess. > This by the way, can be deferred to the C or C++ compiler: > > C99: int a[runtime_size]; > > C++: std::vector<int> dummy(runtime_size); > int *const a = &dummy[0]; > > For ANSI C one can use the alloca function available for most compilers: > > C89: int *const a = (int*)alloca(runtime_size*sizeof(int));
Yes, there are two types of arrays: those that only live inside of a function, and those that leave the function context in one way or another. The above would be nice for the first, whereas the wiki page refers more to a ref-counted array type. That's why I said that the SIMD type would eliminate most of that requirement. >> Since we already agreed to get a full-featured SIMD type, what do you think >> about dropping the dynamic memory handling part for plain C arrays, and >> instead just supporting slicing operations on any C pointer type, and >> letting them return a Python list? (or a byte string in the special case of >> a char*) >> > I have programmed a lot in Fortran 95, where this kind of slicing is > available. I think slicing a pointer (if it can be done fast without > Python overhead) has its merits. But I think returning Python lists are > generally too expensive. I'd rather have a pointer slicing return a > Py_buffer struct referencing the memory. ... which would, in turn, require some kind of memory management for the Py_buffer, so that's not any better than the SIMD type. > If it is assigned to a list > variable, then you get a list contructed. That would require a typed list variable, though. There should also be a default way of coercing a C array to a Python object. I find a list the least surprising here, although a view object would certainly be more efficient, with the obvious drawback of requiring the array to stay alive at least as long as the view. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
