On Sun, Jan 12, 2014 at 10:40 PM, Ben Kloosterman <[email protected]>wrote:
> Thanks WIlliam > > On Mon, Jan 13, 2014 at 3:50 PM, William ML Leslie < > [email protected]> wrote: > >> Interfaces never really want to live on the heap. If implemented as >> > pairs of (this ref, vtable ref), it's cheaper to pass this around as a >> well-typed unboxed value than to stick it in the heap where it needs >> metadata to describe its allocation, as well as possibly a header for >> RTTI. >> > > Im thinking about GP programming with many objects in the heap having > members that are interfaces and these are very long lived and its very > common. So instead of create on heap , we create on stack and copy to > heap in each case. > It turns out that we don't need to do that. The ifTable is a compile-time constant, so we can ignore that part. The encapsulated object reference is just a managed pointer. What this means is that we can make interfaces into an unboxed (value) type. The only way that the interface object itself ends up in the heap is if it is contained by an object having reference type. > > Also what about interfaces to internal value objects ? >> >> Are you asking about objects whose allocation is maintained outside >> the runtime, or values living unboxed within some other value? >> > > Im asking about a value / un boxed type which is part of a heap objects . > Right. That's just like an interior managed pointer. The trickier one is an interface that references a stack-allocated unboxed value. *That*'*s* the case where we need to worry about interface lifetime constraints. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
