[C++-sig] [Boost.Python v3] Features and Scope

Stefan Seefeld stefan at seefeld.name
Sat Aug 27 23:08:03 CEST 2011


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.

    Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...



More information about the Cplusplus-sig mailing list