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

[David Abrahams]

"Milind Patil" <milind_patil at hotmail.com> writes:

> But, taking the toy example a step closer to the actual class I am
> wrapping...
>
> class Y {
>   public:
>     Y() : y(0L) { }
>     Y(int y) : y(y) { }
>     Y(long long unsigned int y) : y(y) { }
>     Y(int s, const Y & y) : y(y << s/* toy usage*/) { }
>     Y(Y const& rhs) : y(rhs.y) { }
>     virtual ~Y() { }
>
>     operator int() const { return y; }
>
>     void operator=(Y const& y) {
>         this->y = y.y;
>     }
>
>     long long unsigned int y;
> };
>
> BOOST_PYTHON_MODULE(hello)
> {
>     class_< Y >("Y", init<  >())
>         .def(init< const Y & >())
>         .def(init< int, const Y & >())
>         .def(init< int >())
>         .def(init< long long unsigned int >())
>         .def_readwrite("y", &Y::y)
>         .def("__int__", &Y::operator int)
>     ;
> }
>
> This should work, ... intutively. But doesn't,  if I tried
> to execute the python code...
>
> z = hello.Y(2, 1)
>
> Why should I now need
> implicitly_convertible<int, Y>();
> for it to work?

Because:

    a). Boost.Python doesn't automatically detect that the Y(int) case
        isn't explicit (although it could on most compilers).

    b). Python itself doesn't do any implicit conversions.

It would be interesting to generate implicitly_convertible invocations
for single-argument constructors where the argument type is in fact
implicitly convertible to the destination type.  It wouldn't be
supported on CWPro7, but I plan to drop support for that old compiler
anyway.

>> > I am seeking a behaviour where python int is converted to c++ int
>> > before constructing to c++ object Y, and python long is converted
>> > to c++ long long unsigned int before constructing to c++ object Y.
>>
>> That might be difficult.  Guido and the lads are making it
>> increasingly difficult to detect a difference between Python int and
>> Python long, and plan to erase the distinction altogether soon.
>>
>> Do you really need to handle the cases differently?
>>
>
> Not explicitly. But consider if I want to do
>
> z = hello.Y(~0)
> or
> z = hello.Y(-1)
>
> This is best converted to Y(int) constructor. 

Why?

> Part of the c++ library I am wrapping is a bit vector library which
> acts like a c++ builtin type for most part. It is only when
> converting python types to the bit vector object that differences
> become visibile according to whether source type is signed or not.
>
> I read up a bit on python long and learned that it is not like the
> c++ long. It seems the python long is a structure and is not width
> bound. How does boost handle python boost to long conversion?

What is "python boost to long conversion"?  Please be specific.


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com