2010-06-10 3 views
4

В настоящее время я работаю над приложением, которое отображает кучу файлов в таблице, и вы можете добавлять и удалять их и вообще. Чтобы предотвратить дублирование в таблице, я хотел бы создать NSDictionary, используя полный путь файлов как ключи для другого NSDictionary, который содержит всю информацию о файле, но меня немного беспокоит максимальная длина ключа NSDictionary, а также решение будет производительным убийцей или нет ...Какова максимальная длина ключа в NSDictionary?

ответ

9

Нет конкретных ограничений на размер используемой вами NSString, если она не такая большая, что вы заполняете всю память! Словарь не загружается в символы и начинает смотреть на них сам, поэтому не будет никаких внутренних проблем NSDictionary, связанных с этим, или проблем с производительностью, поскольку все, что он делает, это использовать метод isEqual: и если он возвращает true, это Матчи.

Надеюсь, что это поможет.

+0

Ну, 'hash', тоже, плюс протокол NSCopying. Но все это зависит от ключевых объектов для реализации, а ключевым объектам даже не нужно иметь понятие длины: вы можете использовать любые копируемые, хешируемые, сопоставимые объекты в качестве ключей. NSStrings имеют длину и имеют этот практический предел длины, но у них нет явно определенного предела; их длина в принципе не ограничена. –

1

Теоретического максимума нет. Кроме того, я не буду беспокоиться о производительности, пока вы не определите, что это действительно проблема.

2

Максимальное значение отсутствует, за исключением, возможно, максимальной длины NSString, которая, как я думаю, теоретически неограниченна/UIntMax. Интерфейс NSDictionary требует индексации через методы -hash и -isEqual:, реализованные любым объектом, который используется в качестве ключа, чтобы позволить ключам быть чем угодно, а не только NSStrings. Конечно, NSString реализует обе функции, но это не значит, что хэш является int, поэтому в основном NSString находит способ превратить его содержимое в целое число - ему не нужно (и физически не может) быть уникальным, просто повторяемым (каждый раз возвращающий один и тот же результат). См. here для получения подробной информации о хешировании. В основном это означает, что каждый NSString - любой объект, действительно - может иметь хэш. Поэтому, если вы можете сохранить его в NSString, тогда нет предела его помещению в NSDictionary. Кроме того, не стоит беспокоиться о производительности/словарях словарей, являющихся совершенно правильной конструкцией и достаточно быстрыми, чтобы быть применимыми.

+0

Ключи не могут быть ничем, они должны соответствовать протоколу 'NSCopying', а значение хэша не должно опираться на какие-либо изменчивые характеристики объекта. – dreamlax

3

Нет конкретных ограничений. Одним из обязательных условий для словарей является то, что ключ должен соответствовать протоколу NSCopying. Когда вы вставляете пару ключ-значение в словарь, словарь делает копию ключевого объекта, чтобы гарантировать, что он не будет мутировать во внутреннем словаре. Он использует хэш-значение ключевого объекта, чтобы определить, где его заказать внутри. Если объект мутировался, когда он был в словаре, он бы отбросил упорядочение и словарь не работал, поэтому словарь делает копию (хотя в качестве оптимизации, когда неизменяемым объектам, таким как NSString, предлагается копия , он может просто увеличить счетчик удержания и вернуть себя, но это деталь реализации).

Поскольку ключи должны соответствовать протоколу NSCopying, это означает, что вы можете использовать несколько объектов в качестве ключей словаря, в том числе NSArray, NSData и т.д. Не беспокойтесь о производительности с использованием больших строк в NSDictionary коллекции, если у вас нет что это на самом деле узкое место.

Смежные вопросы