Works without objc_setAssociatedObject:
E/Z2GameLog(14278): STDOUT: [--] 1 test from
objc_setAssociatedObject
E/Z2GameLog(14278): STDOUT: [ RUN ]
objc_setAssociatedObject.AssociatedObjectsAreReleased
E/Z2GameLog(14278): STDOUT: [ OK ]
objc_setAssociatedObject.AssociatedObjectsAre
This test case looks like it should pass irrespective of whether the runtime
does the right thing. Since you're using associatedObjectTestAssociatedObject
for both objects, deallocating the original autoreleased one ought to set
associatedObjectDeallocCalled. Can you confirm whether this test
I saw the test that you checked in to svn and modified my code to match it:
static BOOL associatedObjectDeallocCalled = NO;
static const char* objc_setAssociatedObjectKey =
"objc_setAssociatedObjectKey";
@interface associatedObjectTestAssociatedObject : NSObject
@end
@implementation associatedOb
Thanks David,
I'll investigate more on our end. I actually had changed that from
NSString to NSObject just to be sure that it wasn't related to that. (Why
in the above stupid example it was cast to NSObject though Alloced as
NSString, I had intended it to just be a double dummy NSObject.) The ac
Ah, sorry, I was reading your example the other way around. This seems to be
because [[NSString alloc] init] returns a singleton on GNUstep. I don't think
this is necessarily a bug, as there's nothing in the contract for NSString that
says that it needs to return a new instance for different i
I've now added a test for this to the libobjc2 test suite, but it passes and so
does not appear to be the cause. Your issue appears to be the dictionary being
over-retained. I will investigate further.
David
P.S. When sending test cases, it helps to send them in the format of a test
suite fo
On 12.12.2013 09:20, Fred Kiefer wrote:
> Am 12.12.2013 um 09:12 schrieb "Sebastian Reitenbach"
> :
>>> On Thursday, December 12, 2013 08:06 CET, Germán Arias
>>> wrote:
On 2013-12-11 16:58:30 -0600 Fred Kiefer wrote:
I really don't have a clue what is going on here. Anybody out
