[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