[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 6:42:53
Message-ID: 4E5C866D.6060809 () gmail ! com
[Download RAW message or body]

On 08/29/2011 09:41 AM, Stefan Seefeld wrote:
> On 08/28/2011 02:14 PM, Jim Bosch wrote:
>>
>> To solve it, I think you'd want anything registered by a specific
>> module to appear both in that module's registry and the global
>> registry, with the module's registry taking precedence.  Are there any
>> cases where you'd want something only to appear in the module-specific
>> registry?
>
> Anything that gets injected into the global registry is prone to violate
> the ODR. Of course, also adding it into a local registry and letting
> that have precedence may mask the ODR violation issue. But in that case,
> it isn't clear why we'd add it to the global registry at all.
>

The reason to add it to the global registry is so if you know one of the 
modules you depend on registered a converter, you don't have to do it 
yourself.

> It may make sense to define a policy that types exported explicitly by
> an extension module may be added to the global repository. In contrast,
> prerequisite types that are only by way of dependency added (e.g.,
> common libstdc++ types) should be stored in a local / private registry.
>

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.  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.

Is the problem the fact that the global registry stores function 
pointers to template instantiations?  I can see how that would appear to 
make the multiple (template) definitions more problematic, but it also 
seems like that's a problem compilers and linkers would have to have 
already solved.  Of course, this may just be wishful thinking on my 
part; I admit I'm not very familiar with how these problems are handled 
in practice.

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]