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 at:

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

1. All symbols seen by the dynamic loader live in the same scope

# mutually exclusive: comment out exactly one line
#HIDDEN= -hidden

In this case, to_python() is only declared but not defined.
importing ivect from dvect or vice versa fails. See, e.g., dvect.cpp:

    //if (PyImport_ImportModule("ivect") == 0)
    // throw python::error_already_set();
// Result:
// Assertion failed: name_holder.get() == 0, file module_builder.cpp,
line 33

The workaround is to import ivect explicitly in

> 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

# mutually exclusive: comment out exactly one line
HIDDEN= -hidden

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

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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at