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. HTH, Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
