On Fri, Jun 17, 2016 at 8:37 AM, Skip Montanaro
<skip.montan...@gmail.com> wrote:
>
> >>> pro2 = service.Provider("Skip-hacking", {})
> ArgumentError Python argument types in
> Provider.__init__(Provider, str, dict)
> did not match C++ signature:
> __init__(boost::python::api::object, std::string,
> std::map<std::string, resource::variant, std::less<std::string>,
> std::allocator<std::pair<std::string const, resource::variant> > >,
> int)
> __init__(boost::python::api::object, std::string,
> std::map<std::string, resource::variant, std::less<std::string>,
> std::allocator<std::pair<std::string const, resource::variant> > >)
> __init__(boost::python::api::object, std::string)
> [<stdin>|<module>|1]
After a bit more digging I think I found the problem, but am unclear
how to solve it. Down a couple levels of dependencies there is a
resource library in which a variant class is defined. It can contain
int, string or bool objects, and uses a discriminator to decide which
field is active. Kind of a union but without overlapping fields. (I
make no comment on this class. It is what it is. I just have to live
with it.) Structurally, it looks like this:
class variant {
public:
...
enum Which {
NONE = 0x00,
INT = 0x01,
STR = 0x02,
BOOL = 0x03
};
...
private:
Which which_;
int i_;
std::string s_;
bool b_;
}
Somewhere along the way, someone needed to use one of these variants
in a context where two variants needed to be compared, so a public
operator< method was added. The data layout of the class instances
didn't change. My programs were happily communicating with a server
running the newer version of the class while it still relied on the
older version.
The addition of that public operator< method is what seems to have
tripped up Boost.Python. Is there some way to convince it to accept
the version of the variant class which contains this method?
Thx,
Skip
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
https://mail.python.org/mailman/listinfo/cplusplus-sig
