Date: 2000-12-09 18:54:12
> Casting a function pointer to a void* is not guaranteed to work
> Section 3.9.2 para 4 which grants you the ability to use void* to
> range of pointers specifically limits that range to pointers to
> para 1 which describes objects specifically says: "A function is
> object, regardless of whether or not it occupies storage in the way
> 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
> think I can arrange it so that you don't have to. It seems to me
> this case, the maintainer of dvect and the maintainer of ivect both
> recompile whenever either class changes anyway, so it's really
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk