On 5 Oct 2011 at 7:21, Dave Abrahams wrote: > >> 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. > > > > Surely not! You'd want to let template specialisaton be the first > > point of call so the compiler can compile in obvious conversions, > > *then* and only then do you go to a runtime registry. > > I don't understand why you guys would want compile-time converters at > all, really. Frankly, I think they should all be eliminated. They > complicate the model Boost.Python needs to support and cause confusion > when the built-in ones mask runtime conversions.
What I was proposing was that the compile-time registry is identical to the runtime registry. Hence the order of lookup so a lot of the simpler conversion can be done inline by the compiler. Sure, the same system can be abused to have special per-compiland behaviours. I personally have found that rather useful for working around very special situations such as compiler bugs. I agree that you shouldn't have two separate systems, and 99% of the time both registries need to do the same thing. In my own code in fact I have a lot of unit tests ensuring that the compile-time and run-time registries behave identically. > > Imagine the following. Program A loads DLL B and DLL C. DLL B is > > dependent on DLL D which uses BPL. DLL C is dependent on DLL E which > > uses BPL. > > Jeez, I'm going to have to graph this > > A > / \ > B C > | | > D E > \ / > BPL You can't guarantee that Dave. It depends on what flags to dlopen the end user uses. And right now, Python itself defaults to multiple BPLs. > > Right now with present BPL, we have to load two copies of BPL, one > > for DLL D and one for DLL E. They maintain separate type registries, > > so all is good. > > That's not correct. Boost.Python was designed to deal with scenarios > like this and be run as a single instance in such a system, with a > single registry. http://muttley.hates-software.com/2006/01/25/c37456e6.html There are plenty more all over the net. > > But what if DLL B returns a python function to Program A, which then > > installs it as a callback with DLL C? > > OMG, could you make this more convoluted, please? No, it's a valid use case. Again, search google and you'll see. Lots of people with this same problem. > > As I mentioned earlier, this is a very semantically similar problem > > to supporting multiple python interpreters anyway with each calling > > into one another. > > How exactly is one python interpreter supposed to "call into" another > one? Are you suggesting they have their own threads and one blocks to > wait for the other, or is it something completely different. Right now BPL doesn't touch the GIL or current interpreter context. I'm saying it ought to manage both, because getting it right isn't obvious. And once again, if program A causes the loading of two DLLs each of which runs its own python interpreter, you can get all sorts of unfun when the two interpreters call into one another. 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
