Re: [Gnustep-cvs] r31629 - in /libs/back/trunk: ./ Source/cairo/ Source/gsc/ Source/win32/ Source/winlib/ Source/x11/

[Nicola Pero]

> I'd replace 'usually' with 'sometimes' there.  malloc() is  
> absolutely fine (and should be preferred) as long as it is not used  
> to store object pointers and it is matched with free() in - 
> finalize.  I'd also add that it CAN be used with object pointers as  
> long as CFRetain() is called on them (rather than -retain) in Apple- 
> land, so we should support this in GNUstep.  Of course, if you're  
> storing object pointers then NSMutableArray is probably a better bet.
>
> Using objc_malloc() for something that is stored in an ivar and  
> contains non-object types is almost always wrong - you're burdening  
> the GC for no benefit.

Actually, I'm not entirely sure; it makes some sense to use malloc()  
for memory which is allocated and never released (and never
references any garbage-collected memory); but for everything else, the  
boehm garbage collector is not limited to ObjC objects;
objc_malloc() works with normal C memory allocations too - the memory  
is automatically garbage collected as required. :-)

If boehm garbage collection is being used, I can't see a particular  
reason to manage C memory manually using malloc() and free();
using objc_malloc() and objc_free() (btw, objc_free() is an empty  
operation in that case) provides garbage collection for C memory
too, and makes sure that you don't crash because you forget that you  
have a reference to an garbage-collected Objective-C object
in your C memory.

So, I guess the traditional recommendation of always using  
objc_malloc() and objc_free() instead of malloc() and free() actually
makes sense.

Unfortunately, Objective-C garbage collection as implemented by Apple  
is rather different.

Thanks