www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - object - interface compatibility

reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
Today I had a hard lesson to learn. An iface and an object is not
exchangeable. The reference to an object is manipulated if it is casted
to an interface type.

This happens implicit if an object is passed to a var/meth which wants
it to be type of iface.

But this does not happen implicit if you want to pass and array of
objects. This is, because it would mean to iterate over the array, cast
piece-wise and build a new array.
But the consequence is, that the user of the class has to distinguish
between class types and iface types.

I wonder if this should really be in that way?
Is this documented?
Nov 14 2006
parent reply BCS <BCS pathlink.com> writes:
Frank Benoit (keinfarbton) wrote:

 Today I had a hard lesson to learn. An iface and an object is not
 exchangeable. The reference to an object is manipulated if it is casted
 to an interface type.
 
 This happens implicit if an object is passed to a var/meth which wants
 it to be type of iface.
 
 But this does not happen implicit if you want to pass and array of
 objects. This is, because it would mean to iterate over the array, cast
 piece-wise and build a new array.
 But the consequence is, that the user of the class has to distinguish
 between class types and iface types.
 
 I wonder if this should really be in that way?
 Is this documented?


The convention from an object to an interface is unavoidable (at some 
point). Making this conversion implicit would help but, could get costly.


interface I{}
class C : I{}

foo(I[] arr){}



fig(C[] arr){}
{
	foo(cast(I[])arr);
}


void main()
{
	C[] blah = new C[1000000];

	fig(blah); // Ouch O(n) cost in a cast
}



you can neaten up code a bit with something like this:

If[] acast(If, Cl)(Cl[] arr)
{
	If[] ret = new If[arr.length];
	foreach(i,e;arr)
		ret[i] = cast(If)arr[i];

	return ret;
}
Nov 14 2006
parent reply "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:
Yes, thanks for you example.

To make my question more clear:

1.) Is this reference manipulation really absolutely necessary? Why?
2.) Isn't there a way to make class and iface really compatible?
3.) Please document this very cleanly in the D spec.

Frank
Nov 14 2006
next sibling parent reply BCS <BCS pathlink.com> writes:
Frank Benoit (keinfarbton) wrote:

 Yes, thanks for you example.
 
 To make my question more clear:
 
 1.) Is this reference manipulation really absolutely necessary? Why?
 2.) Isn't there a way to make class and iface really compatible?
 3.) Please document this very cleanly in the D spec.

 Frank


In short, No. The long version is that while it could be done, it would 
add a lot of overhead to everything and only fix a problem that is run 
into occasionally.

Actually I ran into this difference a while back, what it amounts to (if 
I understand it correctly) is that the calling convention for interfaces 
is different than that for objects.

For object it amounts to some variation on this (in sudo ASM)

//obj.test(a, b, c);

push c
push b
push a	// push args

mov obj -> r1	// load pointer to object

mov *r1 -> r2	// load v-tbl

push r1		// push "this"

call r2[test]	// use v-tbl to call test




for an interface this is about what is done


//inf.test(a, b, c);

push c
push b
push a	// push args

mov obj -> r1	// load pointer to object

mov *r1 -> r2	// load v-tbl

		// adjust interface to point to object
		// uses information from interface v-tbl
add r1 r2[__offset] -> r1

push r1		// push "this"

call *(r2+test)	// use v-tbl to call test


the interface calling convention adds one more memory fetch and an add. 
Not a lot but it does add to the overhead and complexity that D's single 
inheritance model is trying to avoid.


Actually I would like to see interface calling convention changed to use 
a fat pointer for interfaces. This would use a arbitrary context pointer 
welded to a pointer to a v-tbl. All sorts of cool things could be done 
with this.

interface literals working like delegate literals
3rd party interface implementation for classes*
interfaces from structs, arrays and any arbitrary pointers.

In effect any reference can be used as a context and as the basis for an 
interface


<D version >= 2.0 feature suggestion>

(*)

something like this

// third party closed source code
class Foo
{
	int baz();
	char bar();
	void go(int i);
}


// your code
interface I
{
	void Go();
	void Stop();
}


weld Baz : [Foo:I]
{
	void Go()
	{
		this.go(1);
	}
	void Stop()
	{
		this.go(0);
	}
}


void func(I);

void main()
{
	auto f = new Foo;
	func(f);	// fails (Foo cant be converted to I)
	func(Baz(f));	// works
}

Baz is of type I, when a Foo is converted to a Baz all that needs to 
happen is join the Foo pointer and Baz's v-tbl pointer.
Nov 14 2006
parent reply Pragma <ericanderton yahoo.removeme.com> writes:
BCS wrote:

 Actually I would like to see interface calling convention changed to use 
 a fat pointer for interfaces. This would use a arbitrary context pointer 
 welded to a pointer to a v-tbl. All sorts of cool things could be done 
 with this.
 
 interface literals working like delegate literals
 3rd party interface implementation for classes*
 interfaces from structs, arrays and any arbitrary pointers.
 
 In effect any reference can be used as a context and as the basis for an 
 interface


So then the interface method call turns into:

//inf.test(a, b, c);
push c
push b
push a    // push args

mov obj -> r1    // load pointer to object
mov vtbl -> r2    // load v-tbl (obj+vtbl = fat-pointer)
push r1        // push "this"
call r2[test]    // use v-tbl to call test

So, this basically sacrifices stack space in favor of a few less opcodes 
per interface-method call. :)

But doesn't this make cast() operations *longer* by one additional move 
operation?  Are method calls really more numerous than casts?

On the up-side, it would only make the ABI more consistent, since 
delegates are pretty much doing the same thing when compared to their 
function-pointer counterpart (as you already mentioned).  A higher 
degree of consistency there, could buy us a higher degree of consistency 
with D's constructs, cleaner code, and possibly more-bug-free compiler 
implementations.

-- 
- EricAnderton at yahoo
Nov 14 2006
parent BCS <BCS pathilink.com> writes:
Pragma wrote:

 BCS wrote:

 Actually I would like to see interface calling convention changed to 
 use a fat pointer for interfaces. This would use a arbitrary context 
 pointer welded to a pointer to a v-tbl. All sorts of cool things could 
 be done with this.




[...]

 
 So then the interface method call turns into:
 
 //inf.test(a, b, c);
 push c
 push b
 push a    // push args
 
 mov obj -> r1    // load pointer to object
 mov vtbl -> r2    // load v-tbl (obj+vtbl = fat-pointer)
 push r1        // push "this"
 call r2[test]    // use v-tbl to call test
 


More or less.


 So, this basically sacrifices stack space in favor of a few less opcodes 
 per interface-method call. :)
 
 But doesn't this make cast() operations *longer* by one additional move 
 operation?  Are method calls really more numerous than casts?
 


That is a problem, it doubles the size of an interface reference. I can 
see reasons why that would be bad. (BTW this doesn't attempt to solve 
the object-interface incompatibility.)

OTOH It may make objects smaller by one word for each interface they 
implement. I think that the v-tbl pointer for interfaces is part of the 
object, with the proposed system, it would be part of the objects v-tbl.

It all depends on what your looking for, this system is a bit bigger in 
one place, a bit smaller in another and provides a few new options for 
features.


 On the up-side, it would only make the ABI more consistent, since 
 delegates are pretty much doing the same thing when compared to their 
 function-pointer counterpart (as you already mentioned).  A higher 
 degree of consistency there, could buy us a higher degree of consistency 
 with D's constructs, cleaner code, and possibly more-bug-free compiler 
 implementations.
Nov 14 2006
prev sibling parent Walter Bright <newshound digitalmars.com> writes:
Frank Benoit (keinfarbton) wrote:

 1.) Is this reference manipulation really absolutely necessary? Why?


There are two ways to implement interfaces. One is where the 
determination of what functions to call is done by repeated testing of 
an object to see what interfaces it supports. This is slow. The other 
way is to do it like C++ does multiple inheritance. Interfaces are 
really "multiple inheritance lite", and D does it the C++ way, which is 
very efficient at runtime.


 2.) Isn't there a way to make class and iface really compatible?


Consider a function that takes an interface as an argument. Two 
different objects, A and B, can implement that interface. How can the 
function tell that it can call A.foo() when it gets an interface derived 
from A, when B doesn't have a .foo()?


 3.) Please document this very cleanly in the D spec.
Nov 14 2006