Richard Frith-Macdonald <richard <at> tiptree.demon.co.uk> writes:

> On 10 May 2007, at 12:35, Nicola Pero wrote:
> 
(...)
> >
> > This looks pretty bad, not only because it doesn't compile with GCC  
> > 2.95, but also because that variable defined in the middle of  
> > nowhere is very ugly ... unclear
> > scope (what happens if you have two _NSANIMATION_LOCK in  
> > sequence ?  is the same variable being used or different  
> > variables ?) ... 

This macro is used as a macro : to repeat again and again the same 
piece of code. It only has to be used in this class. If you have two
_NSANIMATION_LOCK then you have made an error : would you code two 
[NSThread -lock] in sequence ?

> I fixed this to make __gs_isLocked an ivar rather than declaring it  
> locally (which was pretty suboptimal).  I also fixed a bug in the  
> unlock macro (it was setting the lag to the wrong value), and added  
> assertions to check that the macro is not misused.

Bad. If __gs_locked is needed (and as i said i think it is not : i made
an error) then it must be declared in all methods. If __gs_isLocked is
an ivar, its value can be changed in another method then the [unlock]
will never be called.
An ivar already exists: _isThreaded.

Regards

Xavier





_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Reply via email to