Ah the glory that is CLI! If you are willing to sufficiently commit yourself
to barf-worthy solutions, you can accomplish almost anything. I just figured
out how to do a semantically conforming implementation of inner references.
If you have recently eaten, and are not possessed of a truly iron stomach,
you'll definitely want to come back to this note later.
This technique is required exactly if (a) you take a liveness-constrained
reference, and (b) that reference is *captured*. It *may* also be required
in some conservative corner cases, but offhand I can't think of any.
This technique does *not* work on anything that is stack allocated. If a
reference of this form is captured, it is necessary to spill the
stack-allocated item to the heap. This is essentially the same problem that
we already have for closures.
So with those two caveats:
We define an abstract base class InnerReference<T>. This class has abstract
virtual member functions
T get()
void set(T&)
Wherever an inner reference is captured in BitC, it is necessarily of the
form a.b..y.z, where 'a' is some reference type and "b...y.Z" is a
compile-time path of identifiers naming the field being captured. Note that
none of the intermediate fields "b...y.z" has reference type.
When a reference to such a field is captured, we introduce an anonymous
concrete class that is a subclass of InnerReference<T>. This concrete class
encapsulates 'a', and provides implementations of get() and set() as
follows:
T get() { return a.b....y.z; }
void set(T& t) { a.b...y.z = t; }
This anonymous class is instantiated at the point where the inner reference
is captured, and the CLI type given to the resulting inner reference is
InnerReference<T>.
Two instances of InnerReference<T> are considered EQ if (1) they encapsulate
the same outer reference 'a', and (2) they apply the same relative path of
identifiers b...y.z.
How's that for barf-worthy! Thank God it will only get called on in rare
cases!
shap, who needs to go clean the yuck out of his keyboard now.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
