|
|
At 12:28 PM 7/25/03 +0200, Andre Louw wrote:
>Sorry for not making myself clear, I realize I would not need to implement
>MakeScheduler.
>Yr example triggered me to think of something else I'm doing where a
>conversion operator would work very nicely.
>SWIG does not directly support the concept of conversion operators, is there
>another mechanism/hook I can use to get a similar result?
Andre,
the problem is not SWIG, it's the semantics of Python.
In C++, if you write:
Foo f;
f = Bar();
the object "f" remains a Foo, and a conversion operator is called so that
the Bar is transformed into a Foo. In Python, if you write:
f = Foo()
f = Bar()
what you are doing is discarding the Foo object and rebinding the variable
"f" to the Bar object. The same applies to most other languages supported
by SWIG.
Therefore, automatic conversion between any two types is simply not possible.
What you can do if you have two classes such as:
class Foo {};
class Bar {
public:
operator Foo() { ... }
};
is to export them to SWIG as:
class Bar {};
class Foo {
public:
%extend {
Foo(const Bar& b) { return new Foo(b); }
}
};
Be aware though that in Python you'll have to use explicit conversion,
i.e., you'll have to write:
Bar b
f = Foo(b)
Later,
Luigi
|
Locked
