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...
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
