Stefan Seefeld wrote:
It's an interesting thought, but it raises a lot of questions, and opens
a huge can of worms. (Welcome in the world of 'DLL hell' !)
I'm not sure what angle to attack this problem from. In particular, I
believe before thinking about interface issues, we should clarify the
problem domain, and in particular, what semantics we want.
I thought this was obvious, sorry. The 'worst' and most common scenario
is, precisely put: more than one python extension module over which we
have no control has wrapped type T. We need to use them simultaneously.
For instance, here are two modules that both wrap vector<double>.
With assertions enabled, this happens:
>>> import converter_collisions1_ext
>>> import converter_collisions2_ext
python:
/home/troy/Projects/boost/src/libs/python/src/converter/registry.cpp:212:
void boost::python::converter::registry::insert(PyObject* (*)(const
void*), boost::python::type_info, const PyTypeObject* (*)()): Assertion
`slot->m_to_python == 0' failed.
zsh: abort python
delightfully, without assertions there is only a warning:
>>> import converter_collisions1_ext
>>> import converter_collisions2_ext
__main__:1: RuntimeWarning: to-Python converter for std::vector<double,
std::allocator<double> > already registered; second conversion method
ignored.
So one resolution is to remove the 'assert' that triggers this crash and
leave the semantics as-is: second and later converter registrations are
warned about and ignored. I'm simply suggesting we give the user more
control over this behavior, because in a number of situations (it is up
to the user to determine what they are) such control would be useful.
For example, what does 'replaceable' mean ? Does it mean two bindings
are identical or equivalent ?
No it means only that the behavior in the situation above is modified.
Does it merely mean the user allows the
mapping to change? (This would lead into undefined behavior, if you
don't carefully control in which order things are loaded / initialized.)
UB as in what happens when there is an ODR violation? How?
A different approach might be to avoid collisions by 'scoping'
conversion operators, so they are only available to specific extension
modules.
Interesting idea. As I interpret "scoping conversion operators", I'm
not sure the cost in runtime and complexity would be worth it, OTOH I
don't have much to go on here.
> May a converter registry be explicitly imported into a module,
during initialization?
Now I'm sure I've interpreted "scoping conversion operators" differently
than you meant it. Can you clarify?
That would involve making dependency between extension modules explicit
("module X imports converters provided by module Y").
But, you can do that now; "module X imports the converter for T provided
by module Y" just means "module X doesn't wrap T and won't run without
Y", right?
-t
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
