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