[C++-sig] [Boost.Python v3] Conversions and Registries

Jim Bosch talljimbo at gmail.com
Mon Sep 19 23:03:43 CEST 2011


I'd like to restart the discussion on how conversions will work in 
Boost.Python v3.  Here's the starting point:

I'd like to see support for static, template-based conversions.  These 
would be defined by [partial-]specializing a traits class, and I tend to 
think they should only be invoked after attempting all registry-based 
conversions.  Users would have to include the same headers in groups of 
interdependent modules to avoid specializing the same traits class 
multiple times in different ways; I can't think of a way to protect them 
from this, but template-based specializations are a sufficiently 
advanced featured that I'm comfortable leaving it up to users to avoid 
this problem.

We've had some discussion of allowing different modules to have 
different registries (in addition to a global registry shared across 
modules).  Leaving aside implementation questions, I have a little 
survey for interested parties:

1) Under what circumstances would you want a conversion that is 
completely limited to a specific module (or a group of modules that 
explicitly declare it)?

2) Under what circumstances would you want a conversion to look in a 
module-specific registry, and then fall back to the global registry?

3) Considering that we will have a "best-match" overloading system, what 
should take precedence, an inexact match in a module-specific registry, 
or an exact match in a global registry?  (Clearly this is a moot point 
for to-Python conversion).

Finally, can anyone give me a reason why having a global registry can 
lead to a violation of the "One Definition Rule"?  This was alluded to 
many times in the earlier discussion, and there's no doubt that a global 
registry may lead to unexpected (from a given module's perspective) 
behavior - but I do not understand the implication that the global 
registry can result in formally undefined behavior by violating the ODR.

Thanks!

Jim


More information about the Cplusplus-sig mailing list