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 > > > in two shared libraries doesn't seem any different from instantiating > something like: > > std::vector > > 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 >(…) will generate the same code in both cases. For std::vector, this holds, but for class_< std::vector >(…), 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 writability/modifications). HTH, Hans _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig