[C++-sig] [Boost.Python v3] Features and Scope
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