Когда использовать Array () над Generic.Lists в .NET

Question

когда уместно использовать массив поверх общего списка (из T) в .NET

Я изо всех сил пытался увидеть какую-либо выгоду, предоставляемую массивом по сравнению с универсальным списком, но у меня возникло ощущение, что я что-то упускаю Производительность - это то, что поразило меня как одно потенциальное узкое место?

Спасибо

Answer 1

Прочтите эту статью Эрика Липперта: http://blogs.msdn.com/ericlippert/archive/2008/09/22/arrays-considered-somewhat-harmful.aspx

Вы, вероятно, никогда не должны возвращать массив из открытого свойства или метода.

Answer 2

Я думаю, что Эрик Липперт говорит это лучше, чем я мог:
http://blogs.msdn.com/ericlippert/archive/2008/09/22/arrays-considered-somewhat-harmful.aspx

Answer 3

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

Я хотел бы отметить, что в то время как массивы имеют ковариацию, общий списков нет. Например, массив типа MyChildClass[] можно легко приведен к MyParentClass[], в то время как List<MyChildClass> нельзя кастовать до List<MyParentClass>, по крайней мере, нет непосредственно.

Если вам нужна ковариация, либо используйте массивы, используйте метод Cast () LINQ или некоторые другие способы разыграть каждый предмет в индивидуальном порядке.

Answer 4

Когда вы используете фиксированное число объектов данного типа, нет смысла принимать небольшое снижение производительности, связанное с классом List, поскольку вы не будете использовать ни одну из его функций.

Answer 5

Другая причина использования обычных массивов - это когда вы работаете с вызовом платформы (выполняете неуправляемый код на языке c / c ++), но это ограничено очень небольшим набором приложений

Также, как замечание: если размер массива известен, но вы все еще хотите использовать общий список, не забудьте передать размер параметру емкости конструктора.

например:

List<int> lst = new List<int> (100);

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

Answer 6

Если вы хотите кэшировать фиксированное количество данных, используйте массивы. В противном случае, используйте общие списки ... они проще в использовании, обеспечивают большую гибкость и набираются (нет необходимости в упаковке / распаковке) ... просто так. Кроме того, массив имеет фиксированную длину, а списки могут быть переменными и изменяться в любое время. Причины могут продолжаться и на том, почему использовать общий список против массива. Массивы - просто боль в заднице. И, честно говоря, снижение производительности при использовании списка по сравнению с массивом, вероятно, можно обсудить до n-й степени

Answer 7

Насколько нам известно, массивы являются примитивной структурой данных, если вам нужно вставить или удалить элементы в средней позиции, а также отсортировать их, обычно на устаревших языках это требуется программисту, а не во время работы с объектом List, таким как DotNet Generics, все эти операции уже выполнены для вас.

Более того, массивы сильно ограничены, только те же элементы типа данных и т. Д.

На сегодняшний день вычислений я не вижу преимущества использования массивов.

Привет.

Answer 8

Многие структуры данных более высокого уровня (включая List) используют массивы для внутреннего использования, это единственный способ сохранить необработанную последовательность в памяти - поэтому массив должен существовать на языке программирования, иначе у вас не будет структур данных более высокого уровня .

Мое мнение таково, что если вам не нужно (например, потому что вы используете компонент, который требует его), вы никогда не должны использовать массивы - особенно не пишите код, который возвращает массивы, они принимают массивы в качестве параметров, поэтому вы не должны заставлять других использовать массивы тоже.

Единственное исключение (на мой взгляд) - это тот редкий случай, когда вам нужна коллекция известного фиксированного размера в качестве локальной переменной, чем просто кажется расточительным использовать что-то еще.