[C++-sig] dynamic compile and "to-Python converter ... second conversion method ignored"
Stefan Seefeld
seefeld at sympatico.ca
Fri Nov 20 18:29:27 CET 2009
On 11/20/2009 11:47 AM, troy d. straszheim wrote:
> Stefan Seefeld wrote:
>>
>> (It's a global symbol that is seen by all DSOs. Having two DSOs
>> provide that symbol, but with different content, is illegal.)
>>
>
> I'd like to fix this, now, it is starting to cause me pain.
>
> For instance, it also rears its ugly head if you import two libraries
> that both wrap std::vector<double>, for instance if you try to use the
> IceTray physics analysis suite together with Paul Kunz's wonderful
> Hippodraw.
>
> Another situation that came up recently was that the pair<T,U> inside
> std::map<T, U> and another container of T,U (that used pair<T,U>
> internally) collided. I think it should be possible to specify that a
> type's wrapper is replaceable (if you know, for instance, that two
> projects wrap std::pair<string,int> the same way).
>
> I haven't thought about the interface much yet.
It's an interesting thought, but it raises a lot of questions, and opens
a huge can of worms. (Welcome in the world of 'DLL hell' !)
I'm not sure what angle to attack this problem from. In particular, I
believe before thinking about interface issues, we should clarify the
problem domain, and in particular, what semantics we want.
For example, what does 'replaceable' mean ? Does it mean two bindings
are identical or equivalent ? Does it merely mean the user allows the
mapping to change ? (This would lead into undefined behavior, if you
don't carefully control in which order things are loaded / initialized.)
A different approach might be to avoid collisions by 'scoping'
conversion operators, so they are only available to specific extension
modules. May a converter registry be explicitly imported into a module,
during initialization ?
That would involve making dependency between extension modules explicit
("module X imports converters provided by module Y"). In general, I
think that would be cleanest. "Explicit is better than implicit." I'm
sure David would like that. ;-)
Regards,
Stefan
--
...ich hab' noch einen Koffer in Berlin...
More information about the Cplusplus-sig
mailing list