gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Implementing CFSTR() in corebase


From: Richard Frith-Macdonald
Subject: Re: Implementing CFSTR() in corebase
Date: Fri, 22 Jan 2010 17:49:55 +0000

On 22 Jan 2010, at 17:41, Stef Bidi wrote:

> On Fri, Jan 22, 2010 at 11:16 AM, Richard Frith-Macdonald <address@hidden> 
> wrote:
> However, as I understand it, the idea is that this (corebase) should be built 
> on top of GNUstep-base, so as we know it's always going to be linked with the 
> base library, it might be possible to take advantage of the fact that we know 
> that the base library defines NSConstantString as the class for constant 
> strings, and get the compiler to initialise the 'isa' field with the 
> appropriate external reference for the linker to fixup at runtime.  You would 
> need to look into that (ask someone who knows more about low level 
> compiler/linker stuff than me) to find out if it's really possible.
>  
> I was hoping to take advantage of exactly that!  I'll go ahead and share 
> Fred's test (see attached files).  In this case, the NSConstantString struct 
> is compiled with {NULL, "myString", 8} (makes sense)... it's also in the 
> .date section (r/w) and not .rodate (r).  At some points that NULL gets 
> turned into a pointer to the NSConstantString class, and that's what I'd like 
> to be able to reproduce, if at all possible.

Maybe you can initialize the 'isa' field to __objc_class_ref_NSConstantString 
if you predeclare that some way?

> Another issue is the reference counting.  GNUstep objects include a header 
> that has a NSZone * and integer for reference counting... does this need to 
> be reproduced.

No, that doesn't need to be reproduced.  A constant string instance doesn't 
perform any reference counting or deallocation and has methods which carefully 
refrain from trying to use that hidden information.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]