[C++-sig] dynamic compile and "to-Python converter ... second conversion method ignored"

Roman Yakovenko roman.yakovenko at gmail.com
Sat Nov 21 20:05:04 CET 2009


On Fri, Nov 20, 2009 at 10:44 PM, Stefan Seefeld <seefeld at sympatico.ca> wrote:
>> Now I'm sure I've interpreted "scoping conversion operators" differently
>> than you meant it.  Can you clarify?
>
> This is mostly only hand-waving, sorry. I was wondering whether it was
> possible to make the registry not an application-global object, but a
> per-module object. And if that's possible (and thus, conversions are by
> default only available to the defining module), would it be possible to
> chain them explicitly, to get both, well-defined semantics, as well as no
> ODR violations.
>
> I haven't thought about whether this has to involve runtime overhead, and if
> so, how much. At least without the chaining it may actually be cheap. (Just
> hide the registry symbol from other modules.)
> And even with chaining, this is merely a lookup in a chain of converter
> maps, which likely can be reordered / optimized at the point where one
> registry is explicitly added to another.
> Still, this is just a rough idea. I don't have any implementation ideas yet.

IMHO, this could be the way to go. I already meat this problem in the past:
* std containers were exposed using different suites
* during the testing - initially all my tests run in the same process,
but after 30 tests it became very difficult to name C++ classes :-),
so I was forced to run every test in its own process.

The "per-module" registry could be a solution to the problem.

-- 
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/


More information about the Cplusplus-sig mailing list