Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk