[cfe-dev] Instance variables in implementation error?

[Marcel Weiher]

On Jul 4, 2011, at 0:43 , David Chisnall wrote:

> On 3 Jul 2011, at 22:33, Marcel Weiher wrote:
> 
>> I am working on a code-base that for various reasons has instance variables declared in both the @interface and the @implementation section
> 
> 
> How old is this codebase?

Its origins are mid 90-ies, so quite old, but actively developed, if not on OSX.

>  That was never allowed in Objective-C 4: GCC just accepts it to ease migration of legacy Objective-C 3.3 code (yes, Objective-C 2.0 is the one that comes after Objective-C 4.  Blame Apple marketing for that one).  Since Objective-C 4 was released about 20 years ago, that's expected to be long enough for most people to update their code...

:)

> If you're on Darwin, then 64-bit mode is enabling the non-fragile ABI implicitly.  This means that defining instance variables in @implementation contexts actually does define new instance variables.

Yep.  The question is wether I can undo/override the implicit enabling explicitly, for example by using  '-fobjc-std=objc1'. 

> Can you not simply delete them from the @implementation?

Not simply, no, although that would be my goal.  The reason is that the headers with the interfaces are actually generated from the .m files (which also means there can't be conflicts).   This has some interesting benefits, though I myself found the costs to outweigh the benefits and abandoned the practice years ago.

>  They aren't actually doing anything there - GCC and clang with the fragile ABI will not accept definitions of new ivars there, because without the non-fragile ABI class layouts had to be public so that each class new where its superclass's ivars were.

Yep.   One solution would be to have the header-generator skip generating the variables for the @interfaces when compiling for 64 bit, and maintain the generation of the variables for 32 bit, but that's also pretty nasty.

Thanks,

Marcel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110704/5a671fe4/attachment.html>