[C++-sig] Re: long long unsigned issue...

Milind Patil 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
> more?

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.

For example

.def( self + self)


implicity_convertible<char *, Y>();
implicity_convertible<int, 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
Y class.

> 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
virtual methods.

> 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 mailing list