Привет, всем.
Возник вопрос: а что лучше\эффективнее использовать: массивы (MyClass[]) или дженерики (List<MyClass>) ? и почему ?
т.е. не нужно задавать вопрос "для каких целей тебе нужно?" Мне не для конкретных целей, просто хочу узнать в каких случаях лучше array, а в каких List<T> или другие структуры, типа Collection<T> ?

например. Если заранее не известно количесво элементов массива, то лучше использовать List<T>, т.к. не нужно явно вызывать Array.Resize()
или что-то в этом роде...

Ваши мысли, господа !!

ИМХО всегда лучше использовать специализированный класс, чем генерик - генерик в лучшем случае сделает коллекцию твоего типа такой, как ты бы хотел. В худшем - столько лишнего насует!

Массив или коллекция? Это вопрос другой. Смотря какой интерфейс ты хочешь получить. Коллекции имеют методы, которых у массива просто нет. (Но ты их можешь реализовать сам, в классе-обертке твоего массива  ) Даже если посмотреть на обычные коллекции и их генерик-аналоги. Зачастую интерфейсы отличаются. Время идет, программеры думают, что-то передвигают в интерфейсах.


Глубочайшее заблуждение! Чудес не бывает и процессор - не шаман! Внутри коллекции находиться массив заданной размерности. По умолчанию его размер задается 16, 32 (или сколько ты задашь) элементов. При добавлении элемента в коллекцию, если размер, заданный при инициализации, превышен - коллекция как раз и вызывает метод, подобный Array.Resize(). А чаще всего, инициализирует внутренную переменную массива новым массивом, а старый - добыча сборщика мусора!
Просто когда-то были одни массивы, коллекций не было. И дали программерам задание - чтоб были! Вот они и реализовали их через массивы, а как еще? 

Ну вот, вроде не слишком длинно ответил.

ну... например я где-то читал, что List<int> быстрее чем int[], а List<string> по скорости равнозначен string[]. Вот и возник вопрос, что когда лучше?
tol05 т.е. из твоего высказывания я понял, что генерики использовать не стоит (нужно избегать из использование)?
и еще... реализовывая самостоятельно методы, которые реализованы в коллекции, а в массиве нет, есть вероятность, что эти методы будут работать медленнее\не эффективнее, чем в коллекции.

не верю. Я открыл рефлектором класс List<Т> и увидел:

как он может работать быстрее чем T[] ? У него внутри их два и еще много чего, да и свойства, проверки...   

вместо List<string> я всегда использую System.Collections.Specialized.StringCollection. Уже адаптированная под String коллекция... советую почитать.
А по поводу быстродействия - так тестировать можно, на больших объемах данных. Там все видно будет.


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

И не говорил я, что использования генериков избегать нужно. Есть время лишнее - пиши свои классы коллекций, тестируй, пользуйся. Нет времени, быстродействие не принципиально - пользуйся стандартными. Повторяю: ты спрашивал мнения, я высказал только свое.

Глупости, коллекции -- это всего лишь один из случаев применения такой замечательной вещи, как дженерики. А плодить по классу ради специализованной коллекции неразумно и неудобно.



Нет, это вовсе не так.



А зачем изобретать велосипед? Может, оно, конечно, и интересно, но всё же лучше воспользоваться уже существующими классами.



Зацени  .



А чем она лучше List<string>?

Добавлено через 4 минуты и 13 секунд
P.S. Читаем в документации Microsoft:



StringCollection -- лишь обёртка над ArrayList, а последний по вполне понятным причинам менее продуктивен, чем List<T>.

Ну и что? Я открывал System.Collections.Generic.List<T>(версия 2.0.0.0)
У тебя немного другое содержание, согласен. Так что, продуктивнее массива, ты хочешь сказать?


да, не о том немного сказал.  Давно она разрабатывалась. Зато - типизирована. В то время - бомба 


Немного не понял. Коллекции раньше дженериков появились? Так кто кого лечит? 


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

В общем, остаюсь при своем мнении. Обертки - хорошо, но вкуса еды не меняют.

Это сообщение отредактировал(а) tol05 - 31.5.2007, 17:12

Нет, я имею в виду, что, вместо того, чтобы юзать рефлектор, можно посмотреть, как ребята в mono сделали  .




И что? Это ж обёртка над нетипизированным ArrayList. А List<T> типизирован изначально  . Как он может быть хуже этой коллекции?




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




Причём тут обёртки вообще?
Вопрос стоял: что лучше -- T[] или List<T>.
Ответ очевиден: в зависимости от того, нужны ли дополнительные операции, реализующие поведение списка, или нужен именно массив.
Однако же, использование List<T> предпочтительнее использования коллекций из .NET 1.x (например, StringCollection).
В целом же, дженерики -- довольно полезный механизм.

С чем тут спорить-то  ?

А у меня на работе нет на mono лицензии. Матюкаюсь, юзаю рефлектор.  А почему ребята на mono счас так делают? А потому, что не на mono сделано криво. А потом будет стерео, playStation. Но это будет потом, а я работаю сейчас. И говорю - сейчас мне лучше поменьше генериками пользоваться.

Я не говорю, что генерики - плохо. Это хорошо, чтоб быстро написать код, быстро заработать денег и начать зарабатывать следующие деньги. Я прямо сейчас на них пишу DAL-level  
Но если бы мне поставили задачу: оптимизировать собственный код на 10%, я бы только на них, родимых, половину бы отбил

Когда все расхваливают генерики, все прямо тычут ArrayList-ом. Да, по-сравнению с ним, где на каждом шагу надо было приведение типов устраивать, это самолет. Но...

Как насчет того, что код с использованием типизированного массива строится на этапе компиляции, а генериков - в runtime, jit-компилятором? Потому что до вызова метода с генериком никто не знает, например, какого типа будет передаваемый в метод параметр. А распухание кода при компиляции, когда для каждого упомянутого в генерике типа создается отдельный класс (причем код "метод+тип", все комбинации)? Да, ограничения как-то компилятором проверяются, но ты же знаешь, какого уровня эти проверки! класс-не класс. 
А то, что генерики не поддерживают перегрузку операций?
Интересная статья с RSDN "Нововведения в C# 2.0", мне понравилась.

Одним словом. Оба мы используем и то, и другое. Тебе генерики нравятся, мне - не очень. Ну и слава Богу, когда есть разные подходы. Лично я - не против.

Ы? Какая лицензия? Моно опенсорсный.


Не понял. Что не на mono сделано криво? И причём тут игровая приставка?




Ты ошибаешься. Тогда и ООП -- тоже плохо, правда?



Оптимизировать надо только узкие места, и без глупостей, тем более  .



Жаль тебя разочаровывать, но код .NET в любом случае комплируется JIT-компилятором из IL. Или тогда пример кода давай  .




Да неужели? То есть, ты хочешь сказать, что до компиляции тип дженерика неизвестен  ?



Можно пример? Я не понял фразы.



Ну а какого ещё уровня могут быть проверки? Мне это лично непонятно.



Почему?



(правда, насчёт компиляции C я и правда не уверен)



Это как "тебе классы нравятся, мне - не очень". Ну да ладно.

ууу. ребят, чето вы из мухи слона залепили...

1. мое мнение: mono - тот же .NET, только под Linux, Solaris, Mac OS X, Windows, and Unix
И это есь ГУТ!!!!

2. Что лучше T[] или List<T>? 
мое мнение - однозначно всегда и везде надо юзать <T>, но не только массивы или коллекции,
а вообще, господа, надо писать всё <T>, методы, классы, интерфейсы.
Это суть есть абстрагирование, и соответственно лучшее понимание происходящего внутри метода,
остается только чистый алгоритм.
АЛГОРИТМ!, мы ж не кодеры, мы - алгоритмеры   

3. на сечет оптимизации:
кому нать оптимизацию, тот либо должен сразу компилировать managed код (такая возможность, как известно есь)
либо юзать unmanaged.
Но все-же T[] - суть есть Ссылочный тип!!!, лежит он в куче, как и <T>
так что никакой <T> уж точно не медленнее(ну может чуть-чуть), 
разве что памяти в куче больше жрет

Если я сейчас подойду к своему директору и скажу

я через 10 минут буду уволен. Некоторые люди (может я работаю на извращенцев) готовы в 5 раз переплатить, чтобы у них не было головняка, чтобы я не подходил, разводил руками перед ними и гворил, ну что вы хотите от опенсорса! Они мне лицензией в морду ткнут и козла отпущения из меня сделают. Они заказывают музыку, а я пляшу под нее на полную катушку.

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

По поводу ООП, классов и прочего: не нужно хавать все, что подсовывают. Даже если говорят, что "вкус - незабываемый". Это может оказаться "кАкой". Так что, первый фреймворк был немного не ООП? Теперь ООП? Если кое-кого послушать, то Виста - мечта любого нормального человека. А я ее в жизни не поставлю. У меня друзья на Линукс перешли, когда Висту увидели, поюзали, да почитали кое-что...
Exception, ты  с программерами других языков, где генериков нет, поговори. Расскажи им, что они классов не любят, что они ООП не понимают...

Я никому своего мнения не навязываю. Я прошу, если мое мнение кому-то не нравится, если кто-то имеет другое, то хотя бы не нужно мне это свое, другое, навязывать. И не нужно говорить, что я чего-то не понимаю. Я свою позицию вырабатываю осмысленно и пока своих работодателей устраиваю. Чужое мнение нужно если не уважать, то хотя бы принимать как есть.

P.S. повторяю последний раз: я использую и то, и другое. Лично мое мнение: Генерики - удобнее. Массивы и типизированные коллекции - продуктивнее.

Это сообщение отредактировал(а) tol05 - 1.6.2007, 10:07

tol05.
Никто никому не навязывает свое мнение, мы просто тут обсуждаем тему и спорим (это естественно, когда сеществует несколько мнений). Как говориться: "в спорах рждаеться истинна".

SpaceSpace
По поводу 2-го согласен. И все-таки вопрос остаеться в силе.. 
это нужно пробовать на практике.
Т.е. можно писать можно и так и так, но: 
1\ что будет лучшим стилем ?
2\ что будет производительнее ?
т.е. представим себе ситуацию: Вы техлидер, к вам подходит девелопер и задает впорос:
"Слушай... у меня тут метод... должен возвращать массив, что мне лучше использовать List<MyClass> или MyClass[] ?"
Нужно дать ответ с пояснениями, мол лучше напиши List<T> потому что.... или лучше напиши T[] т.к....
Ответом на этот вопрос и будет ответ на мой вопрос 

Если нужно оптимизировать код - предлагаю в первую очередь посмотреть на работу со строками  . Есть опыт, когда дали оптимизировать код и увеличить performance, так вот... заменив все string + string... в циклах на StringBuilder и тому подобное.. быстродействие увеличелось в разы.

Извините все за мой тон. счас я остыл вроде 

Я все же считаю, что никогда не нужно забывать о производительности. Наш код - это не алгоритм на стену. Да, его конечно нужно писать наглядным, легко адаптируемым, по возможности - абстрактным. Но, с другой, стороны, наш код никто из заказчиков смотреть не будет. Заказчику все равно, красивый он, или нет, ему важно: какой объем памяти занимает конечный продукт, сколько ОЗУ он потребляет, как быстро производятся вычисления. И чем эти показатели выглядят лучше (по отношению к показателям конкурента), тем наш продукт конкурентноспособнее. "Алгоритмы - это хорошо (скажет он), только я в них ни фига не понимаю, мне главное, чтоб продукт работал быстро, мало жрал, а меня - наоборот, хорошо кормил" 

Я знаю людей, который с C# на C++ обратно перешли, чтобы выполнить заказ и уложиться в требования по производительности.
А в последнее время многие почему-то не обращают внимания на производительность. Забывают, что компьютер - не резиновый, что если у разработчика стоит Pentium 4 (ну хотя бы  ), то у клиента, которому заказчик продаст продукт (за большие, между прочим деньги) может стоять Pentium 200.

Заказчик конечно может (я правда такого еще не встречал) послушать наши рассказы о том, что в коде применено 8 паттернов,  что все новые фичи юзаются. Но он очень не любит писать на коробочке с продуктом: системмные требования: не ниже.
Потому что он знает, что 75% его потенциальных заказчиков (к примеру) имеют реально у себя "системмные требования" ниже. И не каждый из них побежит за новой машиной ради его продукта...
Идти по пути наращивания мощностей техники ради обеспечения функциональности - это простой путь. Виста, я не зря о ней говорил, в том числе и по пути "всепоглощающей абстракции" сделана. И что? Занимает уйму ресурсов только под обеспечения своей работы. На некоторых машинах, если Висту поставить, так больше ничего и не станет. А операционная система - это только помощник для юзера, а не его хозяин.

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

Если главное - оптимизировать производительность - 
надо писать не на C#, а нa unmaged C++

Если быстродействие не так важно, то

Если логика одинаковая для нескольких методов - нада юзать <T>,
чтобы не писать лишний код

Если заранее известен тип массива и количество элементов - 
нада юзать []
если количество меняется - типизированные коллекции

Если тип массива неизвестен, или элементы разных типов,
тоже от обстоятельств, можно массив Object'ов вообще заюзать...


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

Задачи - абсолютно разные, для каждой - свое, оптимальное решение
Так что,StepS  давай колись, что за конкретная задача

Конкретной задачи нет, просто был класс:
у которого было объявлено поле как string[]


нужно было в Location добавлять значения в цикле. через string[] - не удобно. Вот я и заменил на List<string>. Теперь мучаюсь вопросом, правильно ли сделал ?


люди разные бывают и задают разные вопросы. И не техлидер, тот кто не сможет толково ответить на этот вопрос. Вне зависимости доучен работник или нет. В конечном итоге мы все устраиваемся на работу не доученными (да и когда уже проработаем, тоже: век живи - век учись).
Поэтому ответом на этот вопрос : "Товарищ !!! та ты же не доучен.... а ну ка... иди ка быстренько учись... потом прийдешь и перескажешь мне параграф MSDN-а про Collection"    не являеться грамотным. 
(Сорри, если это кого-то заденет - я не хочу, кого-то обижать или наезжать. Это просто реальность)

Почему в шарпе нету связаного списка? (если List<T> - на самом деле обертка над T[]) или я что-то пропустил?   

archeg,  по-моему, вообще не в тему. В принципе, есть такое. Но есть же TreeNode, ведь по сути связанный список - это унарное дерево.

На каком основании такие заявления?

tol05, ПРИВЕДИТЕ ПРИМЕР (Исходные данные, полученные метрики) - а свое мнение и пространные, большей частью бесполезные рассуждения можете оставить при себе.

У Вас пальцы не устают столько флудить?

Товарищи, вот уж не думал, что эта тема разовьется в такой спор   

Мое мнение: если вы точно знаете размер вашей коллекции и он не изменяется, то однозначно лучше использовать массив (хотя очень часто я использую Лист и в этом случае, ибо он удобнее).
Но если, вы не в курсе, сколько элементов будет у вас в массиве, то лучше использовать специализированную коллекцию.
Одной из таких коллекций является List<string>.
Причем дженерики ни коем образом не относятся к коллекциям, это просто удобный инструмент для создания шаблонных классов, работающих с любым конкретным типом, вместо того, чтобы плодить туеву хучу реализаций одной и той же логики для разных типов.

Перейдем к реализации List<T>:
Да, за дополнительные возможности нужно платить, тут уж не попишешь :( (Что тут у нас, а --- возможность добавления новых элементов без ресайза коллекции).

Чем же мы расплачиваемся: 
В первую очередь памятью. Возможность "безболезненного" увеличения размера коллекции реализована за счет избыточности. Она храним "пустые" ячейки для новых элементов коллекции. Например, коллекция, состоящая из 10 элементов будет хранить 6 (=16-10) пустых ячеек.
Во вторую очередь скоростью доступа. List<T> реализуется как обертка над массивом T[]. Так что при доступе к элементу коллекции мы, в любом случае, обращаемся к массиву:

Что у нас тут? Обращение к массиву (никуда от этого не деться) + трата времени на проверку индекса и сам вызов метода get. Не очень хорошо :(

Вот две основные проблемы использования коллекции вместо простого массива. Есть и более мелкие проблемы, но эти две, ИМХО, самые важные (среди них никому не нужное поле version, которое хранить версию массива, получить которую не представляется возможным, да и нафик она кому нужна, ИМХО).

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

Кроме того, я не зря взял слово "проблемы" в кавычки. Эти "проблемы" действительно не стоят того, чтобы на них обращать внимания в 99,99% случаев. Действительно:
Память. Ну кого, скажите, волнует наличие неиспользованных 6*4 = 24 байт на хранение "резерва" в примере выше, когда совершенно пустое WinForm приложение занимает 4Мб памяти? 
Но все же если вы используете "сотни тысяч" таких коллекций, то стоит пересмотреть свою позицию (это та самая сотая процента)
Производительность. Один запрос к диску, БД, да еще по сети, отображение UI, ожидание ответа пользователя, ...  сводят на нет все проблемы связанные с доступом к элементу коллекции. Так что, если вы не пишите критическую часть приложения, которая будет юзаться "сотни тысяч раз" на протяжении 1 минуты, то можно забить и на эту проблему.


Один из которых статический, т.е. не имеет никакого отношения к конкретному экземпляру. 
Кроме того, на единичных операциях массивы бесспорно выигрывают, но при интенсивном добавлении новых элементов массивы нервно курят в сторонке.

Пример: ты получаешь некие сообщения из нескольких источников (от геодезических зондов, например) и тебе нужно каждую минуту отправлять собранные сообщения дальше. Что лучше использовать?


Позволю себе не согласится. int[], как и любой struct[], является структурным типом, если он: локальная переменная, либо часть другой структуры.

LinkedList<T> (хоть это и двусвязный список)

MSDN:

Arrays (C# Programming Guide)

adLucem, точно, только что протестил. И почему я думал по другому     

Блин, tol05, ты меня не понял  .
Во-первых, насчёт Mono, я имел в виду, что, если хочешь знать, как реализуется какой-то класс, то можно посмотреть в него, и призывать тебя что-то говорить начальнику или хотя бы самому юзать Mono я даже не собирался  . Кстати, Mono -- не .NET под Линукс, он кроссплатформенный и может работать и под Windows.
Насчёт дженериков, если ты решил что эта идея нова и "подсунута Билли", то ты сильно ошибаешься, так как она ещё более полно реализована в С++ (шаблоны) и многих других языках. Да и в Java они есть (хотя там это синтаксический сахар). Если ты не научился использовать какое-то средство языка разумно, не стоит делать преждевременных выводов о нём. Дженерики часто бывают полезны, например, при разработке и использовании многоцелевых каркасов приложений (типа CAB). Однако, само собой, их не надо лепить где попало, так как абстрагирование местами только усложняет проектное решение.
Массив следует использовать, когда нужен массив, а список -- когда нужен список  . А спор такой разгорелся именно потому что автор задал вопрос в отрыве от контекста: что лучше, сыр или колбаса? Всё зависит от того, что ты хочешь скушать  .

  
  
Да ладно... Действительно, правильно ivashkanet, выразился - если три-четыре горячих парня встретятся, то жди беды   и не важно, на какую тему говорить! 
Генерики - не шаблоны.
http://blogs.gotdotnet.ru/personal/mihaili...50-B21953401B95
 Java - не смотрел, думал в отпуске заняться
все, типа сдаюсь.