On 11/20/2009 03:23 PM, troy d. straszheim wrote:
For example, what does 'replaceable' mean ? Does it mean two bindings
are identical or equivalent ?
No it means only that the behavior in the situation above is modified.
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.)
UB as in what happens when there is an ODR violation? How?
I'm only talking about user-visible behavior, and assuming that it could
be implemented in a way that would avoid ODR violations.
(Whether that's actually possible is a different matter. I'm only
talking about semantics.)
A different approach might be to avoid collisions by 'scoping'
conversion operators, so they are only available to specific
extension modules.
Interesting idea. As I interpret "scoping conversion operators", I'm
not sure the cost in runtime and complexity would be worth it, OTOH I
don't have much to go on here.
> May a converter registry be explicitly imported into a module,
during initialization?
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.
That would involve making dependency between extension modules
explicit ("module X imports converters provided by module Y").
But, you can do that now; "module X imports the converter for T
provided by module Y" just means "module X doesn't wrap T and won't
run without Y", right?
Yes. I'm talking about the case where module X and module Y provide a
converter for T, so the user who wishes to use X and Y needs to specify
the desired behavior, which could be "each uses its own" or "either of
the two will be used globally".
Stefan
--
...ich hab' noch einen Koffer in Berlin...
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
