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?)
> I argue below that A must have effects far beyond simple operator
> overloading.
>
>> On Apr 25, 2009, at 9:54 AM, Dag Sverre Seljebotn wrote:
>>> How would you represent my latter example in my previous mail at
>>> using C++
>>> syntax in Cython?
>> I would expose your ItemAccessor class as well as your
>> MyCollection class in the Cython declaration. This may
>> necessitate exposing the notion of a C++ reference to Cython as
>> well. At the very least, I think trying to overload on the return
>> type is bad.
>
> (Note that C++ overloading on return type in the specific case of
> the conversion operator, "operator SomeType". I.e. you can have
> "int a = x; float b = x" invoke two different methods on an x
> object to do the conversion.)
>
> 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
class MyCollection:
A __getitem__(K idx)
B __getitem__(K idx) # note: overloads on return value...
I would prefer
class MyCollection:
X __getitem__(K idx)
with X being typed to convert either to A or B.
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
