[C++-sig] .def(str(self)) compile problems

[Ralf W. Grosse-Kunstleve]

--- Simon Burton <simon at arrowtheory.com> wrote:

> OK here are my results. 
> Including either of these causes the problem:
> 
> # include <boost/python/str.hpp>
> # include <boost/python/numeric.hpp>

Thanks!
numeric.hpp brings in str.hpp.
I looked around in the includes a bit and here is what I think is going on:

We have

boost::python::str which is a wrapper for Python's str and
boost::python::self_ns::str which supports David's expression templates for
wrapping operators.

Near the bottom of operators.hpp I found (in the global namespace):

# ifdef BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP
using boost::python::self_ns::abs;
using boost::python::self_ns::int_;
using boost::python::self_ns::long_;
using boost::python::self_ns::float_;
using boost::python::self_ns::complex_;
using boost::python::self_ns::str;
using boost::python::self_ns::pow;
# endif

Under the assumption that BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP is defined in your
case, this introduces str in the global namespace. When inside boost::python,
the name lookup for str(self) will find boost::python::str first, which is not
what you want. You have to write self_ns::str(self) to get the right version.

I don't think there is anything special about str in this case. The same
problems will arise for the other types in the list above.

David's design if fine for compilers that support argument dependent lookup,
but I find it very confusing otherwise. To avoid headaches I'd simply use
self_ns all the time, as another poster suggested already a couple of days ago.
It's not pretty, but a sparrow in your hand is better than a dove on the roof,
as we say in Germany. :)

Cheers,
        Ralf



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250