[c++-sig] A question regarding arguments bindings
Hi, My question is regarding the default behavior of the compiler when there is mismatch in the argument type between binding declaration and function declaration. By default no warning is generated. Consider following example: class A{ public: A(const B&); }; In wrapper, if by mistake (which I made in my code), i write class_<A>("A", init<B>) ; The compiler does not complain about no constructor found. Instead for reasons, beyond my understanding of boost.python, B get passed by value. My question why doesn't compiler issue at least a warning. Needless to say i am new to boost.python. My apologies if this is something trivial or well known. Thanks sandeep
Sandeep Gupta wrote:
Hi, My question is regarding the default behavior of the compiler when there is mismatch in the argument type between binding declaration and function declaration. By default no warning is generated.
Consider following example: class A{ public: A(const B&); };
In wrapper, if by mistake (which I made in my code), i write class_<A>("A", init<B>) ; The compiler does not complain about no constructor found. Instead for reasons, beyond my understanding of boost.python, B get passed by value.
My question why doesn't compiler issue at least a warning. Needless to say i am new to boost.python. My apologies if this is something trivial or well known.
I'm not entirely certain about how it works, but can easily imagine...: As A's constructor is called from Python, there needs to be code that will unpack the C++ arguments from the Python callable argument tuple, and pass it down to the constructor. That code gets instantiated by means of 'init<signature>'. Since you indicate 'Signature' to be 'B', the code will extract a B instance (by value) from the Python argument list, and pass that down to A's constructor, which the compiler happily accepts. There is just no reason the compiler would guess that this is not the intended behavior. If it was the other way around, i.e. if the compiler expected a (non-const) reference to 'B', but was fed a const B reference, it would loudly complain. HTH, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Hi Stefan, Agreed, very likely Boost.python internally is carrying out those steps. It is valid course of course of action. However, I would assume that a wrapper should be restricted to exposing known functionality to python. But now, it seems one can formulate a pass by value constructor in python when no such constructor existed in c++. Well it seems like trifling matter to some extent...and thanks for clarifying it. -Sandeep However, shouldn't the wrapper's functionality be restricted to exposing known c++ construct. On Thu, Nov 13, 2008 at 2:15 PM, Stefan Seefeld <seefeld@sympatico.ca>wrote:
Sandeep Gupta wrote:
Hi, My question is regarding the default behavior of the compiler when there is mismatch in the argument type between binding declaration and function declaration. By default no warning is generated.
Consider following example: class A{ public: A(const B&); };
In wrapper, if by mistake (which I made in my code), i write class_<A>("A", init<B>) ; The compiler does not complain about no constructor found. Instead for reasons, beyond my understanding of boost.python, B get passed by value.
My question why doesn't compiler issue at least a warning. Needless to say i am new to boost.python. My apologies if this is something trivial or well known.
I'm not entirely certain about how it works, but can easily imagine...:
As A's constructor is called from Python, there needs to be code that will unpack the C++ arguments from the Python callable argument tuple, and pass it down to the constructor. That code gets instantiated by means of 'init<signature>'. Since you indicate 'Signature' to be 'B', the code will extract a B instance (by value) from the Python argument list, and pass that down to A's constructor, which the compiler happily accepts. There is just no reason the compiler would guess that this is not the intended behavior. If it was the other way around, i.e. if the compiler expected a (non-const) reference to 'B', but was fed a const B reference, it would loudly complain.
HTH, Stefan
--
...ich hab' noch einen Koffer in Berlin...
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (2)
-
Sandeep Gupta -
Stefan Seefeld