Привет, всем.
Возник вопрос: а что лучше\эффективнее использовать: массивы (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"    не являеться грамотным. 
(Сорри, если это кого-то заденет - я не хочу, кого-то обижать или наезжать. Это просто реальность)