Re: retainCount-what about debugging(Dave Mattson)
Re: retainCount-what about debugging(Dave Mattson)
- Subject: Re: retainCount-what about debugging(Dave Mattson)
- From: Dave Mattson <email@hidden>
- Date: Sat, 6 Oct 2001 11:12:46 -0500
I understand there is no reason for using [foo retainCount] --except for
testing and debugging. But retain count doesn't reflect a pending
autorelease. That makes it tricky to when testing or debugging-to make
sure that a memory leak or lurking crash hasn't crept in.
And another point, when using external code we can study and study but
one NSLog(@"%d", [foo autoreleaseCount] would worth a thousand
studies. For example:
NSNumber *n1 = [[NSNumber alloc] initWithInt:1];
NSNumber *n2 = [NSNumber numberWithInt:1];
I'd say at my point on the learning curve I'm 94%(OK 98%) sure n2 is
autoreleased and n1 is not. I can pound n2 with an extra autorelease
and make sure we hit a signal 11, but that seems a little kludgey.
Dave Mattson
On Saturday, October 6, 2001, at 12:18 AM, cocoa-dev-
email@hidden wrote:
Send cocoa-dev mailing list submissions to
email@hidden
To subscribe or unsubscribe via the World Wide Web, visit
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
or, via email, send a message with subject or body 'help' to
email@hidden
You can reach the person managing the list at
email@hidden
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cocoa-dev digest..."
Today's Topics:
1. Re: retainCount (John C. Randolph)
2. Why is NSMenu indexOfIitemWithTag unpredictable? (Tony)
3. Re: retainCount (Dustin Mierau)
4. Re: retainCount (Brant Vasilieff)
5. Re: global default for NSLayoutManager selection threshold? (Paul
Bayley)
6. Re: global default for NSLayoutManager selection threshold? (Paul
Bayley)
7. Re: retainCount (Greg Titus)
--__--__--
Message: 1
Date: Fri, 5 Oct 2001 19:16:17 -0700
Subject: Re: retainCount
Cc: Henri Lamiraux <email@hidden>, email@hidden
To: Rosyna <email@hidden>
From: "John C. Randolph" <email@hidden>
On Friday, October 5, 2001, at 06:36 PM, Rosyna wrote:
So, from the different posts on the subject, it seems there is no way
to tell whether an object is in the autorelease pool or not?
Oh, there's a way to tell, but what we've all been trying to tell you is
not to do it.
-jcr
"I fear all we have done is to awaken a sleeping giant and fill him with
a terrible resolve." -Admiral Isoroku Yamamoto, Dec 7, 1941.
--__--__--
Message: 2
From: "Tony" <email@hidden>
To: <email@hidden>
Subject: Why is NSMenu indexOfIitemWithTag unpredictable?
Date: Fri, 5 Oct 2001 22:24:11 -0400
I have application where each menu item was assigned a different tag.
The intention is to execute menu item action programmatically
using NSMenu's performActionForItemAtIndex.
However, [ menu indexOfItemWithTag:NN] sometimes returns valid index
and sometimes -1, indicating menu item does not exist.
I could not find any hard rule in this behavior, but clicking app
menu with mouse usually results in indexOfItemWithTag returning a valid
index.
After executing menu action at some point I start getting -1 as index
and
then,
of course, I can not execute menu item action. Eventually it starts
working and then failing again, and so on.
All topmost app menu items are mapped to IB outlets. On each outlet I
call
submenu,
return of which is then used as the target for indexOfItemWithTag
message.
I am running version 10.1.
Thanks for any suggestions,
Tony
--__--__--
Message: 3
Date: Fri, 5 Oct 2001 19:23:20 -0700
Subject: Re: retainCount
Cc: "John C. Randolph" <email@hidden>, Henri Lamiraux
<email@hidden>, email@hidden
To: Rosyna <email@hidden>
From: Dustin Mierau <email@hidden>
I think what everyone is trying to say and has said is:
"If you should ever have to do this, you should review and
rewrite parts of your code, because you should never need to do
this."
I don't think it is a shortcoming, it just forces the developer
to not second guess him/herself all over the place. You should
know if an object is in the autorelease pool or not.
Though I could be totally wrong...
-dustin
So, from the different posts on the subject, it seems there is
no way to tell whether an object is in the autorelease pool or
not? This seems like a shortcoming. I'd even try using
+showAllPools, then searching the output to see if my object is
in there, except there seems to be no way to get the output.
-- Sincerely,
Rosyna Keller
Technical Support/Holy Knight/Always needs a hug
Unsanity: Unsane Tools for Insane People
_______________________________________________
cocoa-dev mailing list
email@hidden
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
--__--__--
Message: 4
Date: Fri, 5 Oct 2001 20:14:09 -0700
Subject: Re: retainCount
Cc: Rosyna <email@hidden>
To: email@hidden
From: Brant Vasilieff <email@hidden>
On Friday, October 5, 2001, at 07:06 PM, cocoa-dev-
email@hidden wrote:
So, from the different posts on the subject, it seems there is no way
to tell whether an object is in the autorelease pool or not? This
seems like a shortcoming. I'd even try using +showAllPools, then
searching the output to see if my object is in there, except there
seems to be no way to get the output.
After all the replies to the various questions concerning autorelease
pools, and retain counts, I'm amazed at your continued insistence on
avoiding them.
If you know enough about the internals of an object to know that you
want to remove it from an autorelease pool, then don't put it there to
begin with. There is no list of pools. Each thread can create their
own pool and pools can be nested. It is unsafe to remove an item from a
pool. Prematurely clearing a pool would wreak havoc all the way up the
call chain.
Autorelease pools are not thread safe. Adding an item to the pool is
only atomic within the thread that own it. If you had a multi-threaded
app, and could iterate a release pool from another thread to see if an
item existed, you could be interrupted before acting on that knowledge
allowing the pool to be released, in which case the object technically
wouldn't exist in the pool any more. Even though your test would assume
it was.
If you look at the interface for the autorelease pool, you'll wee it
doesn't use an NSArray.
@interface NSAutoreleasePool : NSObject {
@private
void *_token;
void *_reserved3;
void *_reserved2;
void *_reserved;
}
+ (void)addObject:(id)anObject;
- (void)addObject:(id)anObject;
_token is most likely some form of linked list or linked buffer.
Further, in thread conditions, autorelease is your friend. Trust me.
If you ask a Person object to return their name, that object cold be
released before you get the result. To fix that, you return an
autoreleased version of it. Either by retain/autorelease or
copy/autorelease;
For example:
- (void)dealloc
{
[name release];
[super dealloc];
}
- (NSString*)name
{
return [[name retain] autorelease];
}
- (void)setName:(NSString*)inName
{
id oldName = name;
name = [inName copy];
[oldName release];
}
- (id)initWithName:(NSString*)inName
{
self = [super init];
{
name = [inName copy];
}
return self;
}
Thread A:
- (void)sayHiToPerson:(Person)*inPerson
A1: {
A2: NSString* name = [inPerson name];
A3: NSLog(@"Hi %@.", name];
A4: }
Thread B:
- (void)giveDoctorateToPerson:(Person*)inPerson
B1: {
B2: NSString* name = [inPerson name];
B3: name = [NSString stringWithformat:@"Dr. %@", name];
B4: [inPerson setName:name];
B4: }
Thread A could end up allowing Thread B to execute between A2 and A3.
If -[Person name] didn't return a retained and autoreleased version of
name, and instead just return the pointer to name, then name could be
deallocated by thread B, before we get to log the name.
Don't avoid using autorelease pools, embrace them.
HTH,
Brant
--__--__--
Message: 5
Date: Fri, 5 Oct 2001 21:08:03 -0700
To: "Erik M. Buck" <email@hidden>, <email@hidden>
From: Paul Bayley <email@hidden>
Subject: Re: global default for NSLayoutManager selection threshold?
Cc: <email@hidden>
At 12:03 AM -0500 10/5/01, Erik M. Buck wrote:
You know, I have yet to use a single Cocoa app I like.
There is no accounting for taste :( I have yet to use a Carbon app
that I
like.
A) We don't need to debate the paths vs. refs thing again. We will
all have
to agree to disagree.
Cocoa doesn't give me the choice.
B) We all hate the way text selection works. It was Apple ludites that
caused that IMHO. It used to work better.
It used to work better? HUH!?!?!
C) The whole policy of almost never allowing click-through slows _me_
down.
I hate it.
Whatever. My only point with respect to this is the
command-click-through isn't universal and doesn't remove the modifier
before passing it through.
D) It used to be possible to assign quick keys as a user preference,
and
they did not change without your consent. If you used a particular
service
frequently, you could give it a quick key that makes sense to you...
While
we are complaining, I hate the three key chords that Apple dumped on
us! If
it takes three keys then something is broken.
I was more productive with System 7.6 because Now Utilities still
worked. You could change any menu item's hotkey by selecting it and
typing the hotkey. Nothing could be simpler. You can try ACTION Menus
in MacOS 9 to understand what I mean.
Unfortunately I don't see anything like that ever happening in OS X.
There is no global menu structure any longer.
--__--__--
Message: 6
Date: Fri, 5 Oct 2001 21:11:44 -0700
To: Ali Ozer <email@hidden>, email@hidden
From: Paul Bayley <email@hidden>
Subject: Re: global default for NSLayoutManager selection threshold?
At 9:58 AM -0700 10/5/01, Ali Ozer wrote:
It probably won't happen, but my suggestion to Apple would be to
reduce
the delay - at least to half of the present value
The delay in 10.1 is half of that in 10.0.
Ali
I can't accept any delay.
Is there a hidden preference I can use to set it? If not, why not?
Same for the left-to-right drag CR selection threshold.
--__--__--
Message: 7
Date: Fri, 5 Oct 2001 21:44:39 -0700
Subject: Re: retainCount
Cc: "John C. Randolph" <email@hidden>, Henri Lamiraux
<email@hidden>, email@hidden
To: Rosyna <email@hidden>
From: Greg Titus <email@hidden>
On Friday, October 5, 2001, at 06:36 PM, Rosyna wrote:
So, from the different posts on the subject, it seems there is no way
to tell whether an object is in the autorelease pool or not? This seems
like a shortcoming. I'd even try using +showAllPools, then searching
the output to see if my object is in there, except there seems to be no
way to get the output.
Rosyna,
Could you please describe more completely why it is that you want to do
this? What is the pattern in your code that leads you to believe that
knowing the number of times an object has been autoreleased is necessary
or desirable?
My initial reaction, and obviously that of many of the other people
responding to this thread is: there's no reason to want to know, and you
must be overcomplicating your memory management if you think you need to
know.
Of course, it is possible that we are wrong, but you'll need to share
more of what you are attempting for anyone to be able to give any better
advice.
Thanks,
--Greg
--__--__--
_______________________________________________
cocoa-dev mailing list
email@hidden
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
End of cocoa-dev Digest