Почему массивы в .Net имеют длину, а другие типы коллекций имеют число? [закрыто]


23

Например, в C # массивы имеют свойство Length. Но другие типы коллекций, такие как списки и т. Д., Имеют свойство Count. Есть ли причина, почему эти два разные? Если так, то я хотел бы знать.


4
Я не могу найти свой Lippert-свисток, поэтому я не думаю, что мы получим хороший ответ сегодня :(
MetaFight

4
Просто дикая догадка, поскольку у меня нет внутренних знаний о том, как был разработан CLR: детали того, как работают массивы, были указаны до типов коллекций. Вызов свойства Length является наиболее естественным для него именем, и поскольку ранее существовавшего стандарта не было, чтобы соответствовать этому, разработчик массивов решил использовать его. Затем коллекции были определены позже, но Length не подходит для некоторых коллекций (это подразумевает линейность, поэтому для неупорядоченных коллекций это недопустимое имя), поэтому Count был выбран как более логически непротиворечивый.
Жюль

4
Я думаю, что это бывшее сообщение от stackoverflow имеет правильный ответ.
Док Браун

6
@MetaFight: я недавно записал серию обучающих видео, и в какой-то момент я упомянул, что понятия не имею, почему дизайнеры использовали и длину, и количество. Это всегда казалось мне странным. Комментарий Жюля выше выглядит правдоподобным.
Эрик Липперт

3
Мета-примечание - я разыграл 5-й VTC, так как не верю, что на этот вопрос можно окончательно ответить. Существующий ответ является твердым и правдоподобным ответом, но он не подкреплен доказательствами. Аналогичным образом, комментарий Липперта заставляет меня думать, что никто не знает ответа, так как он мог быть вызван недосмотром, а не сознательным решением.

Ответы:


30

Они названы по-разному, потому что семантически они совершенно разные:

Количество коллекции - это количество элементов, хранящихся в ней в данный момент, которые могут со временем измениться.

Длина массива - это максимальное количество элементов, которые он может содержать (он будет иметь длину 10, даже если вы не сохранили в нем столько элементов) и является неизменным.

Пример:

Если у меня есть ведро, которое может вместить максимум 100 шаров, оно имеет длину 100. Если я положу в него 50 шаров, то у него будет количество 50.

Если я добавлю еще 10 шаров, счет станет 60, но длина все равно 100. Чтобы изменить длину, мне нужно получить другое ведро.

Массив, вероятно, использует слово Length, потому что под капотом он выделяет непрерывный блок (длину) памяти, основанный на емкости, умноженной на размер элемента. Хотя тот факт, что класс List использует «Capacity» для аналогичной (хотя и изменчивой) концепции, предполагает, что массив может использовать слово «Length» по историческим причинам.


12
A T[]с длиной N всегда хранит ровно N значений типа T. Семантически, не все эти значения могут быть значимыми (они могут быть, nullнапример), но они существуют. Это отличается от обычного значения емкости (как, List<T>например, используется). Ты прав, что Countможешь измениться, а Lengthне можешь. Опять же, ничто не обязывает, что Countна самом деле изменится. Это также используется для неизменных коллекций.

@ дельнан, о, дорогой. я не понимал, что слово «Capacity» уже использовалось в C #, как это. Я случайно перегрузил его. Спасибо за указание на это. Я уточню свой ответ, чтобы уточнить.
комбинаторика

Разница между емкостью и длиной: - Емкость может изменяться в течение жизненного цикла объекта, тогда как длина всегда остается неизменной. Если я увижу свойство Length на объекте, я предположу, что это «жесткое» максимальное число (или границу / индекс), а если я увижу свойство Capacity, я предположу, что это «мягкое» максимальное число, которое я должен только проверить против, если я обеспокоен производительностью.
StupidOne

@StupidOne: Если вы идете по этому пути, то любой массив также должен иметь count-property.
Дедупликатор

1
Черт бы побрал StringBuilder ... в более строгих языках, таких как Vigil, класс StringBuilder был бы должным образом наказан за нарушение соглашения github.com/munificent/vigil
Falco
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.