Re: [pygccxml-development] USE_CALLDEF_ORGANIZER

[Roman Y. <rom...@gm...>]

On Wed, Jan 27, 2010 at 5:45 PM, Berserker <ber...@ho...> wrote:
>> 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.

No. I can't change the algorithm, because it will break backward compatibility.

As I said, if you have such problems you'd better avoid them by
changing the alias of the exposed functions. As you can see, a
developer can add a new constructor and as the result other function
will be called. This is hard to find problem.

Don't you think so?

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/