From: rwgk_at_[hidden]
Date: 2000-12-11 10:20:38
There are again new versions of ivect.cpp, dvect.cpp, Makefile and
tst_vects.py at:
http://cci.lbl.gov/~rwgk/cvs/cvsweb.cgi/bpl_tru64/
Now there are to_python() functions in the BOOST_PYTHON_CONVERSION
namespace that use the function pointers passed in converter structs.
I have tried to cover both cases outlined at the end of my previous
message:
----------------------------------------------------------------
1. All symbols seen by the dynamic loader live in the same scope
----------------------------------------------------------------
Makefile:
# mutually exclusive: comment out exactly one line
#HIDDEN= -hidden
CPPOPTS= $(CPPOPTS) -DDL_ALL_IN_ONE_SCOPE
In this case, to_python() is only declared but not defined.
Unfortunately,
importing ivect from dvect or vice versa fails. See, e.g., dvect.cpp:
#ifdef DL_ALL_IN_ONE_SCOPE
//if (PyImport_ImportModule("ivect") == 0)
// throw python::error_already_set();
// Result:
// Assertion failed: name_holder.get() == 0, file module_builder.cpp,
line 33
#endif
The workaround is to import ivect explicitly in tst_vects.py.
> Probably the best solution would chain the name_holders into a
> stack, in case a module might be initialized during another module's
> initialization.
I guess this would help me, too!
----------------------------------------------------------------------
-----
2. The symbols seen by the dynamic loader do not all live in the same
scope
----------------------------------------------------------------------
-----
Makefile:
# mutually exclusive: comment out exactly one line
HIDDEN= -hidden
#CPPOPTS= $(CPPOPTS) -DDL_ALL_IN_ONE_SCOPE
In this case, to_python() is a wrapper that imports and uses a pointer
to the actual converter via a PyCObject.
This case works perfectly even without the explicit import ivect at
the beginning of tst_vects.py.
I have not yet tried to import from_python converters. Is this likely
to work in a similar way?
David wrote:
> Finally, I don't think one should pay the price of exporting these
> converters by default, for every class, so I think class_builder<>
> should have an export_converters() member function which does the
> export.
If the PyCObject is not in the module's __dict__, but only generated
"on demand" when the module.class.__converters__ hook is called,
what exactly is price to pay?
If the converters are not provided by default, I would most likely
export everything explicitly anyway. Otherwise I would find myself
having to go back again and again, recompiling modules only to make
the converters accessible. Or worse, I might have to ask the people
who do not want to share the C++ source to send new binaries, only
to get access to the converters.
David suggested:
import_converters<X> import_x("x", "X");
import_reference_converters<X> import_x("x", "X");
Can this be done so that the two cases above are covered without the
user having to think about the difference?
Thanks!
Ralf