> It is not going to be too difficult. But, If I were you, I would not
> go this way. I would drop "overloading" and gave the functions
> different name.

> The interface exposed to the user is fragile and could be easily
> broken with addition/deletion of a function.

> Let me know if you still want the change.

I have another issue related to this topic :)
Please consider this case:

C++ code

class Bar
{
public:
Bar(const std::string &str);
};

class Foo
{
public:
void set(const std::string &name, bool value);
void set(const std::string &name, int value);
void set(const std::string &name, const std::string &value);
void set(const std::string &name, const Bar &value);
};


Python code

f = Foo()
f.setAttribute("alfa")


The problem here is that boost::python calls the overload with
"Bar" as argument because is the last (available) registered.
What's your opinion about this? Shouldn't the registration order
be:

-> Foo::set(const std::string &name, const Bar &value);
-> Foo::set(const std::string &name, const std::string &value);
-> Foo::set(const std::string &name, int value);
-> Foo::set(const std::string &name, bool value);

As "general rule" Bar is dependent/related from std::string because
of it's implicit convertibility?
Maybe decl_wrappers.algorithm.registration_order.is_related must
be updated according to this rule.




Shopping online? I tuoi acquisti sono pił sicuri con Internet Explorer 8