On 08/27/2011 02:08 PM, Stefan Seefeld wrote:
On 08/27/2011 04:40 PM, Dave Abrahams wrote:
Hmm. I'm guessing the global type registry would still be the
default, and per-module registries would override these when
available? It sounds like Stefan has a clear use case in mind, and
I'd be curious to know what it is.
Me too.
I believe what we were discussing at the time was a situation where an
extension module would not only define converters for its own types, but
also common types that may are required by the API. This could in
particular include common types from libstdc++.
If multiple extension modules do this, than a Python program that
happens to use them in the same application may end up with undefined
behavior (does this constitute an ODR violation under the hood ?)
To make this work, the common type converters need to be factored out
and shared. This in itself is impractical (since the original authors
may not be aware of this need). Furthermore, a converter may require
module-specific behavior, i.e. converting a std::string in the context
of one module may be different from the desired conversion in another.
Binding converters to particular modules (and requiring to explicitly
import / exporting converters) seems like a solution to the above.
That's definitely a problem that needs to be addressed. I've
encountered it too. I hope to provide more libstd++ conversions in
Boost.Python itself, which should alleviate the need for this a bit, but
it does need a proper solution.
To solve it, I think you'd want anything registered by a specific module
to appear both in that module's registry and the global registry, with
the module's registry taking precedence. Are there any cases where
you'd want something only to appear in the module-specific registry?
Jim
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
