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:
"
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 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 i
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 thei
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, f
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 d
> >> 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 o
On Jan 19, 2010, at 9:21 PM, Shawn Rutledge wrote:
> On Tue, Jan 19, 2010 at 7:01 PM, mmalc Crawford 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
>> instanc
On Tue, Jan 19, 2010 at 7:01 PM, mmalc Crawford 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 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 s
> > 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 y
Le 20 janv. 2010 à 00:18, Kyle Sluder a écrit :
> On Tue, Jan 19, 2010 at 3:09 PM, Shawn Rutledge
> 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
On Tue, Jan 19, 2010 at 3:09 PM, Shawn Rutledge
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 have the option of improv
On Tue, Jan 19, 2010 at 2:33 PM, Jeremy Pereira 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 same re
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 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 th
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 ab
On Tue, Jan 19, 2010 at 2:57 PM, Shawn Rutledge
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 mailing list (Cocoa-dev@l
On Tue, Jan 19, 2010 at 2:38 PM, Graham Cox 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 to use it in a
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 garbage-
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: gr
> 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 as
On Tue, Jan 19, 2010 at 1:24 PM, Jens Alfke 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 greater flexi
On Tue, Jan 19, 2010 at 11:24 AM, Jens Alfke 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 custom clas
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 put
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 copying
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 reverse
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 w
28 matches
Mail list logo
