Re: ABI Compatibility (was Re: Installation woes for the average user...)

[Xavier Glattard]

David Chisnall a écrit :
> On 10 Mar 2009, at 10:28, Xavier Glattard wrote:
>
> > Riccardo Mottola a écrit :
> > (...)
> > > David Chisnall wrote:
> > (...)
> > > Yes, this appears to me the "least hurting" path. But I laready dislike.
> > > If we really need, this should be the road.
> > > > If you make private ivars into a structure and make a pointer to this
> > > > an ivar, you add an extra malloc for every +alloc (expensive) and you
> > > > add an extra load for ever ivar access.
> > > That is an abomination.
> >
> > Another stupid question : the memory allocation function accepts an 
> > 'extraBytes' parameter. These bytes are allocated _after_ the instance 
> > bytes by the same 'malloc' call. Couldn't this system be adapted to 
> > ivar storage ? The extra storage is at self+1 : no need for an 
> > additional pointer, and no extra load for ivar access.
>
> The extra bytes are allocated after the object, which would be 
> completely useless.  Imagine:
(...)
> Now you add another ivar to A and remove the extra bytes, and you have 
> this layout:
>
>     id isa;    // offset 0
>     int a;    // offset 4
>     int a1;    // offset 8
>     int b;    // offset 12 <- This has now moved and class B needs 
> recompiling, as do any subclasses of B.

Yes, but this is the case we want to avoid with the use of extra bytes!
--> " do not insert ivar, add it in extra bytes "

> Alternatively, you could try storing the data in the extra bytes, so the 
> layout would be:
(...)
> We now have three different classes, with offsets of 8, 12 and 24, 
> respectively for the a1 ivar.  Every method that attempted to access 
> this ivar would need to determine which class it is and calculate the 
> offset.  This would need a macro like this:
>
> #define a1 (*((int*)(((char*)self) +isa->instance_size)))
>
> This would be really horrible and error-prone (this macro doesn't take 
> into account alignment, so is only valid for architectures like x86, 
> with no strict alignment requirements (as long as none of the ivars are 
> vectors), and would break on SPARC and similar archs.  The next ivar you 
> add would need an even more complex macro to account for the alignment 
> of a1.  This ivar would not be exposed via any introspection, so you 
> couldn't use it with KVC/KVO, bindings, or EtoileUI without writing even 
> more code.
>
> In short, this adds a lot more problems than it solves.  The extra 
> storage is not at self+1 unless self is cast to the correct subclass 
> first.  Pointer arithmetic like that only works when the size of the 
> pointee is known at compile time, which is not the case for Objective-C 
> objects, except in the trivial case of classes with no subclasses, which 
> do not encounter this problem to start with.
>
> David

The extra bytes are already used in some class in GNUstep (GSString, 
GSArray...) and AKAIK there is no problem with system arch.

In GSArray.m:417 :

  _content_array = (id*)&self[1];

So my 'self+1' was not so naive ;)

I have no idea of the macro that would be written for this task. Yours 
is very ugly ;) But it'd have to be writen only once if the extra bytes 
are defined as a structure. And then it would not be so error prone.

// In NSObject
#define OBJECT_EXTRA_PTR ((void*)(((char*)self) +isa->instance_size))

// In FooClass
struct _foo_extra_st
{
  int a1;
} _foo_extra;

#define FOO_EXTRA (*(_foo_extra*)(OBJECT_EXTRA_PTR))

- (int) a1
{
  return FOO_EXTRA.a1;
}

You may find two other examples in GSString.m: 633, 3087

Anyway that's only an idea, not a solution.
I'm convinced that the solution would be more 'political' than technical.

Thank you for your patience.

- Xavier