What would be the consequence of implementing interfaces as fat pointers ?

[Manu]

On 30 March 2014 11:42, Walter Bright <newshound2 at digitalmars.com> wrote:

> On 3/29/2014 6:11 PM, deadalnix wrote:
>
>> I'm talking about interface here. The way they are implemented in most new
>> language is via a struct that contains:
>>   - pointer to the object
>>   - pointer to vtable
>>
>> That way to don't make object bigger when they implement an interface,
>>
>
> True, but why is this a problem?


The most annoying thing about a hidden vtable pointer is it breaks
alignment. If there is any SIMD (vector, matrix, etc) or other aligned
value in the class, you have to start worrying and compensating for the
hidden member.

 and you don't need cascaded load to call methods.
>>
>
> True, but on the other hand, it takes up 2 registers rather than one,
> costing twice as much to copy around, store, pass/return to functions, etc.


2 registers are used anyway; it will just populate the second register when
it fetches the vtable pointer.
There is an additional register used when passing a class pointer to a
function, but I'd like to see statistics on function args that include a
class pointer. In my experience, functions that receive a class as an
argument are the sort of functions that rarely receive many arguments. I
notice that classes tend to EITHER receive a class pointer, or receive many
arguments to do some work (and not a class pointers). I don't imagine it
affecting the arg register availability significantly in practise. Slices
certainly have a much greater impact on arg register availability, and they
haven't shown to be a problem.


This is an interesting idea. Something I never thought of, and I think I
like it!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140331/321d34ea/attachment.html>