[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ABI Compatibility (was Re: Installation woes for the average user...
From: |
Xavier Glattard |
Subject: |
Re: ABI Compatibility (was Re: Installation woes for the average user...) |
Date: |
Tue, 10 Mar 2009 15:27:00 +0100 |
User-agent: |
Thunderbird 2.0.0.16 (X11/20080707) |
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
- Re: ABI Compatibility (was Re: Installation woes for the average user...), (continued)
Re: ABI Compatibility (was Re: Installation woes for the average user...), Yavor Doganov, 2009/03/06
Re: ABI Compatibility (was Re: Installation woes for the average user...), Xavier Glattard, 2009/03/06
Re: ABI Compatibility (was Re: Installation woes for the average user...), Riccardo Mottola, 2009/03/07
- Re: ABI Compatibility (was Re: Installation woes for the average user...), David Chisnall, 2009/03/07
- Re: ABI Compatibility (was Re: Installation woes for the average user...), Riccardo Mottola, 2009/03/09
- Re: ABI Compatibility (was Re: Installation woes for the average user...), Xavier Glattard, 2009/03/10
- Re: ABI Compatibility (was Re: Installation woes for the average user...), David Chisnall, 2009/03/10
- Re: ABI Compatibility (was Re: Installation woes for the average user...),
Xavier Glattard <=
- Re: ABI Compatibility (was Re: Installation woes for the average user...), David Chisnall, 2009/03/10
- Re: ABI Compatibility (was Re: Installation woes for the average user...), Xavier Glattard, 2009/03/10
- Re: ABI Compatibility (was Re: Installation woes for the average user...), David Chisnall, 2009/03/10
- Re: ABI Compatibility (was Re: Installation woes for the average user...), Xavier Glattard, 2009/03/10
- Re: ABI Compatibility (was Re: Installation woes for the average user...), David Ayers, 2009/03/11
- Re: ABI Compatibility (was Re: Installation woes for the average user...), Xavier Glattard, 2009/03/11
Re: ABI Compatibility (was Re: Installation woes for the average user...), Richard Frith-Macdonald, 2009/03/10
Re: ABI Compatibility (was Re: Installation woes for the average user...), Yavor Doganov, 2009/03/11
Re: ABI Compatibility (was Re: Installation woes for the average user...), David Chisnall, 2009/03/11
Re: ABI Compatibility (was Re: Installation woes for the average user...), Yavor Doganov, 2009/03/12