On 08/30/2011 01:26 AM, Hans Meine wrote:
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:
std::vector<int>
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.
They aren't different as far as the One Definition Rule goes. You're
just passing different arguments to the constructor, not providing a
different definition. And I think that's true in both cases; sure, the
class_ code is much more complex, but it's still perfectly legal C++,
even across shared library boundaries.
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).
I agree with all of the above, and these could all be solved by my
proposal of having per-module registrations take precedence over gloal
registrations. Having a single optimal converter is clearly the best
solution when such a thing exists, and we can anticipate the type, so
adding more built-in converters too Boost.Python is part of the solution.
But this doesn't have anything to do with the One Definition Rule, and I
still don't see that we're having any more problems in that regard than
template libraries usually do.
Jim
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
