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

Niall Douglas s_sourceforge at nedprod.com
Tue Aug 30 20:14:49 CEST 2011

On 30 Aug 2011 at 10:42, Jim Bosch wrote:

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

What I have done in my own libraries is to have per-process type 
registries keep their data on the basis of shared object or DLL. The 
"current" SO/DLL can be determined by having an inlined thunk 
template function pass in the address of some guaranteed per SO/DLL 
data e.g. a static char * does just fine. One then looks up the 
pointer address in a list of loaded SO/DLLs so one knows in which 
context a particular type resolution is being performed.

This sounds like a lot of complexity, and at the start getting the 
data storage right does take time, but in the long run it saves huge 
amounts of complexity. Once it's working it's a god send because 
third parties libraries - which often break ODR whether intentionally 
or unintentionally - work as expected.

I have a whole load of code implementing this in open source if 
consulting an implementation would be useful to you, and of course 
I'm always here by email. Long time members of this mailing list will 
know what I'm referring to.


Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 

More information about the Cplusplus-sig mailing list