[C++-sig] [Boost.Python v3] Features and Scope
talljimbo at gmail.com
Tue Aug 30 19:42:49 CEST 2011
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:
>> 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
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.
More information about the Cplusplus-sig