В программировании мне ни разу не приходилось сталкиваться с ситуацией,
когад массив был бы лучшим решением для хранения информации, чем любая иная
его форма. Я думал, что добавочные «фишки» в языках программирования улучшили
массивы и, тем самым, их заменили. Теперь я вижу, что они не заменены, а, наоборот,
обрели, так сказать, новую жизнь
Я увидел это сообщение на Реддите и реакия была далеко не благосклонной. Большая часть обсуждения сконцетрировалась на том, насколько глуп сам вопрос, и на ошибках образовательного и профссиональных сообществ, которые привели к тому, что такие базовые вещи не известны. К сожалению, моя первая реакция была такой же.
После некоторого размышления я понял, что вопрос не такой уж и глупый. Я понял, что я не использую массивы в Эрланге, они там просто не нужны. Программируя на С и С++, я постоянно их использовал, потому что я был практически вынужден их использовать. Но в Эрланге на передний план выходят списки. В Эрланге есть средства для работы с массивами, но максимум, на который я приближаюсь к использованию их — это в использовании маленьких кортежей фиксированой длины. Странно, но я только сечас заметил, насколько редко я использую массивы. Единственно место, где я их применяю, программируя на Эрланге, это для организации поиска по двоичным ключам в коде двоичных деревьев в CouchDB.
Правда состоит в том, что, если вы не занимаетесь низкоуровневым программированием, массивы (и даже векторы) редко необходимы или оптимальны дл большинства задач. Самая яркая особенность массивов — это константное время доступа к любому значению по порядковуму номеру. Проблма состоит в том, что мало какая задача требует константного времени доступа к значениям по порядковым значениям. Массивы в основном применяются как коллекции данных, для чего больше подходит список.
А как часто вы используете массивы?
ЗЫ. Сорри за корявоватый перевод. Оригинал — по ссылке в начале поста
Здравствуйте, Mamut, Вы писали:
M>А как часто вы используете массивы?
Часто. К примеру, прекрасное средство оборвать ленивость итераторов. Неплохо массивы смотрятся в качестве элементов контракта в виду своей легковесности и стандартности, а если нужно переменное число параметров, то вообще альтернативы нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Mamut, Вы писали:
M>>А как часто вы используете массивы?
AVK>Часто. К примеру, прекрасное средство оборвать ленивость итераторов. Неплохо массивы смотрятся в качестве элементов контракта в виду своей легковесности и стандартности, а если нужно переменное число параметров, то вообще альтернативы нет.
Т.е. именно производная от System.Array, а не IList или что-то подобное?
Здравствуйте, _FRED_, Вы писали:
_FR>Как тип для входных данных (параметров) или выходных (возвращаемое значение)? Или и там и там?
Для входных. Разумеется, если такие параметры подразумевают массивы с сравнительно небольшим количество элементов, чтобы лишнее копирование не приводило к снижению перформанса.
_FR>Какие преимущества (иными словами, "чем лучше") будет иметь тип возвращаемого значения T[] перед IList<T> и в каких ситуациях?
Менее тяжеловесный объект, проще читается контракт, BCL сама часто использует массивы, необходимость копирования в некоторых случаях передаваемых значений (массив самый лучший кандидат на копирование в него), ковариантность.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Mamut, Вы писали:
M>А как часто вы используете массивы?
Подразумевается .net, или вообще все что можно?
Автор статьи писал конкретно про C, C++, Erlang...
Я считаю, что ответ на вопрос про массивы довольно сильно зависит от языка, а не только от личных предпочтений.
А тут прибежали дотнетчики, которые привыкли списком обзывать List<T>, который на самом деле вектор а не список, т.к. имеет константное время доступа
2All
Кстати, между прочим, в каких языках кроме .net-овских принято использовать стандартные интерфейсы контейнеров, аки IList<T>, чтобы можно было подсунуть разные реализации?
почти нет. но все зависит от языка и от прикладной задачи само собой. в с++ обычно vector для хранения и итераторы для доступа. c# — List для хранения и IEnumerable для доступа.
Здравствуйте, samius, Вы писали:
S>2All S>Кстати, между прочим, в каких языках кроме .net-овских принято использовать стандартные интерфейсы контейнеров, аки IList<T>, чтобы можно было подсунуть разные реализации?
Думаю во всех, где есть понятие интерфейса как минимум. В Java например.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
S>Кстати, между прочим, в каких языках кроме .net-овских принято использовать стандартные интерфейсы контейнеров, аки IList<T>, чтобы можно было подсунуть разные реализации?
В Джаве, причём названия контейнеров там будут получше, чем в .NET FCL.
_FR>>Какие преимущества (иными словами, "чем лучше") будет иметь тип возвращаемого значения T[] перед IList<T> и в каких ситуациях?
AVK>ковариантность.
Разве ковариантность — это преимущество? Jon Skeet пишет:
So why are arrays covariant? According to the CLI Annotated Standard, for the first edition the designers wished to reach as broad an audience as possible, which included being able to run code compiled from Java source. In other words, .NET has covariant arrays because Java has covariant arrays — despite this being a known “wart” in Java.
Здравствуйте, Qbit86, Вы писали:
S>>Кстати, между прочим, в каких языках кроме .net-овских принято использовать стандартные интерфейсы контейнеров, аки IList<T>, чтобы можно было подсунуть разные реализации?
Q>В Джаве, причём названия контейнеров там будут получше, чем в .NET FCL.
Я так и не понял, чем же "получше"
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Qbit86, Вы писали:
_FR>>Какие преимущества (иными словами, "чем лучше") будет иметь тип возвращаемого значения T[] перед IList<T> и в каких ситуациях?
Q>Имхо, вместо этих типов лучше использовать List<T> и IEnumerable<T>.
Так вот прям List<>? Не IList<>?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, Qbit86, Вы писали:
_FR>>>Какие преимущества (иными словами, "чем лучше") будет иметь тип возвращаемого значения T[] перед IList<T> и в каких ситуациях?
Q>>Имхо, вместо этих типов лучше использовать List<T> и IEnumerable<T>.
_FR>Так вот прям List<>? Не IList<>?
Тут у меня следующие соображения:
Если говорить о типе возвращаемого значения метода, то принято считать что в другой раз вернется другой экземпляр коллекции, потому возвращаемый тип может быть изменяемым (Properties vs. Methods). Здесь будет одинаково уместно использовать T[] или List<T>, но List<T> удобнее, т.к. у него больше сервисов, потребитель метода сможет что-то с результатом сделать по своему усмотрению. Здесь главное не мешать массивы с листами, т.к. у одного Count а у другого Length
Если говорить о типе возвращаемого значения свойства — то согласно тому же руководству принято считать, что при обращении к свойству вернется тот же самый экземпляр коллекции. И тогда надо думать о том, как бы этот экземпляр не испортить. T[] тут однозначно не подходит. List<T> может подойти если предусмотрено изменение коллекции, если не предусмотрено, то IList<T> и в качестве результата будет возвращаться readonly обертка. Но каждый раз один и тот же ее экземпляр, т.е. readonly обертку я кэширую, а не создаю каждый раз новую типа
get { return _fooList.AsReadonly(); }
А IEnumerable возвращаю только там, где по каким-то причинам не удобно возвращать коллекцию, а выгодно вернуть именно перечислитель.
Кстати, считаю, что было бы здорово, если бы Enumerable.Range и подобные ему методы возвращали бы IList<int>. Ничего не стоило бы определить для того перечислителя Count и индексированный доступ к элементам.
Здравствуйте, samius, Вы писали: S>А IEnumerable возвращаю только там, где по каким-то причинам не удобно возвращать коллекцию, а выгодно вернуть именно перечислитель. S>Кстати, считаю, что было бы здорово, если бы Enumerable.Range и подобные ему методы возвращали бы IList<int>. Ничего не стоило бы определить для того перечислителя Count и индексированный доступ к элементам.
Ну, тогда это был бы List.Range
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
В Джаве контейнеры именованы более последовательно. Их название состоит ровно из двух частей, вторая часть соответствует абстр. типу данных (интерфейсу), первая часть — структуре данных, лежащей в основе реализации (определяет асимптотику операций):
List: ArrayList, LinkedList
Map: HashMap, TreeMap
А теперь сравни с названиями тех же дженерик-коллекций из .NET:
IList: просто List, LinkedList
IDictionary: просто Dictionary, SortedDictionary
Здравствуйте, samius, Вы писали:
_FR>>>>Какие преимущества (иными словами, "чем лучше") будет иметь тип возвращаемого значения T[] перед IList<T> и в каких ситуациях? Q>>>Имхо, вместо этих типов лучше использовать List<T> и IEnumerable<T>. _FR>>Так вот прям List<>? Не IList<>?
S>Тут у меня следующие соображения: S>Если говорить о типе возвращаемого значения метода, то принято считать что в другой раз вернется другой экземпляр коллекции, потому возвращаемый тип может быть изменяемым (Properties vs. Methods).
+1
S>Здесь будет одинаково уместно использовать T[] или List<T>, но List<T> удобнее, т.к. у него больше сервисов, потребитель метода сможет что-то с результатом сделать по своему усмотрению. Здесь главное не мешать массивы с листами, т.к. у одного Count а у другого Length
Не удобнее: Why we don’t recommend using List<T> in public APIs
От себя добавлю: если метод возвращает List<T>, то, учитывая, что этот класс никак не расширяем, реализация _вынуждена_ или возвращать уже имеющийся экземпляр List<T> или откуда-то копировать данные в List<T>. Допустим, сегодня мой класс имеет поле типа List<T> и показывает его наружу через свойство типа List<T>. Но вот прошло время, и нам надо бы внутри класса реагировать на изменение списка. А как? List<T> подобной функциональности не предоставляет, и придётся менять интерфейс класса, тогда как при использовании интерфейсов подобное изменение можно было сделать "прозрачно" для внешнего мира. Или, например, потребовалось проверять, что в списке не более двух одинаковых значений. По-уму. надо написать своего наследника Collection<T>, в котором можно "прозрачно" для внешнего мира. Если мы не хотим менять интерфейс класса, нам придётся эту логику добавить в наш класс.
С массивами, к слову сказать, та же история.
В общем, примеров, чем неудобен List<>, можно привести миллион. Ни одного примера его удобства я не знаю.
S>Если говорить о типе возвращаемого значения свойства — то согласно тому же руководству принято считать, что при обращении к свойству вернется тот же самый экземпляр коллекции. И тогда надо думать о том, как бы этот экземпляр не испортить. T[] тут однозначно не подходит. List<T> может подойти если предусмотрено изменение коллекции, если не предусмотрено, то IList<T> и в качестве результата будет возвращаться readonly обертка.
А вот если мы знаем, что выставляем наружу "readonly обертку", то и тип надо использовать соответствующий: ReadOnlyCollection<>. Зачем List<>?
S>А IEnumerable возвращаю только там, где по каким-то причинам не удобно возвращать коллекцию, а выгодно вернуть именно перечислитель.
Через свойство? ИМХО, имеет право на жизнь, только если в классе есть поле типа IEnumerable. Тогда можно вернуть эту переменную. А вот такие свойства:
IEnumerable<string> Names {
get {
for(var s in smth()) {
yield return"_" + s;
}//for
}
}
На самом деле являются поделками детей, решивших поиграть в ыункциональный подход. "Такое" надо делать методами.
S>Кстати, считаю, что было бы здорово, если бы Enumerable.Range и подобные ему методы возвращали бы IList<int>. Ничего не стоило бы определить для того перечислителя Count и индексированный доступ к элементам.
Да ну: кому надо, ToList() или, что ещё лучше, ToArray() вызовет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Help will always be given at Hogwarts to those who ask for it.
IList<T> не нужен практически никогда (имхо). Если ты в своём коде используешь IList<T>, то скорее всего, его нужно заменить либо на IEnumerable<T> (если обращение по индексу никогда не используется, а используется только перечисление), либо на List<T> (если обильно используется случайный доступ по индексу, то лучше входной параметр функции фиксировать этой конкретной реализацией IList'а, чтобы пользователь функции не мог передать связный список и поиметь падение производительности).
Здравствуйте, Qbit86, Вы писали:
_FR>>Так вот прям List<>? Не IList<>?
Q>IList<T> не нужен практически никогда (имхо). Если ты в своём коде используешь IList<T>, то скорее всего, его нужно заменить либо на IEnumerable<T> (если обращение по индексу никогда не используется, а используется только перечисление), либо на List<T> (если обильно используется случайный доступ по индексу, то лучше входной параметр функции фиксировать этой конкретной реализацией IList'а, чтобы пользователь функции не мог передать связный список и поиметь падение производительности).
А почему не на MyCustomList<T> или MyCustomList2<T>? Или вместо них я должен IEnumerable<T> использовать?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Help will always be given at Hogwarts to those who ask for it.
