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
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev