[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-cpp-sig
Subject:    Re: [C++-sig] [Boost.Python v3] Features and Scope
From:       Jim Bosch <talljimbo () gmail ! com>
Date:       2011-08-30 17:42:49
Message-ID: 4E5D2119.20307 () gmail ! com
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]