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

[Xavier Glattard]

Richard Frith-Macdonald a écrit :
> On 6 Mar 2009, at 09:15, Xavier Glattard wrote:
>
> > Richard Frith-Macdonald a écrit :
> > > On 6 Mar 2009, at 07:05, Xavier Glattard wrote:
> > > > Hi
> > > >
> > > > I dont understand this problem about ABI and binary compatibility, so
> > > > please excuse me if this looks stupid :\
> > > >
> > > > The problem comes from ivars that would not be always at the same
> > > > offset, doesn't it ? But these ivars are supposed to be private, dont
> > > > they ? So the code that uses these ivars is always released along with
> > > > the class interface. I can not find any official 'public' ivars. Do i
> > > > miss something ?
> > > There are all sorts of possible issues with symbol names when 
> > > functions and global variables etc are added/removed/changed, but the 
> > > main issue we are talking about is the ivar layout and subclassing.
> > > If you add an ivar to a class, the memory used by and instance 
> > > becomes bigger to make room for it.
> > > If you link in some bundle or library which uses a subclass of that 
> > > class, the bundle/library will not be expecting that ivar to be 
> > > there, and will have stored one of the subclass ivars at the oiffset 
> > > in memory where the new ivar is stored ... causing obvious problems.
> > > David's solution of non-fragile ivars requires compiler and runtime 
> > > support, but is definitely the way to go to solve the problem (except 
> > > for when the very highest performance is needed, in which case you 
> > > can usually use straight C and other techniques for optimisation).
> >
> > Fred, Richard : thank you for your answers.
> > I think I understand the 'technical' problem :)
> >
> > But IMHO :
> > - private ivars should (can?) not be used from outside the class itself.
> > - protected ivars should only be used from inside the 
> > library/framework itself, and only for very good reason.
> > - public ivars should not exist!
> >
> > Moreover ivars are never documented.
> >
> > Then GNUstep users should never meet this problem. If they do then I 
> > think this is their own choice.
> >
> > Do i still miss something ?
(...)
> but the actual layout at runtime is
> {
>   Class isa;
>   int _ivar1;
>   int _ivar2;
>   NSString *name;
> }
> so the assignment actually overwrites _ivar2
(...)

I have think of this, but i could not consider the compiler is so stupid!
Thank you for your patience.

Anyway, do you think we should rely on a (non-existent) compiler feature 
? It takes a long time for new compiler release to reach end users. Is 
the compatibility with gcc 2.95 a forgotten dream ? ;)

Do you think a backward compatible version of some classes might be 
created at each release ? Additional ivars would be stored externally in 
a map table : slow but simple. This version of the class would be loaded 
at runtime, but would be private and only the new version could be used 
by a compiler. The implementation file could be easily shared by both 
version (if not the implementation itself with the use of accessors)

======================

---- LibraryClass.h

#ifndef __GSLibraryClass_Version_flag__
#define __GSLibraryClass_Version_flag__
int __GSLibraryClass_mandatory_version = 0x0200; // not extern !
#enfif

@class LibraryClass_old;

@interface LibraryClass: LibraryClass_old
{
@private
//  int    _ivar1; -- inherited
  int    _ivar2;
}

- int var2;
- int twice;

@end

---- LibraryClass.m

#define __GSLibraryClass_Version_flag__
extern int __GSLibraryClass_mandatory_version;
static int __GSLibraryClass_version = 0x0200;

#include <LibraryClass.h>

@interface LibraryClass_old : NSObject
{
@protected
  int    _ivar1;
}
@end

@implementation LibraryClass_old

static GSIMap * _ivar2_store;

- int var2
{ return [_ivar2_store valueForKey: self]; }

- int twice
{
  return [self var2] * 2;
}

@end

@implementation LibraryClass

+ (id) alloc
{
  if ( __GSLibraryClass_version != __GSLibraryClass_mandatoryVersion )
    {
      return [LibraryClass_old alloc];
    }
  else
   {
      return [super alloc];
   }
}

- int var2
{ return _ivar2; }

// if needed :
- int twice
{
  return _ivar2 * 2;
}

@end

=================

Some good old MACROS might be helpful. I know there are some MACROS 
gurus around ;)

Just an idea. Maybe too complicated.

-- Regards
- Xavier