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).
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
