Почему в шарпе нету связаного списка? (если 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 - не смотрел, думал в отпуске заняться
все, типа сдаюсь.