[C++-sig] [Boost.Python v3] Features and Scope
hans_meine at gmx.net
Tue Aug 30 10:26:49 CEST 2011
Am Dienstag, 30. August 2011, 08:42:53 schrieb Jim Bosch:
> I don't see how having a global registry makes things any worse from an
> ODR perspective. It seems like it's mostly just the same "where do
> templates get instantiated" problem that compilers and linkers always
> have to deal with.
There is a big difference in the case that two separate extensions (want to)
use different converters, though.
> In other words, instantiating something like:
> class_< std::vector<int> >
> in two shared libraries doesn't seem any different from instantiating
> something like:
> in two shared libraries, and we basically always have to leave it up to
> the compiler/linker to solve the latter.
Here you assume that class_< std::vector<int> >(…) will generate the same code
in both cases. For std::vector<int>, this holds, but for
class_< std::vector<int> >(…), the (…) part—which you left out—is crucial.
In practice, it happened to me with two extensions which did not even agree on
the /type/ of converter (class_ vs. rvalue) for the same class
(vigra::TinyVector, a small fixed-size vector).
Although it would be nice to fix/allow this (local registries, which can still
be imported/reused as a dependency), it /may/ be an even better fix to change
the extensions and make them agree on the "optimal" converter. (The obvious
problem is of course the definition of "optimal" which may be different
depending on the application.) The problem with this is the very reason for
the variety of std::vector converters out there (e.g. focusing on conversion
to native Python types, conversion speed, or in-place
More information about the Cplusplus-sig