Re: [boost] [c++-sig] A question regarding arguments bindings

Subject: Re: [boost] [c++-sig] A question regarding arguments bindings
From: Sandeep Gupta (gupta.sandeep_at_[hidden])
Date: 2008-11-13 17:43:22

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_at_[hidden]>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
>