On Oct 16, 2008, at 7:20 AM, Lisandro Dalcin wrote:
> On Thu, Oct 16, 2008 at 12:43 AM, Greg Ewing
> <[EMAIL PROTECTED]> wrote:
>> Lisandro Dalcin wrote:
>>
>>> And how are you going to free the memory?
>>
>> I'm not, that's up to the programmer. It's just a
>> more convenient way of writing a malloc.
>
> Then I have to say that I'm -1 in such magic. What about introducing
> two new pseudo-keywords cnew/cdel, and use it like this (like in C++):
>
> MyStruct *p = cnew MyStruct(a=1,b=2)
> # use p
> cdel p # also sets p to NULL
> assert p==NULL
> cdel p # success, but do nothing?
>
> Such approach would make Cython/Pyrex closer to C++ behavior.
> Moreover, this could be extended to support funny features, like
> letting user choose the alloc/dealloc routines and perhaps
> constructor/destructor routines.
>
> What do you think?
First, thanks for all the feedback, and thanks Dag for bringing this up.
I'd rather focus on making Cython closer to the Python language than
introducing new concepts. Also, I'm with Stefan that it is very
dangerous to hide the malloc and expect the user to explicitly
provide the free. If the user wants to manage their own memory, they
can do so with malloc and friends (understanding the associated
dangers), and any special memory-management stuff we add should be as
implicit and easy to use as Python's garbage collection (and probably
piggyback off of it).
I think the MyStruct(...) should result in an actual struct (not a
pointer), but perhaps on conversion to an object it could be made
into a memory managed version of the struct (e.g. using the same
string allocation trick we talked about for arrays) giving C access,
pass-by-reference, and memory management. This, however, is not going
to happen in the next release of Cython and when it does it could be
made backwards compatible with the current conversion to dict.
(Syntax suggestions for how to declare such an object welcome,
perhaps "cdef object MyStruct foo" and memory-managed arrays could be
"cdef object int[] foo")
As for the current proposal, don't want to introduce new, special
"struct instanciation dictionaries," so I'd opt for allowing the
{"a": 1, "b": 2} literals with the plan of conversion from a runtime
dict down the road (including runtime-created keys), but disabling
the {a: 1, b: 2} as the MyStruct(a=1, b=2) is available (and, even
better, more explicit).
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
