Greg Ewing wrote:
> Dag Sverre Seljebotn wrote:
>
>> (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.)
>
> But that's not overloading on return type -- it's not
> even overloading at all, since they're different
> methods.
>
> Overloading on return type would be if
>
> int a = x.foo()
>
> and
>
> float b = x.foo()
>
> were to select different versions of the foo() method
> based on their return types. I don't think C++ does
> that (although I might be wrong).
I suppose you are right. Although the *effect* can be simulated by
having foo() simply return an object with conversion operators which
call two different methods:
class Result {
public:
operator float() { return 2; }
operator int() { return 3; }
}
Result foo() { return Result(); }
int a = foo() // a == 3
float b = foo() // b == 4
foo() // nothing can happen, no side-effects possible
So the reason I end up with overloading on result type in Cython is
because then you can declare the interface while ignoring the Result
class and have things work the right way.
But it was just a throw-away idea, like I said to Robert, I'm much more
worried about
foo() = 3;
at the moment. And, if you decide to declare Result Cython-side, I'm
worried it might force support of stuff like
if True:
cdef Result result = foo() # inside block!
# destructor of result called here
and so on.
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
