[C++-sig] Re: Using .add_property with make_getter.

[David Abrahams]

Kirsebom Nikolai <nikolai.kirsebom at siemens.no> writes:

> I have the following c++ class:
> class PyDLEPRInterface : public DLEPRInterface
> {
> public:
> 	PyDLEPRInterface();
> 	PyDLEPRInterface(const PyDLEPRInterface& objectSrc);
> };
>
> PyDLEPRInterface::PyDLEPRInterface(const PyDLEPRInterface& objectSrc)
> {
> }
>
> PyDLEPRInterface::PyDLEPRInterface()
> {
> }
>
> The class DLEPRInterface defines some public attributes, example
> 	CString m_DocumentCategory;
> 	int m_UserID;
>
>
> I have a converter for converting CString <--> python string.
> See code in thread "Exception second time loaded" 20th of June.
>
> The two attributes are exposed with the statements:
> 	.def_readonly("UserID", &PyDLEPRInterface::m_UserID)
> and
> 	.add_property("DocumentCategory",
> make_getter(&PyDLEPRInterface::m_DocumentCategory,
> return_value_policy<return_by_value>()))
>
> When running in Python, the UserID is available 

What does "available" mean?

> however reading the DocumentCategory attribute produces the
> following traceback:
>
> import DocuLive  #<<Module exposing function to get an existing
> PyDELEPRInterface object
> import CString #<<Module handling the conversion
> v = DocuLive.getit() #<<Fetch the exisiting object
> v.UserID #<<Print the value for UserID attribute
> 44
> v.DocumentCategory 
> Traceback (most recent call last):
>   File "<input>", line 1, in ?
> TypeError: bad argument type for built-in operation

Can you post a complete, minimal test case that we can use to
reproduce the problem?

> I'm running the python statements in a PyCrust (wxPython/wxWindows)
> shell application.  In my posting 20th of June I asked for help
> relating to exception when staring the second time.  It appears that
> the starting of the mainloop in the PyCrust application produces the
> exception if other applications (in Windows) has been activated in
> between.  

I don't know what that means, but I can tell you that if you want to
initialize the same Boost.Python extension modules a 2nd time, the
Boost.Python DLL must be unloaded first.  I don't know what it takes
to do that, but I'm guessing we have a problem because it gets
referenced by each of the BPL extension modules which is loaded, and
they in turn are being kept alive because no PyFinalize() is being
called, because we don't support PyFinalize() yet.  Dirk Gerrits has
been working on a solution, but has been waylaid.  It's an important
feature to get implemented, but Boost Consulting has to focus on
projects which have been funded.


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com