[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: problems compiling NSAnimation.m
From: |
Xavier Glattard |
Subject: |
Re: problems compiling NSAnimation.m |
Date: |
Wed, 9 May 2007 16:53:01 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
Riccardo <multix <at> ngi.it> writes:
> Hi,
>
> trying to compile NSAnimation on older compilers is a nightmare (like
> gcc 2.95). I fixed some trivial stuff, but then stopped: the main
> problem is the _NSANIMATION_LOCK macro. Since this macro defines a
> variable in it,
>
> #define _NSANIMATION_LOCK \
> BOOL __gs_isLocked = NO; \
> if (_isThreaded) \
> { \
> __gs_isLocked = YES; \
> NSDebugFLLog( <at> "NSAnimationLock",\
> <at> "% <at> LOCK % <at> ",self,[NSThread
> currentThread]);\
> [_isAnimatingLock lock]; \
> }
>
> it causes a hidden "c99-ism" everywhere. If the definition of
> __gs_isLocked inside the macron can be avoided or the macroitself can
> be avoided, I think the code would be cleaner.
>
> Ideas? Who maintains this?
>
> -Riccardo
I wrote this stuff, so i guess i could help ;-)
I dont know if this can be avoided : i remember i thought very hard and i did
not find any other way to make this class thread-safe and reduce overhead. But i
can't remember why i added __gs_isLocked... Maybe in case of isThreaded becomes
false before the unlock. But it cant (AFAIK)
A 'if(_isThreaded)' might be enough, both in _NSANIMATION_LOCK and
_NSANIMATION_UNLOCK.
Regards
Xavier