Re: [C++-sig] boost ref problem

2012-02-07 Thread Jim Bosch 

On 02/06/2012 08:33 PM, Jay Riley wrote:


I'm trying to wrap a C++ class into python. I need to pass an enum value by 
reference through a virtual function. I'm doing it like so (non relevant code 
omitted):

class BasicRMLScreenWrap : public BasicRMLScreen{   public: 
   bool HandleKeyPressedDefault(const sf::Uint32 time, const ::Input::InputModule* inputModule, 
::Input::PlayerInput pinput, ::Input::InputAction&  iaction){   
return BasicRMLScreen::HandleKeyPressed(time, inputModule, pinput, iaction);
}   bool HandleKeyReleased(const sf::Uint32 time, const ::Input::InputModule* 
inputModule, ::Input::PlayerInput pinput, ::Input::InputAction&  iaction) override  
  {   return call_method(self, 
"HandleKeyReleased", time, ptr(inputModule), pinput, boost::ref(iaction));
   }  private: PyObject* self; };
class_, boost::shared_ptr, 
boost::noncopyable>("BasicRMLScreen", init())  
.def("HandleKeyPressed",&BasicRMLScreen::HandleKeyPressed,&BasicRMLScreenWrap::HandleKeyPressedDefault)   
;
the problem is that when I wrap it like this, I get the following error:
Error   74  error C2664: 'boost::mpl::assertion_failed' : cannot convert parameter 1 
from 'boost::mpl::failed boost::mpl::or_::* ***' to 
'boost::mpl::assert::type'

if I switch boost::ref(iaction) to iaction it compiles fine, but I need to pass 
it by ref for correct behaviour. I'm not sure if this is a boost::ref problem 
or a boost python issue but was curious if someone might have an idea how to 
correct it. I can pass using boost:ref fine in the other places ive used it 
with call_method. Is this is an issues because it's an enum?
Any help would be appreciated,


I'm afraid you're run into a bit of an impossible problem.  Boost.Python 
only defines rvalue from-python converters for enums, and this actually 
makes sense - like int, float, and str in Python, enums are immutable 
Python objects; when you set them, you're really just assigning the name 
of the variable to a new object.  There's really no way to express 
modifying an argument in-place in Python when the argument is an 
immutable object.


I think you'll manually have to transform the signature to return the 
new enum value in Python (i.e. make a derived class that implements the 
enum ref virtual member function by delegating to a new enum-returning 
virtual member function that you can wrap).


Jim

___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] How to define a Python metaclass with Boost.Python?

2012-02-07 Thread Jim Bosch 

On 02/07/2012 01:35 AM, paulcmnt wrote:

The Python C API has the `PyObject *PyType_Type` object, which is equivalent
to `type` in the interpreter. If I want to define a metaclass in C++, how
can I set `type` as one of its bases in Boost.Python? Also, what other
things should I take into consideration when defining a Python metaclass in
C++? It'd be ideal if there was a Boost.Python solution to this. If not, a
solution that uses the Python C API (or a combination of Boost and the C
API) is good as well. (The version I'm using is Python 3.)



I'm afraid this isn't really supported.  All Boost.Python classes have 
to use a specific Boost.Python metaclass that's defined deep in the 
bowels of some Boost.Python source file, and there's really no way to 
override that at present.


This might be a nice feature for the future, but I haven't thought too 
deeply about how to make it work or why one would want to do it.  If you 
have a specific use case for a custom metaclass, I'd love to hear what 
it is.


Jim
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig

Re: [C++-sig] How do I make correct wrappers to interfaces while using shared_ptrs?

2012-02-07 Thread Jim Bosch 

On 02/05/2012 07:49 PM, Adam Preble wrote:


Would using register_ptr_to_python explicitly and consistently instead of
the online shared_ptr declaration potentially eliminate some side-effects?
I cannot yet isolate why my real app crashes in python when it tries to do
an eval into one of my wrappers.


Overall, I doubt it.  Usually putting shared_ptr in the class_ template 
params would allow you to do more fancy shared_ptr tricks, not less. 
And as I said before, it might be necessary if you use 
enable_shared_from_this.


What your previous example showed, though, was that it might be useful 
to use register_ptr_to_python on every type you ever make a shared_ptr 
to in C++ *in addition* to putting shared_ptr in the class_ templates - 
you'll get some warnings in Python about redundant converters, and those 
will tell you which of those extra declarations it's safe to remove. 
Any that remain might help fix your problem.


Jim
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig