Re: [Boost Python Library] Mixing types wrapped in different modules

From: rwgk_at_[hidden]
Date: 2000-12-09 18:54:12

> Casting a function pointer to a void* is not guaranteed to work 
portably.
> Section 3.9.2 para 4 which grants you the ability to use void* to 
hold a
> range of pointers specifically limits that range to pointers to 
objects. 1.8
> para 1 which describes objects specifically says: "A function is 
not an
> object, regardless of whether or not it occupies storage in the way 
that
> objects do." I would prefer a portable solution, wouldn't you?

Part of the plan is to store the to_python and from_python function 
pointers inside a struct, and pass a pointer to the struct via a 
PyCObject. Wouldn't that be portable?

> In any case, wouldn't you prefer not to have to do all this manual 
work? I
> think I can arrange it so that you don't have to. It seems to me 
that in
> this case, the maintainer of dvect and the maintainer of ivect both 
have to
> recompile whenever either class changes anyway, so it's really 
unclear what
> you're gaining by breaking them into separate modules.

Recompilation should be necessary only if the definition of the 
member data is changed. I am not sure about the consequences of 
changing the interface (e.g., adding a new function member). My 
feeling is that it should still work without recompiling. Fixing bugs 
in function members also would not require recompiling the module 
that imports. Please correct me if these assumptions are wrong.

However, just avoiding the need for maintaining a mega-module in a 
multi-developer-group project is enough motivation for me to pursue 
this further. The final goal is to instantiate appropriate to_python
() and from_python() functions with a single template instantiation.

Ideally, the PyCObject with the function pointers would not appear in 
the module's __dict__, but would be accessed as, e.g. 
ivect.ivect.__converters__. This would be similar to 
the "__safe_for_unpickling__" hook in classes.cpp. Of course, the 
__converters__ hook should exist by default, so that the end-user 
never has to worry about this.

Ralf