On 19 Jan 2010, at 23:06, Jens Alfke wrote:
On Jan 19, 2010, at 10:46 AM, Kirk Kerekes wrote:
NSDictionary will use almost any object as a key:
From the docs:
In general, a key can be any object (provided that it conforms to the
NSCopying protocol...)
-- and if it is an immutable
Am 20.01.2010 um 11:34 schrieb Jeremy Pereira:
On 19 Jan 2010, at 23:06, Jens Alfke wrote:
On Jan 19, 2010, at 10:46 AM, Kirk Kerekes wrote:
NSDictionary will use almost any object as a key:
From the docs:
In general, a key can be any object (provided that it conforms to
the NSCopying
On Jan 20, 2010, at 5:22 AM, Jens Miltner wrote:
Am 20.01.2010 um 11:34 schrieb Jeremy Pereira:
On 19 Jan 2010, at 23:06, Jens Alfke wrote:
On Jan 19, 2010, at 10:46 AM, Kirk Kerekes wrote:
NSDictionary will use almost any object as a key:
From the docs:
In general, a key can be any
I wish NSDictionary (NSMutableDictionary actually) could handle
arbitrary mappings of one type of object to another, without copying
the keys. A string makes a good key most of the time but what about
the case where you want to do the reverse mapping, to find the string
which you have associated
On Jan 19, 2010, at 11:53 AM, Shawn Rutledge wrote:
I wish NSDictionary (NSMutableDictionary actually) could handle
arbitrary mappings of one type of object to another, without copying
the keys. A string makes a good key most of the time but what about
the case where you want to do the
On Jan 19, 2010, at 8:53 AM, Shawn Rutledge wrote:
I wish NSDictionary (NSMutableDictionary actually) could handle
arbitrary mappings of one type of object to another, without copying
the keys.
It can. If you have a custom class you want to be able to use as a
dictionary key without
On Jan 19, 2010, at 10:09 AM, Paul Bruneau wrote:
When I want to find the key(s) for a given object, I use the -
allKeysForObject method
This is fine, but keep in mind that it's a lot slower since it does a
linear search instead of a hash lookup. (It's O(n) instead of O(1).)
If you're
On Tue, Jan 19, 2010 at 11:24 AM, Jens Alfke j...@mooseyard.com wrote:
On Jan 19, 2010, at 8:53 AM, Shawn Rutledge wrote:
I wish NSDictionary (NSMutableDictionary actually) could handle
arbitrary mappings of one type of object to another, without copying
the keys.
It can. If you have a
On Tue, Jan 19, 2010 at 1:24 PM, Jens Alfke j...@mooseyard.com wrote:
On Jan 19, 2010, at 8:53 AM, Shawn Rutledge wrote:
I didn't try CFDictionary yet; is that appropriate for an iPhone app?
But try NSMapTable first. It's sort of halfway between the two — it's an
Objective-C class but it has
I wish NSDictionary (NSMutableDictionary actually) could handle
arbitrary mappings of one type of object to another, without copying
the keys. A string makes a good key most of the time but what about
the case where you want to do the reverse mapping, to find the string
which you have
On 19 Jan 2010, at 16:53, Shawn Rutledge wrote:
I'm accustomed to
things like Qt and Java where hashtables can contain anything for both
key and value.
This is not true (at least for Java and probably for QT for the same reason).
From the API docs for the Map abstract class:
Note: great
On 20/01/2010, at 5:33 AM, Shawn Rutledge wrote:
I forgot to mention, another problem I ran into was that my dictionary
is a member variable of my UIViewController, I inited it in
initWithNibName, then later when I go to use it in another member
function, I found that it had been
On Tue, Jan 19, 2010 at 2:38 PM, Graham Cox graham@bigpond.com wrote:
On 20/01/2010, at 5:33 AM, Shawn Rutledge wrote:
I forgot to mention, another problem I ran into was that my dictionary
is a member variable of my UIViewController, I inited it in
initWithNibName, then later when I go
On Tue, Jan 19, 2010 at 2:57 PM, Shawn Rutledge
shawn.t.rutle...@gmail.com wrote:
I think dictionaryWithCapacity should both alloc and init it, right?
Please stop making conjectures. The documentation explains all of this.
--Kyle Sluder
___
Cocoa-dev
On 20/01/2010, at 9:57 AM, Shawn Rutledge wrote:
I think dictionaryWithCapacity should both alloc and init it, right?
Why do you think that?
I repeat: You MUST learn the memory management rules and have them down pat so
you can write correctly managed code without having to really think
On Jan 19, 2010, at 2:57 PM, Shawn Rutledge wrote:
I think dictionaryWithCapacity should both alloc and init it, right?
Yes, and it autoreleases it too. :-o That means it'll conveniently be
released later on, which is exactly what you're running into. If you
want to keep a reference to
On Jan 19, 2010, at 10:46 AM, Kirk Kerekes wrote:
NSDictionary will use almost any object as a key:
From the docs:
In general, a key can be any object (provided that it conforms to
the NSCopying protocol...)
-- and if it is an immutable object, that -copy is just a -retain.
Yes, but he
On Tue, Jan 19, 2010 at 2:33 PM, Jeremy Pereira a...@jeremyp.net wrote:
On 19 Jan 2010, at 16:53, Shawn Rutledge wrote:
I'm accustomed to
things like Qt and Java where hashtables can contain anything for both
key and value.
This is not true (at least for Java and probably for QT for the
On Tue, Jan 19, 2010 at 3:09 PM, Shawn Rutledge
shawn.t.rutle...@gmail.com wrote:
Well yeah, that's one of the reasons java.lang.String is immutable.
But it helps that java.lang.Object has both hashCode and equals, so
any object can be put into a collection that depends on those... you
just
Le 20 janv. 2010 à 00:18, Kyle Sluder a écrit :
On Tue, Jan 19, 2010 at 3:09 PM, Shawn Rutledge
shawn.t.rutle...@gmail.com wrote:
Well yeah, that's one of the reasons java.lang.String is immutable.
But it helps that java.lang.Object has both hashCode and equals, so
any object can be put
I think dictionaryWithCapacity should both alloc and init it, right?
Yes, and it autoreleases it too. :-o That means it'll conveniently be
released later on, which is exactly what you're running into. If you
want to keep a reference to the dictionary, you should call alloc and
init
On Jan 19, 2010, at 5:50 pm, Jeff Laing wrote:
Yes, and it autoreleases it too. :-o That means it'll conveniently be
released later on, which is exactly what you're running into. If you
want to keep a reference to the dictionary, you should call alloc and
init yourself.
No, you should
On Tue, Jan 19, 2010 at 7:01 PM, mmalc Crawford mmalc_li...@me.com wrote:
No, you should just *retain* the result of dictionaryWithCapacity.
No, you shouldn't.
If you're writing an init method and want to assign the dictionary to an
instance variable, you should use alloc/init.
Why?
On Jan 19, 2010, at 9:21 PM, Shawn Rutledge wrote:
On Tue, Jan 19, 2010 at 7:01 PM, mmalc Crawford mmalc_li...@me.com wrote:
No, you should just *retain* the result of dictionaryWithCapacity.
No, you shouldn't.
If you're writing an init method and want to assign the dictionary to an
Yes, and it autoreleases it too. :-o That means it'll conveniently be
released later on, which is exactly what you're running into. If you
want to keep a reference to the dictionary, you should call alloc and
init yourself.
I wrote:
No, you should just *retain* the result of
On Jan 19, 2010, at 8:47 PM, Jeff Laing wrote:
With all due respect, why not? Apple gives us all those convenience methods
but you say we shouldn't use them?
Convenience ≠ performance.
The autoreleased factory methods are very convenient when you're using the
result temporarily, so you
On Jan 19, 2010, at 8:47 pm, Jeff Laing wrote:
I wrote:
No, you should just *retain* the result of dictionaryWithCapacity.
mmalc wrote:
No, you shouldn't.
With all due respect, why not?
Because it's difficult to imagine a common situation in which your advice will
be valid, for
On Jan 19, 2010, at 10:47 PM, Jeff Laing wrote:
I'm assuming you are saying 'don't use the convenience methods because the
autorelease pool won't empty quickly enough'. Certainly Ken said it, though
he seemed to assume that there was only one pool, that people would not be
creating their
28 matches
Mail list logo
