On Fri, Mar 19, 2010 at 6:42 PM, Maciej Sitarz wrote:
>
> Hi all,
>
> I want to create python module for class that has protected operator=.
> That class placed in std::vector and code generated by Py++ uses that
> operator.
I could be wring, but if I remember right, you can not use such
classes
On Fri, Mar 19, 2010 at 1:27 AM, Maciej Sitarz wrote:
> On 17.03.2010 08:52, Roman Yakovenko wrote:
>>
>> Nothing, really.
>>
>> Please take a look on the following document:
>>
>> http://language-binding.net/pyplusplus/documentation/tutorials/module_builder/module_builder.html#declarations-custom
On 20.03.2010 19:12, Roman Yakovenko wrote:
On Fri, Mar 19, 2010 at 6:42 PM, Maciej Sitarz wrote:
Hi all,
I want to create python module for class that has protected operator=.
That class placed in std::vector and code generated by Py++ uses that operator.
I could be wring, but if I remembe
On Sat, Mar 20, 2010 at 9:15 PM, Maciej Sitarz wrote:
> On 20.03.2010 19:12, Roman Yakovenko wrote:
>>
>> On Fri, Mar 19, 2010 at 6:42 PM, Maciej Sitarz wrote:
> The compile errors are still the same:
> generated.cpp:40: instantiated from here
> test.h:6: error: 'JobPropertyWrapper& JobProperty
On 20.03.2010 20:47, Roman Yakovenko wrote:
On Sat, Mar 20, 2010 at 9:15 PM, Maciej Sitarz wrote:
On 20.03.2010 19:12, Roman Yakovenko wrote:
On Fri, Mar 19, 2010 at 6:42 PM, Maciej Sitarzwrote:
The compile errors are still the same:
generated.cpp:40: instantiated from here
test.h:6: e
On Sat, Mar 20, 2010 at 10:12 PM, Maciej Sitarz wrote:
> On 20.03.2010 20:47, Roman Yakovenko wrote:
> Em... but the example main() compiles and works... unless I want to
> 'push_back' object to the vector.
This is exactly my point
>> I think, you will have to change your code.
>
> I could chan
Hello,
I'm having some issues with shared_ptr's in a Python environment: it
looks like once a shared_ptr enters Python, it cannot be upcasted nor
downcasted.
Here's a brief C++ source code to explain better the issue:
#include
class Base { };
class Derived : public Base { };
boost::shared_pt
On 20.03.2010 21:24, Roman Yakovenko wrote:
On Sat, Mar 20, 2010 at 10:12 PM, Maciej Sitarz wrote:
On 20.03.2010 20:47, Roman Yakovenko wrote:
I think, you will have to change your code.
I could change it in the example, but I can't change the code for which I'm
making the python module.
I
On Sat, 2010-03-20 at 21:31 +0100, peoro wrote:
> Hello,
>
> I'm having some issues with shared_ptr's in a Python environment: it
> looks like once a shared_ptr enters Python, it cannot be upcasted nor
> downcasted.
>
> Here's a brief C++ source code to explain better the issue:
>
>
> #include
Just one more comment...
The constructor takes reference to vector, so I
suspect that maybe it will be filled there by some other code I don't
have? So I don't need to fill the vector, just to create it (I will ask
the developers)
Additional source + documentation (but no details ):
http://g
Do Boost.Python-generated extension modules conform to PEP 384's
constraints for ABI compatibility?
Thx,
Skip Montanaro
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Yes, having all of the objects at their most-derived type would be
what I need, but it's not what happens.
I posted a piece of C++ code that shows what I do (I exported it using
py++ without any further modification): all of the pointers my
functions return are wrapped in boost::shared_ptr's, but
On Sat, Mar 20, 2010 at 11:10 PM, Maciej Sitarz wrote:
> Just one more comment...
>
> The constructor takes reference to vector, so I suspect
> that maybe it will be filled there by some other code I don't have? So I
> don't need to fill the vector, just to create it (I will ask the developers)
R
On Sun, 2010-03-21 at 03:07 +0100, peoro wrote:
> Yes, having all of the objects at their most-derived type would be
> what I need, but it's not what happens.
>
> I posted a piece of C++ code that shows what I do (I exported it using
> py++ without any further modification): all of the pointers my
On Sun, Mar 21, 2010 at 4:07 AM, peoro wrote:
> Yes, having all of the objects at their most-derived type would be
> what I need, but it's not what happens.
>
> I posted a piece of C++ code that shows what I do (I exported it using
> py++ without any further modification): all of the pointers my
>
15 matches
Mail list logo