Robert Bradshaw wrote: > On Apr 26, 2009, at 12:19 AM, Dag Sverre Seljebotn wrote: > >> Robert Bradshaw wrote: >>> I start with a disclaimer I should have made several posts back: >>> I have done very little programming with C++, so please excuse >>> any naiveté I have in this regard... >> Sure, but I must also expose it :-) >> >> So, to sum up the two solutions so far: >> >> A) Introduce the C++ operators to Cython. This will require adding C >> ++ semantics to the Cython language in other areas as well. >> >> B) Define C++ snippets of code which correspond to Cython operators/ >> semantics. This will only support a (natural) subset of what is >> possible to do in C++; say, as if the C++ library had been wrapped >> for the Python runtime. >> >> We seem to agree that A should use C++ syntax (that's really a >> tangential issue but is a nice peg to remember things by). > > That's a fair summary. I am also for supporting only a subset of what > is possible--if one really needs crazy stuff like differently > implemented prefix/postfix decrements and -> vs (*). one can code in C > ++ or use clever macros. (Would we need to expose ++, a.k.a > "__next__" for STL iterators?)
Yes, you need ++/-- for std::list<T>::iterator, which doesn't accept any form of +=, but we can just compile += 1 and -= 1 to those operators in general (also for plain ints for that matter), so it's not really a problem. (We are then requiring that += 1 would have the same semantics, which I'm 100% fine with.) This holds for both my and your stance BTW and is orthogonal. As for crazy .. well, I'd argue that "polygon.vertices(2) = Vertex(3,4)" is not outside the realm of what one could sanely do in C++ -- I'd go for [] myself, but that's not really up to me. Yet this is out of reach for current Cython semantics. >> Exposing ItemAccessor as is, and support its use, will have a >> dramatic effect on the Cython language, as operator= is what is >> really used here. > > I think we're going to want to support the operator= in a limited > sense that one is allowed to do conversions from one type to another > (the declaration could be totally different, and potentially the same/ > similar as whatever we settle on for "operator T()"). So rather than > the hypothetical a) I don't see where operator= enters the picture here. b) Even if you could do this, this is only hot-fixing one very specific consequence of a much larger body of problems. I have a feeling you could go around forever fixing specific cases with native Cython support and get something massively complicated (and impossible to guess) compared to my proposal for embedded C++ macros. I'll believe this will work when I see a more concrete proposal. (But at the moment, let "func(2) = 3" serve as my main worry rather than the overloading by return type -- I'll agree that that is a problem.) -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
