[C++-sig] [Boost.Python v3] Features and Scope

Jim Bosch talljimbo at gmail.com
Tue Aug 30 20:06:50 CEST 2011


On 08/30/2011 04:04 AM, Stefan Seefeld wrote:
> On 08/30/2011 02:42 AM, Jim Bosch wrote:
>> 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.
>
> As I suggested in reply to Dave, I think it would be better to require
> modules that depend on  external converters to explicitly import them.
>

I can understand the motivation for requiring manual imports of 
conversions, as a sort of "explicit is better than implicit" argument.

But I don't think it saves us anything in terms of ODR violations.

If I'm understanding the ODR issue (or lack thereof) correctly, we can 
make everyone mostly happy by providing an option whether conversion 
registrations should go into a per-module registry, a global one, or 
both.  We'd then allow modules to import the per-module registry of 
another module into their own if they like.  In all cases, we'd look up 
things in the per-module registry first, and then go to the global 
registry (where things registered by class_ would typically go).

I don't like the idea of Python users being able to tell all modules to 
use a different set of conversions than the ones their authors intended. 
  That seems fraught with peril, and unnecessary if module builders can 
pull converters from modules they depend on.

Jim



More information about the Cplusplus-sig mailing list