[C++-sig] Re: long long unsigned issue...
milind_patil at hotmail.com
Thu Jun 5 09:02:35 CEST 2003
"David Abrahams" <dave at boost-consulting.com> wrote in message
news:uy90p3nmp.fsf at boost-consulting.com...
> "Milind Patil" <milind_patil at hotmail.com> writes:
> My point is that this is a *very* big toy, with lots of constructors
> which look like they could potentially contend for the same input
> arguments. Can't you reduce the problem you're having a little bit
Yes, realize that the example class had lots of constructors. But the
original class that I am wrapping is huge. The constructor contention
is part of my problem as I struggle to get types accross C++ and
python to match up. I want my python wrapper to behave like the
C++ class I am wrapping with very few caveats.
> Do you need *implicit* conversion capability? Remember that implicit
> conversions are generally un-Pythonic.
I was trying to save myself the tiresome chore of writing operator .defs
for the matrix of different types and operators that the class supports.
.def( self + self)
implicity_convertible<char *, Y>();
implicity_convertible<unsigned int, Y>();
would save me
.def(self + other<char *>())
.def(other<char *>() + self)
.def(self + other<int>())
.def(other<int> + self)
.def(self + other<unsigned int>())
Isn't this a common use case scenario for boost python -- Mapping
C++ class which behaves like numeric types to python numeric
type like behaviour?
> > Now that we have a long_ to Y_Wrapper constructor
> > and that class_ Y has Y_Wrapper as one of the bases
> You got that backwards. Y is the base of Y_Wrapper.
My fault. I mistakenly thought that the "class_< Y, Y_Wrapper >("Y", init<
part of module definition meant Y, and Y_Wrapper are bases of the python
> The right solution to this problem is to provide for something Ralf
> has been requesting for some time: the ability to inject new
> constructors into a class, just the way we can inject methods that
> aren't built from member functions. Something like:
> Y Y_from_pylong(long_ y)
> return Y(extract<unsigned long long>(y));
> .def("__init__", constructor(Y_from_pylong))
I think such a class constructor injector will really be useful for
doing converters in a simple way.
> > a) Expose C++ classes as python classes alone. User will not derive
> > from the exposed classes.
> > b) Expose C++ classes as derivable classes in python.
> a and b are equivalent as far as the library is concerned.
Isn't there a difference in how a user wraps a class with virtual functions
one without virtual functions -- in the scenario where the user expects the
python class to be extended? My interpretation of docs was that a Y_Wrapper
class holding a PyObject* as a member is needed to wrap the Y class with
> I'm confused. Why do you want more info on c) if you don't use
> Boost.Python that way?
I do use the embedded + extension scenario. I don't have to reference
or derive from the python classes in the C++ that embeds the python
extension and I
don't have to derive from the c++ classes in python.
More information about the Cplusplus-sig