Re: [Gnustep-cvs] r27578 - in /libs/base/trunk: ./ SSL/ Source/ Source/Additions/ Tools/

[Richard Frith-Macdonald]

On 12 Jan 2009, at 14:30, Fred Kiefer wrote:

> Hi Richard,
>
> could you please explain the background of these changes?

Various changes to fixup building for GC, mostly because the current  
code had bit-rotted over the years to a point where it wouldn't even  
compile.
The vast majority of changes (including the ones you are specifically  
asking about) were just to avoid compiler warnings though, not to fix  
real errors.  For the avoidance of confusion, I like things to compile  
without warnings.

> From looking
> at them I get the impression that our current system of using RETAIN,
> RELEASE etc macros doesn't help much in the case of GC, now this was  
> the
> main reason to stick with those macros (The ASSGIN macro is different,
> that one is valuable in itself).

They help a lot ... but are not a cure-all.  Mostly, where you use  
RETAIN() or AUTORELEASE() you are using the return value, so the GC  
versions reduce to a reference to a variable or expression.  If  
however, you use them on an empty line then the compiler may warn  
because the return value is unused, which is what the IF_NO_GC() macro  
was designed to avoid, but of course we've forgotten to use it in a  
lot of places.

> Do you have a proposal of what we
> should do in the future instead?

Not really ... just do what we've always done ... generally avoid  
using retain or autorelease except where we are going to use their  
return value, and use IF_NO_GC() or '#if !GS_WITH_GC' for chunks of  
code we want to avoid compiling when using garbage collection.

> My impression from a short glance at your changes is that lines like
> RETAIN(anObject); give compiler warnings about unused values when
> compiled.

Yes.

> Should we introduce a new macro that wont return a result?

I don't think there's any point doing that ... it's what IF_NO_GC() is  
for.

> What I don't like is spreading around code like
> IF_NO_GC([anObject retain];)
> This looks strange with the semicolon inside the brackets.

Oh, well you can put the semicolon outside the bracket if you prefer.   
I guess that's an aesthetic issue.

IF_NO_GC(X;)

evaluates to 'X;' or an empty line

IF_NO_GC(X);

evaluates to 'X;' or ';'

In most cases it makes no real difference to the compiler, though you  
do have to take care that you use the second form in places where it  
matters whether there is a statement or not.