Robert Bradshaw wrote:
> On May 7, 2009, at 5:03 AM, Dag Sverre Seljebotn wrote:
>
>> Robert Bradshaw wrote:
>>> With very few exceptions (the new division semantics being one of
>>> them), I think it's valuable that code manipulating all C types
>>> translates nearly directly to C with very little extra magic or
>>> layers. One is then free to write as nice or raw of an interface on
>>> top of that as one wishes. I think applying the same principles to C+
>>> + is a good idea.
>> OK. Variable scoping is still a problem. I'll just dump my current,
>> much
>> clearer thoughts for the record.
>>
>> 1) The "with" clause has C variable scope semantics but would be
>> kind of
>> a pain to use.
>>
>> with vector[int].iterator(vec.begin()) as it: # cdefs the "it" in
>> block
>> while it != vec.end():
>> ...
>>
>> 2) Explicit construct/destruct is a possibility:
>>
>> cdef vector[int].iterator it
>> ...
>> construct(it, vec.begin())
>>
>> destruct(it)
>> ...
>>
>> But, ugly. If you construct twice in a function or forget to destruct
>> you get to keep the pieces (often nothing bad will happen though).
>>
>> 3) Just tracking the first assignment, and destruct at end of
>> function,
>> would kind of work, but there's a problem: Basically the first
>> assignment must invoke placement new, while subsequent assignments
>> must
>> use "=".
>>
>> This could be dealt with with a seperate flag though! So you have a
>> flag
>> "is_constructed", and if it is not, use placement new for assignment,
>> otherwise use "=".
>>
>> As for eliminating such a flag, it would be easy to support
>>
>> cdef iterator it
>> it = vec1.begin() # placement new
>> if not foo:
>> it = vec2.begin() # "="
>>
>> but much more difficult to support
>>
>> if foo:
>> it = vec1.begin() # placement new
>> else:
>> it = vec2.begin() # placement new
>>
>> and impossible to do
>>
>> if foo:
>> it = vec1.begin()
>> it = vec2.begin() # placement new or "="? need a flag
>>
>> Still, using such a flag in all situations before we have control flow
>> analysis is a lot better than refcounting until we have control flow
>> analysis :-)
>>
>> Finally, we could still have an explicit
>>
>> destruct(it)
>>
>> which would also toggle the flag back, making the next assignment
>> reconstruct the object.
>>
>> This would actually work :-) (assuming void*[] is all the alignment we
>> need).
>
> I much prefer option (3), that seems both feasible and obvious to use.
Sounds like a plan. (I guess a @notassignedtoyetcheck directive is in
order too then). I'd feel it would be natural to allow
f() = 3
and
f(a) # a is modified
as well then -- why stop at 90%...
I'd like to eventually have (1) available as well a more obvious
alternative in case you *need* explicit control over when the destructor
is called, or the object is a bit big.
with DbConnection("http://...";) as db:
...
seems very natural, and this is a very common idiom in C++ (they
basically use stack allocation for both the "normal" situations, *and*
for situations where one would use "with" in Python).
It would then be natural tohave this in general, so that you could do
with cython.int(3) as a:
# locally scoped "cdef int a = 3"
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
