Re[5]: Только мне в дотнете не хватает неизменяемого массива - .NET

Здравствуйте, Flem1234, Вы писали:

F>Здравствуйте, VladD2, Вы писали:

VD>>Только мне в дотнете не хватает неизменяемого массива?

F>Ради бога, объясни, зачем именно неизменяемый массив. У него же главная фишка — доступ по индексу, который чаще всего используется в императивном стиле. А неизменяемость из мира фп.

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

Достаточно вообразить что рекомендации к применению массивов распространяются на строки и что из этого последует, тогда станет ясно, насколько строки в этом отношении юзабельнее массивов.

Конечно же можно написать свой MyImmutableArray<T>. Но во-первых он MyImmutableArray, чего уже самого по себе достаточно для того что бы он применялся местячково и не использовался бы в API никаких других библиотек. А значит удобства от его использования не будет. Во вторых — это обертка со своим оверхедом на доступ к элементам, перебор.

F>Ну да, было бы здорово, чтобы рантайм нета так же хорошо поддерживал ФП как и какой-нибудь хаскель, но боюсь этого не будет

Речь не об этом.
Не знаю, какие мотивы у VladD2, но мои — это рекомендации по использованию или точнее неиспользованию массивов в гайдлайнах и отсутствие удобной и доступной для всех алтернативы им из коробки.

Здравствуйте, Аноним, Вы писали:

VD>>Только мне в дотнете не хватает неизменяемого массива?

А>Зачем тебе неизменяемый массив ?

Мужики. Вы достали вопросом на вопрос отвечать.

Не понимания, так проходите мимо.

А>.Net это библиотека для разработчиков ПО, а не для философов, поэтому там есть много удобных вещей для практиков и мало для теоретиков.

Зачем пустословить? Я же говорю, нечего сказать — проходи мимо.

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

Глубокая мысль, уважаемый К.О.!

А>Если для внешней библиотеки нужна "защита от дурака" то на практике проблема решается написанием несложной обертки.

Еще более глубокая мысль, глубокоуважаемый К.О.!

Здравствуйте, samius, Вы писали:

S>Гораздо интереснее как он будет соотноситься с классом System.Array в терминах ковариантности. Точнее это не сильно интересно, а должно иметь место. Т.е. нужно что бы изменяемый массив можно было подавать в качестве неизменяемого.
Не уверен в выделенном. Тогда нельзя будет написать код, полагающийся на иммутабельность переданного ему аргумента.
Простейший пример: класс Url может проверять права доступа к переданному адресу в конструкторе, и полагаться на то, что никто его не подменит, благодаря иммутабельности строк. Иначе атакующий сможет подменять адрес после проверки, но до обращения.

Только мне в дотнете не хватает неизменяемого массива?

Здравствуйте, samius, Вы писали:

S>Гораздо интереснее как он будет соотноситься с классом System.Array в терминах ковариантности. Точнее это не сильно интересно, а должно иметь место. Т.е. нужно что бы изменяемый массив можно было подавать в качестве неизменяемого.

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

Поступить надо так. Ковариантность и контравариантность надо разрешить только для неизменяемых массивов. Для изменяемых ее надо запретить. Все равно ею мало кто пользуется. А если пользуется, то скорее всего не меняет содержимого. Например, методы вроде em.Windows.Forms.ListBox.Items.AddRange(object[] items) должны быть изменены на принимающие неизменяемые массивы.

Здравствуйте, VladD2, Вы писали:

VD>Только мне в дотнете не хватает неизменяемого массива?

Есть, объявляется вот так


 var arr = new ReadonlyArray<int>( new int[] { 1,2,3,4} );

Чтоб работало надо прописать 6 магических строк

public class ReadonlyArray<T> : Array
{
   T[] _a;
   public ReadonlyArray( T[] a ){ _a = a; }
   public this[int index] { get{ return array[index]; } }
}

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>То есть речь о том, что если бы были такие массивы, то в методе записи в Stream должен был бы использвоаться иммутабельный массив, и тогда для блочного копирования пришлось бы задвинуть на реюз блоков?
S>Ну да, ваша же аргументация —
S>

S>проблема не в том что кто-то пытается изменять данные, а в том что по данным (по типу) не видно, можно ли их изменять, изменятся ли они "сами" со временем, как в случае со строкой.

S>?

S>Я всего лишь довёл до абсурда, т.к. все предыдущие намёки на сомнительную полезность immutable-массивов при существующем положении дел как-то прошли мимо.
Этот намек тоже. Не вижу абсурда.

S>>Вообще говоря я не предлагал переписывать фреймворк, но если бы такое случилось, я бы предпочел что бы Stream.Write принимал бы иммутабельный буфер, либо перегруженный метод, принимающий иммутабельный буфер.
S>А заполнялся бы этот immutable буфер копированием. Потому что в ряде сценариев буфер сначала собирают по кусочкам, из нескольких источников, а затем — скармливают в output.
Так в чем проблема?

S>>Как бы ROC<T> не была создана, сам вид ROC<T> не обеспечивает видимости гарантии неизменности данных извне. Т.е. для того что бы понять, будут меняться данные или нет в этом ROC<T>, мне нужно открыть рефлектор и убедиться что ROC<T> создан с копированием данных, а не как-то иначе.

S>Это _очень_ редкий и абсолютно бесполезный для самого фреймворка юз-кейз. Поэтому или писать правило для FxCop, или создавать свою коллекцию, или писать в feedback, или ждать, пока МС вплотную займётся поддержкой неизменяемых типов данных.
Конечно редкий и бесполезный. Если бы изначально в фреймворке строки были бы изменяемыми, то сейчас бы юзкейзы с неизменяемыми строками тоже казались бы не стоящими внимания.

Sinix! Я свою точку зрения изложил, надеюсь она понятна. Мы обменялись аргументами, и судя по всему, остались при своем. То что нет иммутабельного массива я считаю серьезным упущением. На то что он появится когда-либо серьезно не рассчитываю. От того что кто-то кого-то убедит, мало что изменится в текущей ситуации, потому предлагаю на сим закончить.

Здравствуйте, VladD2, Вы писали:

VD>Только мне в дотнете не хватает неизменяемого массива?

Array.AsReadOnly();

Здравствуйте, VladD2, Вы писали:

VD>Только мне в дотнете не хватает неизменяемого массива?

Ради бога, объясни, зачем именно неизменяемый массив. У него же главная фишка — доступ по индексу, который чаще всего используется в императивном стиле. А неизменяемость из мира фп.

Ну да, было бы здорово, чтобы рантайм нета так же хорошо поддерживал ФП как и какой-нибудь хаскель, но боюсь этого не будет

VD>1. Использовать абстрактные типы данных для инкапсуляции изменяемых структур данных (по большей части массивов).
VD>2. Использование разных неизменяемых типов вроде связанных списков.

VD>Не говоря уже, что второй подход — это почти первый замечу только, что оба подхода создают ощутимый и совершенно бесполезный оверхэд.

Какой оверхед ?
Напиши обертку которая бы не делала копирование, в чем проблема то ? Виртуальные вызовы оверхед ощутимый не создают. Иначе quake3 и друиге игры не писались бы с подходом ООП.

А фича реквесты есть намного более важные, чем готовые обертки в 10 строк для ленивых.

Здравствуйте, VladD2, Вы писали:

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

Во многих ФЯ отсутствует неизменяемый массив, как "низкоуровневый строительный блок". Scheme, Haskell, Ocaml, Scala — таких нет.

ИМХО основная причина отсутствия immutable array как обычно:

because no one ever designed, specified, implemented, tested, documented and shipped that feature.

(с) Угадай кто

Хотя после твоего поста склоняюсь к мысли что с развитием ФП в .NET, помогла бы такая фича, как константность как в C++, даже такая нечестная.

ЗЫ. А кто мешает в качестве низкоуровневневых строительных блоков применять обычные массивы? Главное не отдавать их наружу.

Здравствуйте, Sinix, Вы писали:

S>Как быть с Legacy, работающим именно с Array?

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

S>Как описывать многомерные массивы?

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

VD>>2. Создал бы двух его наследников System.MutableArray[T] и System.ImmutableArray[T].
S>Каст от одного к другому — копированием? Тогда вызов метода, принимающего ImmutableArray будет неэффективным.

S>Обёрткой?

Почему? Нет, конечно. Базовый тип просто не должен содержать реализации.

S>Тогда — никаких гарантий, что многопоточный код не изменит значения в ячейках массива.

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

S>Наконец, что делать, если значения в массиве — mutable?

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

Если же в массиве лежит ссылка на объект содержащий изменяемые поля, то их можно будет по прежнему изменять, так как это память уже не принадлежит массиву.

Тут нет никаких отличий от обычных массивов. С ними та же байда.

VD>>3. Ввел бы концепцию "хвостовых массивов".
S>Что это даст и в каких сценариях будет полезно? В 99.(9)% доступ к массиву осуществляется не напрямую, так что выигрыш будет съеден стоимостью вызова ацессора.

Выигрыш в том, что объект и массив размещаются в единой области памяти. Не нужно тратить 12 байт на второй объект, и не нужно делать ссылки на него. Массив просто находится по определенному смещению в теле объекта.

Естественно, что от таких типов нельзя будет наследовать другие типы (они должны быть sealed). В прочем, наследование тоже можно реализовать, но при этом доступ к полям наследников будет менее эффективен (так как нужно будет учитывать смещение определяемое количеством элементов в массиве).

VD>>4. Ввести в рантайм признак неизменяемости для хвостовых массивов (что-то типа readonly, но распространяемого на хвостовые массивы).
VD>>6. Реализовать System.MutableArray[T] и System.ImmutableArray[T] с использованием хвостовых массивов при этом пометив хвостовой массив в System.ImmutableArray[T] как неизменяемый.
S>Зачем? Практически везде внутренняя реализация массивов отдана на откуп рантайму. Добавим уровень абстракции — пожертвуем производительностью и огребём проблем с интеропом.

Затем чтобы:
1) небыло хардкода в рантайме;
2) прикладные программисты могли бы создавать контейнерные типы не менее эффективне нежели те, что захаркодены в рантайме.

Производительность от этого не только не пострадает, но и существенно выиграет, так как систама станет проще, а прикладные программисты смогут создавать более эффективные контейнерные типы.

То что сделано в донтете сегодня — это просто кривой хардкодинг двух типов в рантайме и наплевательское отношение к остальным типам.

Почему System.Strung эффективнее чем List<T>?

VD>>7. Ввести некий атрибут позволяющий помеченному им методы-инициализаторы. В рамках таких методов будет доступна инициализация поэлементная System.ImmutableArray[T], но после выхода управления из таких методов массив уже больше не может подвергаться модификации.
S>И ещё добавить трассировку — чтобы метод не вызвали более одного раза. И кидать исключения при попытке обратиться к элементам до инициализации.

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

S>Не много ли костылей мы ввели ради абстрактной чистоты?

Костыли додумал ты. Как раз получается очень чистая и универсальная реализация. Причем она позволила бы реализовать эффективно не только массивы, но и любые контейнерные типы.

Из магии и хардкодинга все превратилось бы в четко описанные правила.

S>А сколько придётся вводить для многомерных массивов/массивов с ненулевой индексацией?

Массивов с индексом отличным от нуля в дотнете и так нет. Для эмуляции можно использовать классы. С многомерными массивами никаких проблем не будет. Ты их опять же сам придумал. Вся разница многомерных массивов заключается только в наличии у них метаатрибута "размерность". В остальном это такой же непрерывный участок памяти.

Здравствуйте, VladD2, Вы писали:

VD>Только мне в дотнете не хватает неизменяемого массива?

А еще не хватает константных функций-членов:

type Function(...) const; // с++

И передачи параметров по константной ссылке:

type Function(const type &param); // с++

Или это как-то косвенно имеется? Просто почти во всех нормальных книжках по C++ все эти конструкции обсуждаются терминах безопасности кода, но читая книжки по С# я не встречал ни слова про это.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, adontz, Вы писали:

A>>А это вообще где-то есть?

VD>Меня это не волнует. Думаю, что где-нить в ОКамле или Хаскеле должно быть. Плюс в С++ можно добиться похожего поведения (если закрыть глаза на возможность плевать на все и реинтерпретировать память).

VD>И это печально. Дотнетчики не видят ничего дальше своего носа. МС сам воспитывает такой менталитет.

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

Вот пишут люди на окамлах промышленную фигню десятки лет и не понимают, что же им в функциональном языке не хватает... ах да, неизменяемых массивов!

Лично мне гораздо унылее от того, что в дотнетах из коробки нету какой-нибудь структуры данных типа VList, чтобы и внешне иммутабельно, и доступ по индексу/вычисление длинны быстрее чем O(n), и оверхеда по памяти и нагрузки на GC поменьше, чем у linked list.

Здравствуйте, VladD2, Вы писали:

A>>Это константность вообще, а не только массива.
VD>Да как хочешь называй, а создать аналогичный массив на дотнете невозможно. И это просто бредовый просчет создателей системы.

Просчёт — это отсутствие константности вообще. Из-за неё нельзя, например, сделать switch по объектам произвольного типа. С другой стороны, я не понимаю как это можно реализовать на уровне run-time без кучи проверок.

А>>.Net это библиотека для разработчиков ПО, а не для философов, поэтому там есть много удобных вещей для практиков и мало для теоретиков.

VD>Зачем пустословить? Я же говорю, нечего сказать — проходи мимо.

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

Здравствуйте, QrystaL, Вы писали:

VD>>Только мне в дотнете не хватает неизменяемого массива?

QL>

QL>Array.AsReadOnly();
QL>

QL>?

Массив — это монолитная структура данных. А AsReadOnly создает ReadOnlyCollection, что совершенно не нужный оверхэд, да и исходный массив он от изменения не защищает.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, QrystaL, Вы писали:

VD>>>Только мне в дотнете не хватает неизменяемого массива?

QL>>

QL>>Array.AsReadOnly();
QL>>

QL>>?

VD>Массив — это монолитная структура данных. А AsReadOnly создает ReadOnlyCollection, что совершенно не нужный оверхэд, да и исходный массив он от изменения не защищает.

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

Только оверхед вроде ReadOnlyCollection может гарантировать неизменность. А что бы гарантировать неизменность и с ним, нужно AsReadOnly вызывать у клона исходного массива.

Я так понимаю, исходный вопрос риторический? В таком ракурсе — да, мне тоже не хватает встроенного неизменяемого массива. Ну т.е. было бы круто если бы он был. Но никакой надежды что он будет на уровне дотнета — нет. А вот языки в свою очередь могли бы обеспечивать что-то вроде const ref-а хотя бы на уровне компиляции. И я не понимаю, почему const ref-а нет до сих пор

Здравствуйте, QrystaL, Вы писали:

QL>Здравствуйте, VladD2, Вы писали:
VD>>Массив — это монолитная структура данных. А AsReadOnly создает ReadOnlyCollection, что совершенно не нужный оверхэд, да и исходный массив он от изменения не защищает.

QL>А в каких языках есть пример того, что вам нужно?

Наверно, C++: const T [], const T *, const std::vector, const my_cool_array, etc.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, adontz, Вы писали:

A>>Спрашивали про массив

VD>Дык для полей есть readonly (в терминалогии шарпа). Почему бы не сделать решение полноценным и не позволить объявлять неизменяемые массивы?

Думаю дело лишь в том, что концепция константности из C++ несколько чужеродна для других .NET-языкам.

Вводить const в VB.NET и все остальные .NET-языки?

Игнорировать в других языках, оставив фичу лишь для C# и C++/CLI? Какой с этого толк?

Здравствуйте, VladD2, Вы писали:

VD>Только мне в дотнете не хватает неизменяемого массива?

Зачем тебе неизменяемый массив ? Просто так для красоты ? Увеличить быстродействие на 0.1% ?

.Net это библиотека для разработчиков ПО, а не для философов, поэтому там есть много удобных вещей для практиков и мало для теоретиков.

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

Если для внешней библиотеки нужна "защита от дурака" то на практике проблема решается написанием несложной обертки.

Здравствуйте, adontz, Вы писали:

A>Просчёт — это отсутствие константности вообще. Из-за неё нельзя, например, сделать switch по объектам произвольного типа.

В Nemele можно, так что — мимо.

A>С другой стороны, я не понимаю как это можно реализовать на уровне run-time без кучи проверок.

Неизменяемые массивы то? А как System.String реализован?

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

Здравствуйте, VladD2, Вы писали:

A>>С другой стороны, я не понимаю как это можно реализовать на уровне run-time без кучи проверок.
VD>Неизменяемые массивы то? А как System.String реализован?

System.String не фундаментальный тип. Это обычный класс у которого свойство this[int] без сетера.

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

А другим языкам что делать?

Здравствуйте, samius, Вы писали:

S>Дело тут не в ФП, а в usage-ах. Изменяемый массив фактически обречен на внутреннее использование из-за возможности его изменить. Массив не рекомендуется возвращать без копирования, причем скопированный массив не следует затем кэшировать (может быть изменено извне). Любые обертки дают оверхед по производительности (часто незначительный), но не предотвращают изменения содержимого оригинального массива.

S>Достаточно вообразить что рекомендации к применению массивов распространяются на строки и что из этого последует, тогда станет ясно, насколько строки в этом отношении юзабельнее массивов.

Ну, слава богу! А то я уже начал бояться, что тут собралось одно интеллектуальное большинство.

S>Конечно же можно написать свой MyImmutableArray<T>. Но во-первых он MyImmutableArray, чего уже самого по себе достаточно для того что бы он применялся местячково и не использовался бы в API никаких других библиотек. А значит удобства от его использования не будет. Во вторых — это обертка со своим оверхедом на доступ к элементам, перебор.

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

F>>Ну да, было бы здорово, чтобы рантайм нета так же хорошо поддерживал ФП как и какой-нибудь хаскель, но боюсь этого не будет

S>Речь не об этом.
S>Не знаю, какие мотивы у VladD2, но мои — это рекомендации по использованию или точнее неиспользованию массивов в гайдлайнах и отсутствие удобной и доступной для всех алтернативы им из коробки.

На самом деле вы оба правы. Неизменяемость и есть главное что дает ФП. Остальное это красивые средства укорачивания кода. Они конечно важны и приятны, но не являются столь уж необходимым фактором. А вот неизменяемость и вытекающий из него стиль программирования основанный на трансформации данных — это и есть суть ФП.

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

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

Здравствуйте, VladD2, Вы писали:

VD>Только мне в дотнете не хватает неизменяемого массива?

А как ты его создавать и инициализировать собираешься? Через "ImmutableArrayBuilder" какой-нибудь???

Здравствуйте, Аноним, Вы писали:

VD>>Не говоря уже, что второй подход — это почти первый замечу только, что оба подхода создают ощутимый и совершенно бесполезный оверхэд.

А>Какой оверхед ?

Самый обычный. Вместо создание одного объекта нужно создавать два. Учитывая, что даже на х86 объект занимает минимум 16 байт для маленьких массивов мы получаем оверхэд по памяти сравнимый с объемом хранимых данных.

Потом создание объектов — это атоммарная операция, а создание и инциализация двух объектов уже нет. Стало быть менеджер памяти вынужден делать блокировки/интерлоки и вставлять write-барьеры на указатели. А ведь их можно бы и не быть.

А>Напиши обертку которая бы не делала копирование, в чем проблема то ? Виртуальные вызовы оверхед ощутимый не создают.

Проблема в том, что таких объектов довольно много. А по сути на них можно и не тратить ресурсы. Отсюда мы имеем приципиальное отставание перед такими низкоуровневыми языками как С/С++. Причем отставание это обусловлено не объективными причинами, а просто просчетами в дизайне системы.

А>Иначе quake3 и друиге игры не писались бы с подходом ООП.

К твоему сведению, все версии Quake-ов (по крайней мере до версии 3 включительно) писались на С. Кармак (лидер ID Software) как раз таки недолюбливает ООП. По крайней мере он раз плохо высказывался об DirectX.

А>А фича реквесты есть намного более важные, чем готовые обертки в 10 строк для ленивых.

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

Здравствуйте, VladD2, Вы писали:

VD>>>Только мне в дотнете не хватает неизменяемого массива?

Не хватает часто

Но всегда удавалось обойтись ReadOnlyCollection<>

QL>>Array.AsReadOnly();

QL>>?
VD>Массив — это монолитная структура данных. А AsReadOnly создает ReadOnlyCollection, что совершенно не нужный оверхэд, …

И всё-таки: где и как можно использовать "неизменяемый массив", что бы его нельзя было бы заменить ReadOnlyCollection? В голову только вариантность и приходит. Но это можно решить на уровне библиотеки.

А оверхед — ну разве что в названии типа, да он редко когда используется.

VD>…да и исходный массив он от изменения не защищает.

Ну так просто надо как можно скорее исходный "обернуть" и не будет этой проблемы. В крайнем случае ("как можно скорее не удаётся") скопировать (ничего тут не проиграем по сравнению со всеми другими реализациями)

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, gandjustas, Вы писали:

G>>Но ведь не в этом проблема, а в быстродействии.
VD>Проблема в том числе и в быстродействии. Но основная проблема в необходимости лишних абстракций.
То есть всетаки в быстродействии. Лишние абстракции никому не мешают если не дают оверхеда.

VD>Вот ты спрашивал "зачем?", но как тебе объяснить "зачем?", если ты мыслишь императивно.
Словами. Если ты не можешь объяснить что-то словами, то ты сам этого не понимаешь.

VD>На самом деле при некотором стиле программирования (назовем его условно околофункциональном) появляется туча массивов которые однажды будучи проинициализированными больше (до своей смерти) не изменяются. Это позволяет использовать обрабатывать их параллельно.

VD>В ФЯ где нет неизменяемых массивов используют связанные списки, так как они не изменяемые. Это довольно удобно (за тем исключением, что доступ по индексу требует O(n). Но это весьма затратно, так как на каждый элемент списка приходится создавать по отдельному объекту. Объект в дотнете — это минимум 12 байт оверхэда (в х64 бошльше). Конечно и так можно жить, но не ясно зачем платить больше?

G>>Фактически immutable массив эффективен только в случае доступа на чтение по случайному индексу.

VD>Фактически неизменяемые массивы всегда эффективнее чем изменяемые, если изменяемые массивы используются для хранения и не меняются.
Прям таки адмирал Ясен Х#й.

VD>Эффективнее неизменяемые массивы и тем, что не требуется оберток для их защиты, и тем что для их управления не нужен сложных GC с барьером записи, и тем что имеются железные гарантии отсутствия ошибок связанных с изменением.
тогда не пойму почему речь именно про массивы, а не про поддержку иммутабельности на уровне CLR?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, samius, Вы писали:

VD>>>>>Кроме того хотелось бы получить возможность размещать в хвосте объекта один массив однородных элементов. Тогда типы вроде строк не пришлось бы хардодить в рантайме.
VD>...
S>>А что подразумевается под "хардкодить в рантайме"?

VD>А ты погляди на конструкторы string-а через Рефлектор. Знаешь что в них интересного? То что их нет!
Все понятно. В дотнет рантайме...
Я понял фразу так будто кто-то хардкодит во времени выполнения программы

Здравствуйте, _FRED_, Вы писали:

_FR>Это всё очень интересно. Но должна быть, как мне кажется, стратегия принятия решений несколько иная (тем более есть уже устоявшаяся практика использования обычных массивов) — интересно вначале посмотреть на сценарии использования "неизменяемых массивов": всевозможные сценарии.

Да на что смотреть то? Не уж то ООП совсем в мозг внедрился?

Сценарий примитивнейший. Перестаем заниматься херней и в публичном интерфейсе тупо выставляем неизменяемые массивы, которые хранятся как неизменяемые поля объектов. Получаем потокобезопасное, эффективное решение простое в реализации как три копейки.

В Nemerle с его get-свойствами, макрами Record и Accessor — это вообще будет красотища. Объект содержащие только лишь информацию будут до нельзя краткими.

_FR>Чем они предподчтительнее других, имеющихся, структур данных (и не абстрактную воду "ФП и этим всё сказано" тут нужно показать, а конкретные примеры кода. Не все возможные

Различные).

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

_FR>Потом продемонстрировать: что вот де на, можно эмулировать через то, что есть, но при этом будут такие и такие огрехи, неприятности, которые могут оказаться значимыми тогда-то и тогда-то.

А что не ясно? АТД могут эмулировать много чего. Только вот это лишнее звено. Абстракция которой не требуется при правильном проектировании. А устранение лишних абстракций (без потери выразительности и надежности) — это выгода во всех отношениях.

_FR>Потом рассказать об оптимизациях, которые можно будет делать с такой структурой (но это кажется немного сказано, но всё ли?).

Кому? Тем кто не понимает чем отличается один объект от двух плюс лишняя ссылка?

_FR>Но самое интересное — примеры. Возмём существующую BCL. Где от неизменяемых массивов был бы толк?

В AddRange() IEnumerable<object>, ИМХО, лучше вписывается (потому что, что бы создать из изменяемого набора, например IEnumerable<object>, неизменяемый список и передать в метод, нужно сделать копирование. Затем, что бы неизменяемый список куда-то вставить, нужно сделать ещё одно копирование).

Если бы в дотнете были бы неизменяемые массивы, то многое могло бы выглядеть по другому. И при этом абстракции могли бы стать дешевле. Все же есть огромная разница в передаче ссылки на массив и создании итератора. Да, где-то важнее абстракция. Но где-то эффективность.

Чтобы понять бенефиты от неизменяемых структур данных нужно начать изучат этот вопрос. Про это не одна статья и книга написана. Там много бенефитов. Это и версиооннсоть, и отсутствие в необходимости блокировок и возможность безопасно разделять данные (и возвращать ссылки на них во вне).

Здравствуйте, gandjustas, Вы писали:

G>Прям таки адмирал Ясен Х#й.

Учти, что в следующий раз за мат пойдешь в баню. (Ничего личного)

VD>>Эффективнее неизменяемые массивы и тем, что не требуется оберток для их защиты, и тем что для их управления не нужен сложных GC с барьером записи, и тем что имеются железные гарантии отсутствия ошибок связанных с изменением.
G>тогда не пойму почему речь именно про массивы, а не про поддержку иммутабельности на уровне CLR?

Потому-что поля доступные для чтения уже есть, а больше особо ничего и не нужно. Массивы — это единственная дыра в дизайне в этом смысле.

Здравствуйте, VladD2, Вы писали:

_FR>>Не хватает часто

Но всегда удавалось обойтись ReadOnlyCollection<>
VD>Понятно, что обойтись можно. Непонятно, зачем? Зачем терять память и такты понапрасну?
_FR>>И всё-таки: где и как можно использовать "неизменяемый массив", что бы его нельзя было бы заменить ReadOnlyCollection? В голову только вариантность и приходит. Но это можно решить на уровне библиотеки.
VD>Как минимум так где эффективность кода и объем потребляемой памяти важны.
_FR>>А оверхед — ну разве что в названии типа, да он редко когда используется.
VD>Оверхэд в создании двух объектов вместо одного и в постоянном (и свершенно лишнем) доступе по ссылке.

OK, если основной (согласен, что совсем не единственный) профит — это [низкоуровневые] оптимизации, то с этим понятно. Тут, кажется, есть несколько сложностей. Во-первых, такой тип нужно спроектировать. Во-вторых, нужно сделать для него опитимизации. sealed вот с самого начала есть, но оптимизаций под него я не знаю

Отсюда и малый интерес к теме — как-то не верится, что это будет сделано Майкрософтом.

VD>>>…да и исходный массив он от изменения не защищает.
_FR>>Ну так просто надо как можно скорее исходный "обернуть" и не будет этой проблемы.
VD>Это ты расскажи тем кто ошибки делает (а кто их не делает?). Лично моя практика четко показывает, что при использовании неизменяемых структур надежность кода существенно увеличивается (при его упрощении).

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

Хотя было бы здорово конешно

Здравствуйте, VladD2, Вы писали:

_FR>>Это всё очень интересно. Но должна быть, как мне кажется, стратегия принятия решений несколько иная (тем более есть уже устоявшаяся практика использования обычных массивов) — интересно вначале посмотреть на сценарии использования "неизменяемых массивов": всевозможные сценарии.
VD>Да на что смотреть то? Не уж то ООП совсем в мозг внедрился?

Пока больше похоже на то, что это заноза внедрилась куда-то пониже ООП у среднестатистического разработчика

В общем, давайте конструктивнее, интересно же.

VD>Сценарий примитивнейший. Перестаем заниматься херней и в публичном интерфейсе тупо выставляем неизменяемые массивы, которые хранятся как неизменяемые поля объектов. Получаем потокобезопасное, эффективное решение простое в реализации как три копейки.

Нет уж. Данный этап предполагает, в том числе, рассмотрение возможного синтаксиса. Как будет выглядеть объявление? инициализация? Как имеющееся АПИ будет "сопрягаться" с новым фундаментальным типом. Например: возможно ли будет хранить в таких массивах произвольные (в том числе и изменяемые, ибо пока нет в дотнете признака неизменяемости) структуры? Так что конкретика очень важна, и без неё просто неинтересно и нечего обсуждать.

VD>В Nemerle с его get-свойствами, макрами Record и Accessor — это вообще будет красотища. Объект содержащие только лишь информацию будут до нельзя краткими.

Если постараться не обращать внимание на преимущества в оптимизациях (с этим не поспоришь), а поговорить только об удобстве проектирования, я правильно понимаю, что разница между неизменяемым массивом и ReadOnlyCollection<> только в ковариантности первых? Или что-то ещё есть, чего насквозь императивным

сознанием не понять?

_FR>>Чем они предподчтительнее других, имеющихся, структур данных (и не абстрактную воду "ФП и этим всё сказано" тут нужно показать, а конкретные примеры кода. Не все возможные

Различные).
VD>Простой использования, эффективностью, меньшим потреблением памяти. Разве это не очевидно? Но, конечно же, все это доступно в функциональном коде не меняющем данные, а трансформирующем их.

ОК. Следующий важный этап — это оценить стоимость реализации и прибыль от использования. Сделайте в Немерле такой "софтовый" вариант: придумайте синтаксис, начните использовать. И скажите — действительно ли будет так же удобно, как кажется и сейчас? Уверяю, что большинству заинтересованных лиц гораздо интереснее было бы ознакомиться с опытом использования, нежели с тем, как это можно было бы сделать

_FR>>Потом продемонстрировать: что вот де на, можно эмулировать через то, что есть, но при этом будут такие и такие огрехи, неприятности, которые могут оказаться значимыми тогда-то и тогда-то.
VD>А что не ясно? АТД могут эмулировать много чего. Только вот это лишнее звено. Абстракция которой не требуется при правильном проектировании. А устранение лишних абстракций (без потери выразительности и надежности) — это выгода во всех отношениях.

В общих терминах я это тоже всё прекрасно понимаю

Но интерес представляют именно детали.

_FR>>Потом рассказать об оптимизациях, которые можно будет делать с такой структурой (но это кажется немного сказано, но всё ли?).
VD>Кому? Тем кто не понимает чем отличается один объект от двух плюс лишняя ссылка?

Если это единственная оптимизация — то ради неё изменять фреймворк уж точно не стоит

_FR>>Но самое интересное — примеры. Возмём существующую BCL. Где от неизменяемых массивов был бы толк?

В AddRange() IEnumerable<object>, ИМХО, лучше вписывается (потому что, что бы создать из изменяемого набора, например IEnumerable<object>, неизменяемый список и передать в метод, нужно сделать копирование. Затем, что бы неизменяемый список куда-то вставить, нужно сделать ещё одно копирование).

VD>Если бы в дотнете были бы неизменяемые массивы, то многое могло бы выглядеть по другому. И при этом абстракции могли бы стать дешевле. Все же есть огромная разница в передаче ссылки на массив и создании итератора. Да, где-то важнее абстракция. Но где-то эффективность.

Если бы дженерики изначально сделали, тоже было бы очень хорошо :о)) Но это не конструктивный разговор. Топик ведь не о том, как было бы здорово, если это было бы в самом начале? Вроде как о том, стоит ли это делать сейчас? ИМХО, пока не видно, что стоит.

VD>Чтобы понять бенефиты от неизменяемых структур данных нужно начать изучат этот вопрос. Про это не одна статья и книга написана. Там много бенефитов. Это и версиооннсоть, и отсутствие в необходимости блокировок и возможность безопасно разделять данные (и возвращать ссылки на них во вне).

ReadOnlyCollection<> мне кажется неизменяемой структурой данных.

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, samius, Вы писали:

_FR>>>А почему ReradOnlyCollection<> изменяемая?

S>>Потому что ее содержимое может измениться любым кто владеет переданной на конструктор коллекций втайне от тех кто владеет оберткой.

_FR>Ой ли? Или мы владеем тем, что передаём туда, или копируем. Поэтому не "может", а "можно сделать", если делать абы как

Так что всё зависит только от того, что "заворачивает".
Что говорит о том что однозначного ответа на вопрос изменяемости данных ReadOnlyCollection нет, в сравнении со списками F#-а, или Nemerle. Все зависит от абы как, от того что и кто, и что случится когда.

Здравствуйте, VladD2, Вы писали:
VD>Массив — это монолитная структура данных. А AsReadOnly создает ReadOnlyCollection, что совершенно не нужный оверхэд, да и исходный массив он от изменения не защищает.

А в каких языках есть пример того, что вам нужно?

Здравствуйте, VladD2, Вы писали:

VD>Только мне в дотнете не хватает неизменяемого массива?

А это вообще где-то есть?

Здравствуйте, k.o., Вы писали:

QL>>А в каких языках есть пример того, что вам нужно?
KO>Наверно, C++: const T [], const T *, const std::vector, const my_cool_array, etc.

Это константность вообще, а не только массива.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, k.o., Вы писали:

QL>>>А в каких языках есть пример того, что вам нужно?
KO>>Наверно, C++: const T [], const T *, const std::vector, const my_cool_array, etc.

A>Это константность вообще, а не только массива.

А в чём разница?

Здравствуйте, k.o., Вы писали:

A>>Это константность вообще, а не только массива.
KO>А в чём разница?

Спрашивали про массив

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, k.o., Вы писали:

A>>>Это константность вообще, а не только массива.
KO>>А в чём разница?

A>Спрашивали про массив

Ну так мы и получаем неизменяемый массив, разве нет?

Здравствуйте, samius, Вы писали:

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

А ничего что банальная строка (System.String) в дотнете по сути является таким массивом?

Твои рассуждения в корне ошибочны. unsafe есть unsafe. От него не защитишься. А передача по ссылке (то что ты назвал ref) просто не должна допускаться для данных доступных только для чтения.

S>Только оверхед вроде ReadOnlyCollection может гарантировать неизменность. А что бы гарантировать неизменность и с ним, нужно AsReadOnly вызывать у клона исходного массива.

Если бы это было так, то строки тоже создавали бы оверхэд, но это не так.

S>Я так понимаю, исходный вопрос риторический? В таком ракурсе — да, мне тоже не хватает встроенного неизменяемого массива. Ну т.е. было бы круто если бы он был. Но никакой надежды что он будет на уровне дотнета — нет. А вот языки в свою очередь могли бы обеспечивать что-то вроде const ref-а хотя бы на уровне компиляции. И я не понимаю, почему const ref-а нет до сих пор

.

Вопрос совершенно практический. Если бы я нашел поддержку, то можно было бы сделать запрос на фичу в следующую версию дотнета.

ЗЫ

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

Здравствуйте, adontz, Вы писали:

QL>>>А в каких языках есть пример того, что вам нужно?
KO>>Наверно, C++: const T [], const T *, const std::vector, const my_cool_array, etc.

A>Это константность вообще, а не только массива.

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

Здравствуйте, adontz, Вы писали:

A>Спрашивали про массив

Дык для полей есть readonly (в терминалогии шарпа). Почему бы не сделать решение полноценным и не позволить объявлять неизменяемые массивы?

Объект состоящий только из неизменяемых данных можно хранить в более эффективном GC. Ну, и гарантии намного выше когда рантайм обеспечивает свойства объекта, а не инкапсуляция. Про эффективность я молчу.

Здравствуйте, adontz, Вы писали:

A>А это вообще где-то есть?

Меня это не волнует. Думаю, что где-нить в ОКамле или Хаскеле должно быть. Плюс в С++ можно добиться похожего поведения (если закрыть глаза на возможность плевать на все и реинтерпретировать память).

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Пельмешко, Вы писали:

VD>>>Только мне в дотнете не хватает неизменяемого массива?

П>>Да.

VD>Вижу. И это печально. Дотнетчики не видят ничего дальше своего носа. МС сам воспитывает такой менталитет.

еще раз, у кого такое есть?
если так уж надо — можно использовать строку

Здравствуйте, Пельмешко, Вы писали:

П>Думаю дело лишь в том, что концепция константности из C++ несколько чужеродна для других .NET-языкам.

Дума, что ты плохо подумал

.

П>Вводить const в VB.NET и все остальные .NET-языки?

П>Игнорировать в других языках, оставив фичу лишь для C# и C++/CLI? Какой с этого толк?

Меня не очень интересуют языки. Меня интересует фича в рантайме. "const" мне тоже не нужен. Мне нужны неизменяемые массивы. При их наличии поддержка в языках была бы уже вопросом дизайна языка и выбора синтаксиса.

Здравствуйте, VladD2, Вы писали:

VD>Только мне в дотнете не хватает неизменяемого массива?

А почему только массива?

Мне вот очень не хватает (в порядке важности)
1)Immutable List
2)Immutable Map
3)Immutable Set
4)Immutable Queue
5)И только тут Immutable Array

Хотя с Immutable Array непонятно. С одной стороны хочется чтоб он был совместим с Array, ибо на него очень много API, но как при этом обеспечить иммутабельность и скорость работы (ибо копирование всего массива не улыбвается).

Проблема в том что обычный массив — почти самая эффективная структура для однопоточного случая, но с другой стороны массив является слишком низкоуровневой конструкцией.

В принципе на роль "immutable array" подошли бы ropes и\или VList.

Здравствуйте, Пельмешко, Вы писали:

П>Печально, действительно не видят дальше своего носа.

Ага. Очень.

П>В OCaml с давних пор массивы мутабельны, неизменяемые в Haskell.

Ну, вот видишь в самом функциональном из функциональных языков таки есть.

П>Вот пишут люди на окамлах промышленную фигню десятки лет и не понимают, что же им в функциональном языке не хватает... ах да, неизменяемых массивов!

Ага. Применяют списки там где нужно и не нужно, насрав на производительность и/или надежность. То что тебя это радует говорит исключительно о том что ты тоже дальше своего носа смотреть не привык.

П>Лично мне гораздо унылее от того, что в дотнетах из коробки нету какой-нибудь структуры данных типа VList, чтобы и внешне иммутабельно, и доступ по индексу/вычисление длинны быстрее чем O(n), и оверхеда по памяти и нагрузки на GC поменьше, чем у linked list.

Меня всегда радовали чаяния теоретиков.

Здравствуйте, blackhearted, Вы писали:

B>еще раз, у кого такое есть?

Меня это не волнует. Хотя есть в С++, и Хаскеле вроде есть.

B>если так уж надо — можно использовать строку

Расскажи как мне использовать строку для хранения массива int-ов. С удовольствием послушаю эту занимательную историю.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, blackhearted, Вы писали:

B>>еще раз, у кого такое есть?

VD>Меня это не волнует. Хотя есть в С++, и Хаскеле вроде есть.

А зачем тебе нужен неизменяемый массив? (вариант "патамушта" не катит)

Здравствуйте, VladD2, Вы писали:

VD>Ага. Применяют списки там где нужно и не нужно, насрав на производительность и/или надежность.

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

Здравствуйте, adontz, Вы писали:

A>System.String не фундаментальный тип. Это обычный класс у которого свойство this[int] без сетера.

Разочарую тебя. System.String это захардкоженый в ранйтайм тип данных, а не обычный класс.
В прочем, для рантайма и он является изменяемым.

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

A>А другим языкам что делать?

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

Ну, а языкам поддерживающим ФП это вообще сам мог велел поддерживать.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, samius, Вы писали:

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

VD>А ничего что банальная строка (System.String) в дотнете по сути является таким массивом?
Действительно так

VD>Твои рассуждения в корне ошибочны. unsafe есть unsafe. От него не защитишься. А передача по ссылке (то что ты назвал ref) просто не должна допускаться для данных доступных только для чтения.
Да, для строки именно так и происходит.

S>>Только оверхед вроде ReadOnlyCollection может гарантировать неизменность. А что бы гарантировать неизменность и с ним, нужно AsReadOnly вызывать у клона исходного массива.

VD>Если бы это было так, то строки тоже создавали бы оверхэд, но это не так.
Да, погонял. строка с char[] работают нос в нос.

VD>Вопрос совершенно практический. Если бы я нашел поддержку, то можно было бы сделать запрос на фичу в следующую версию дотнета.
Я за, если это что-то значит. Неизменяемый массив серьезно облегчит создания публичных API. Даже чихать на расходы по преобразовыванию его в изменяемые и обратно. Вопрос лишь в том, насколько такая фича нужна.

VD>ЗЫ

VD>Кроме того хотелось бы получить возможность размещать в хвосте объекта один массив однородных элементов. Тогда типы вроде строк не пришлось бы хардодить в рантайме.
Не понял, о чем речь

Здравствуйте, VladD2, Вы писали:

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

Это вполне себе и сейчас возможно, если через modopt помечать параметры и возвращаемые значения. Собственно, C++/CLI так и поступает.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Пельмешко, Вы писали:

П>>В OCaml с давних пор массивы мутабельны, неизменяемые в Haskell.

VD>Ну, вот видишь в самом функциональном из функциональных языков таки есть.

На то он и чистый блин.
В OCaml изменяемые массивы введены чисто для императивной стороны языка, фактически чтобы писать на нём числодробилки адекватной производительности.

П>>Вот пишут люди на окамлах промышленную фигню десятки лет и не понимают, что же им в функциональном языке не хватает... ах да, неизменяемых массивов!

VD>Ага. Применяют списки там где нужно и не нужно, насрав на производительность и/или надежность. То что тебя это радует говорит исключительно о том что ты тоже дальше своего носа смотреть не привык.

Эмм, а как применение linked lists влияет на надёжность?
Это как раз неизменяемые массивы — урон по производительности

Вот человек Вы очень умный, Влад, а спорить с Вами мне почему-то очень уныло

Здравствуйте, Пельмешко, Вы писали:

П>Это вполне себе и сейчас возможно, если через modopt помечать параметры и возвращаемые значения. Собственно, C++/CLI так и поступает.

Это совершенно бессмысленное решение. Тут весь смысл в том, чтобы рантайм и все языки знали о том, что значение не изменяемое. Без этого будет именно то что есть в С++ — т.е. практически ничего.

Здравствуйте, samius, Вы писали:

S>Я за, если это что-то значит. Неизменяемый массив серьезно облегчит создания публичных API.

Ага. И не только. Это и для рантайма было бы не хилым облегчением. Для данных доступных только на чтение не нужен write-барьер.

S>Даже чихать на расходы по преобразовыванию его в изменяемые и обратно. Вопрос лишь в том, насколько такая фича нужна.

Ну, тут как всегда. Для тех кто думает только шаблонами ООП — это бесполезная вещь.

VD>>Кроме того хотелось бы получить возможность размещать в хвосте объекта один массив однородных элементов. Тогда типы вроде строк не пришлось бы хардодить в рантайме.
S>Не понял, о чем речь

Представляешь как устроен List<T>? Это два объекта List<T> и массив содержащий сам список. А можно было бы оформить такие типы как единый объект хранящий и массив и доп. данные. На С это стандартная практика, так как используется реинтерпретация памяти. В управляемых средах это не так. Хотя на самом деле ограничение чисто реализационное.

Здравствуйте, Пельмешко, Вы писали:

П>Эмм, а как применение linked lists влияет на надёжность?

На надежность влияют изменяемые массивы. А списки всего лишь создают оверхэд.

П>Это как раз неизменяемые массивы — урон по производительности

О, да, Кэп!

П>Вот человек Вы очень умный, Влад, а спорить с Вами мне почему-то очень уныло

Так не спорь.

Здравствуйте, gandjustas, Вы писали:

G>А почему только массива?

Потому что это базовый, почти примитивный, тип данных из которых можно делать те самые List, Map и т.п.

G>Мне вот очень не хватает (в порядке важности)
G>1)Immutable List
G>2)Immutable Map
G>3)Immutable Set
G>4)Immutable Queue

Ну, дык у меня они есть (например, Set, Map или list) или я могу их сделать сам.

G>5)И только тут Immutable Array

Дык его нельзя создать средствами высокоуровневых языков (без оверхэда).

G>Хотя с Immutable Array непонятно. С одной стороны хочется чтоб он был совместим с Array, ибо на него очень много API, но как при этом обеспечить иммутабельность и скорость работы (ибо копирование всего массива не улыбвается).

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

G>Проблема в том что обычный массив — почти самая эффективная структура для однопоточного случая, но с другой стороны массив является слишком низкоуровневой конструкцией.

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

G>В принципе на роль "immutable array" подошли бы ropes и\или VList.

Не подошли. Вот для реализации того же VList очень пригодились бы неизменяемые массивы, а сам VList — это высокоуровневая абстркция которую как раз самое оно оформить в виде абстрактного типа данных.

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

Здравствуйте, Flem1234, Вы писали:

F>Ради бога, объясни, зачем именно неизменяемый массив. У него же главная фишка — доступ по индексу, который чаще всего используется в императивном стиле. А неизменяемость из мира фп.

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

Проблема только в том, что при применении функционального подхода возникает оверхэд. Многие считают его неизбежным, но на самом деле во многом он определяется реализацией. Скажем описываю я некую иерархию неизменяемых объектов. Если я не имею неизменяемых массивов, то у меня есть только два выхода:
1. Использовать абстрактные типы данных для инкапсуляции изменяемых структур данных (по большей части массивов).
2. Использование разных неизменяемых типов вроде связанных списков.

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

F>Ну да, было бы здорово, чтобы рантайм нета так же хорошо поддерживал ФП как и какой-нибудь хаскель,

Ага. Очень здорово! Только жаль, что мало кто это понимает. Хотя в МС уже есть люди которым это очевидно (Меер, Дон Саймон и т.п.).

F>но боюсь этого не будет

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

Здравствуйте, VladD2, Вы писали:

VD>Только мне в дотнете не хватает неизменяемого массива?

А в немерле есть? Хотя бы на уровне языка?

Здравствуйте, Lloyd, Вы писали:

L>А в немерле есть? Хотя бы на уровне языка?

Нет. Но хотелось бы. А без поддержки в рантайме хорошего, надежного решения сделать не выйдет (к сожалению).

Думаю, что в Н2 мы что-то попытаемся сэмулировать, но решение (к сожалению) не будет совместимо с остальными языками.

Так до сих пор и не придумал ему применение

Здравствуйте, VladD2, Вы писали:

Да, и еще:
Сейчас все массивы являются реализацие класса System.Array.
Какой базовый класс предлагаешь ты для иммутабельных массивов, и как он будет соотноситься с классом System.Array в терминах ООП?

Здравствуйте, xvost, Вы писали:

X>Здравствуйте, VladD2, Вы писали:

VD>>Только мне в дотнете не хватает неизменяемого массива?

X>А как ты его создавать и инициализировать собираешься? Через "ImmutableArrayBuilder" какой-нибудь???

Т.к. предполагается что это тип из коробки, то и создавать его надо уметь явно

int[||] array = new int[||](source); // where source : IEnumerable<int>

Но и что-то такое тоже желательно.

T[||] Enumerable.ToImmutableArray<T>(this IEnumerable<T>);

А ImmutableArrayBuilder — это нечто лишнее.

Здравствуйте, xvost, Вы писали:

X>Здравствуйте, VladD2, Вы писали:

X>Да, и еще:
X>Сейчас все массивы являются реализацие класса System.Array.
X>Какой базовый класс предлагаешь ты для иммутабельных массивов, и как он будет соотноситься с классом System.Array в терминах ООП?

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

Здравствуйте, samius, Вы писали:

S>

S>int[||] array = new int[||](source); // where source : IEnumerable<int>
S>

И имеем в чистом виде копирование данных.

Здравствуйте, gandjustas, Вы писали:

G>ИМХО основная причина отсутствия immutable array как обычно:

G>

G>because no one ever designed, specified, implemented, tested, documented and shipped that feature.

G>(с) Угадай кто
Это все понятно, но прежде всего такая фича не востребована массами. Если бы она действительна была нужна массам но ее бы не было, то тогда можно было бы ссылаться и на эти причины.

G>ЗЫ. А кто мешает в качестве низкоуровневневых строительных блоков применять обычные массивы? Главное не отдавать их наружу.
То их и мешает использовать, что их надо тщательно прятать.

Здравствуйте, xvost, Вы писали:

X>Здравствуйте, samius, Вы писали:

S>>

S>>int[||] array = new int[||](source); // where source : IEnumerable<int>
S>>

X>И имеем в чистом виде копирование данных.

А разве ImmutableArrayBuilder их бы не копировал? Что там за магия?
Или подразумевается построение обертки над стандартным массивом что бы с одной стороны его можно было менять, а с другой — нет? Лично мне это кажется не интерессным.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, samius, Вы писали:

S>>Я за, если это что-то значит. Неизменяемый массив серьезно облегчит создания публичных API.

VD>Ага. И не только. Это и для рантайма было бы не хилым облегчением. Для данных доступных только на чтение не нужен write-барьер.

S>>Даже чихать на расходы по преобразовыванию его в изменяемые и обратно. Вопрос лишь в том, насколько такая фича нужна.

VD>Ну, тут как всегда. Для тех кто думает только шаблонами ООП — это бесполезная вещь.
Я думаю что такую фичу оценили бы все, если бы она появилась с грамотной вариантностью к родным массивам. Проблема только с первой реакцией на такую фичу. Потому толкать её надо не только через коннект.

VD>>>Кроме того хотелось бы получить возможность размещать в хвосте объекта один массив однородных элементов. Тогда типы вроде строк не пришлось бы хардодить в рантайме.
S>>Не понял, о чем речь

VD>Представляешь как устроен List<T>? Это два объекта List<T> и массив содержащий сам список. А можно было бы оформить такие типы как единый объект хранящий и массив и доп. данные. На С это стандартная практика, так как используется реинтерпретация памяти. В управляемых средах это не так. Хотя на самом деле ограничение чисто реализационное.
Да, понял. Знаком с такой штукой.
А что подразумевается под "хардкодить в рантайме"?

Здравствуйте, samius, Вы писали:

G>>ЗЫ. А кто мешает в качестве низкоуровневневых строительных блоков применять обычные массивы? Главное не отдавать их наружу.
S>То их и мешает использовать, что их надо тщательно прятать.

Но ведь не в этом проблема, а в быстродействии.

Для immutable массивов будут следующие операции и их асимптотика
1)Изменение элемента: O(n)
2)Взятие подмасиива: O(n)
3)Добавление\удаление элемента: O(n)
4)и только взятие элемента по индексу: O(1)

Фактически immutable массив эффективен только в случае доступа на чтение по случайному индексу.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>Гораздо интереснее как он будет соотноситься с классом System.Array в терминах ковариантности. Точнее это не сильно интересно, а должно иметь место. Т.е. нужно что бы изменяемый массив можно было подавать в качестве неизменяемого.
S>Не уверен в выделенном. Тогда нельзя будет написать код, полагающийся на иммутабельность переданного ему аргумента.
S>Простейший пример: класс Url может проверять права доступа к переданному адресу в конструкторе, и полагаться на то, что никто его не подменит, благодаря иммутабельности строк. Иначе атакующий сможет подменять адрес после проверки, но до обращения.

Я понял мысль. Но почему бы в таком случае проверяющему не выполнять проверку через GetType()? Хотя тип в рантайме тоже можно подменить unsafe-ом...
Да, надо подумать об этом.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, samius, Вы писали:

G>>>ЗЫ. А кто мешает в качестве низкоуровневневых строительных блоков применять обычные массивы? Главное не отдавать их наружу.
S>>То их и мешает использовать, что их надо тщательно прятать.

G>Но ведь не в этом проблема, а в быстродействии.
Проблема с быстродействием вытекает из неизменяемости, т.к. изменяемые массивы приходится оборачивать. Это конечно не влияет на алгоритмическую сложность (если не оборачиваем через array.Select(i => i)), но все-таки.

G>Для immutable массивов будут следующие операции и их асимптотика
G>1)Изменение элемента: O(n)
G>2)Взятие подмасиива: O(n)
G>3)Добавление\удаление элемента: O(n)
G>4)и только взятие элемента по индексу: O(1)
Точно так же как и в родном массиве (кроме возможности изменения элемента).
Да, но проблема не в этом, а в необходимости колдовать над каждым внутреннем массивом, что-бы ни дай бог кто-то не изменил его.

G>Фактически immutable массив эффективен только в случае доступа на чтение по случайному индексу.
Он был бы эффективен в плане удобства использования в контрактах при отсутсвии оверхедов оберток.

Здравствуйте, VladD2, Вы писали:

VD>Только мне в дотнете не хватает неизменяемого массива?
В джаве вон с 1999 по 2008 обсуждение шло — надо оно или нет.

Так и не решили...

Здравствуйте, bl-blx, Вы писали:

BB>Здравствуйте, VladD2, Вы писали:

VD>>Только мне в дотнете не хватает неизменяемого массива?
BB>В джаве вон с 1999 по 2008 обсуждение шло — надо оно или нет.

Так и не решили...
Там достаточно часто про неизменяемый массив упоминают.

Здравствуйте, VladD2, Вы писали:

VD>Меня не очень интересуют языки. Меня интересует фича в рантайме. "const" мне тоже не нужен.
А я бы от "const" не отказался бы

... << RSDN@Home 1.2.0 alpha 4 rev. 1478>>

Здравствуйте, xvost, Вы писали:

VD>>Только мне в дотнете не хватает неизменяемого массива?

X>А как ты его создавать и инициализировать собираешься? Через "ImmutableArrayBuilder" какой-нибудь???

Технически, т.п. на уровне рантайма с помощью функции конструктора. Скажем вводится некий атрибут которым можно пометить функцию возвращающую массив такого типа. Ну, а языках уже для этого можно свой синтаксис иметь. Скажем у немерла создание массивов выгядит так: array[1, 2, 3]. Некоторый набор таких предопределенных функций можно заложить в стандратную библиотеку. Например, можно создать функцию принимающую IEnumerable<T> и возвращающую неизменяемый массив.

Здравствуйте, Пельмешко, Вы писали:

VD>>Ну, вот видишь в самом функциональном из функциональных языков таки есть.

П>На то он и чистый блин.

Он ни фига не чистый, блин. Тебя обманули. Он ленивый, блин. Но на наличие императивных конструкций это влияет весьма опосредовано.

П>В OCaml изменяемые массивы введены чисто для императивной стороны языка, фактически чтобы писать на нём числодробилки адекватной производительности.

Я никогда не считал ОКамл образцом для подражания.

Здравствуйте, xvost, Вы писали:

X>И имеем в чистом виде копирование данных.

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

Строками ты ведь пользуешься? Не мешает, что они не изменяемые?

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

Здравствуйте, gandjustas, Вы писали:

G>1)Изменение элемента: O(n)
Да, но n у них достаточно маленький.

G>2)Взятие подмасиива: O(n)
Можно спроектировать и как О(1), этож иммутабельный массив.

G>3)Добавление\удаление элемента: O(n)
Как и в обычном массиве

Здравствуйте, samius, Вы писали:

G>>Фактически immutable массив эффективен только в случае доступа на чтение по случайному индексу.
S>Он был бы эффективен в плане удобства использования в контрактах при отсутсвии оверхедов оберток.

Блин, ребят, вы определитесь — вы или за чистоту идеи, или за эффективность? 7 страниц трёпа как в КСВ

Не, отдельным товарищам понятно зачем — пока не докажешь, что дотнет отстой, а все окружающие — идиоты, своё как-то не попиаришь. А вот если померить — окажется, что R/O обёртка добавляет к себе цену virtual call — как раз примерно 3x стоимости доступа по индексу. Увы, в реальном приложении экономия на спичках тут же сожрётся вызовами других методов.

Output:

-------
array:
  Elapsed:      00:00:00.8285260, MemDelta: 0,01MB
  Elapsed real: 00:00:00.8300474, GC count: 0
-------
R/O collection:
  Elapsed:      00:00:03.8450174, MemDelta: 0,01MB
  Elapsed real: 00:00:03.8452199, GC count: 0
-------
Linq sum:
  Elapsed:      00:00:03.7079820, MemDelta: 0,01MB
  Elapsed real: 00:00:03.7072120, GC count: 0
-------
R/O - linq sum:
  Elapsed:      00:00:03.6998820, MemDelta: 0,01MB
  Elapsed real: 00:00:03.7002116, GC count: 0
Done. Press any key to exit...

Код

using System;
using System.Collections.ObjectModel;
using System.Diagnostics;
using System.Linq;

namespace ConsoleApplication1
{
  internal class Program
  {
    static void Main(string[] args)
    {
      int count = 10 * 1000 * 1000;
      int repeatCount = 50;

      int[] data = new int[count];
      Random rnd = new Random(0);
      for (int i = 0; i < count; i++)
      {
        data[i] = rnd.Next(10);
      }

      ReadOnlyCollection<int> roData = Array.AsReadOnly(data);

      Measure("array", () =>
      {
        for (int j = 0; j < repeatCount; j++)
        {
          long sum = 0;
          for (int i = 0; i < data.Length; i++)
          {
            sum += data[i];
          }
        }
      });

      Measure("R/O collection", () =>
      {
        for (int j = 0; j < repeatCount; j++)
        {
          long sum = 0;
          for (int i = 0; i < roData.Count; i++)
          {
            sum += roData[i];
          }
        }
      });

      Measure("Linq sum", () =>
      {
        for (int j = 0; j < repeatCount; j++)
        {
          int sum = data.Sum();
        }
      });

      Measure("R/O - linq sum", () =>
      {
        for (int j = 0; j < repeatCount; j++)
        {
          int sum = roData.Sum();
        }
      });

      Console.Write("Done. Press any key to exit...");
      Console.ReadKey();
    }

    public static void Measure(string message, Action callback)
    {
      long mem = GC.GetTotalMemory(true);
      long gcCount = GC.CollectionCount(0);

      DateTime now = DateTime.Now;
      Stopwatch stopwatch = Stopwatch.StartNew();
      callback();
      TimeSpan elapsed = stopwatch.Elapsed;
      TimeSpan elapsedReal = DateTime.Now - now;

      // DONTTOUCH:
      //  It is intended to call GetTotalMemory with forceFullCollection: false
      //  _before_ GC.CollectionCount call.
      double memDelta = (GC.GetTotalMemory(false) - mem) / (1024 * 1024.0);
      long gcCountDelta = GC.CollectionCount(0) - gcCount;

      Console.WriteLine(
@"-------
{0}:
  Elapsed:      {1}, MemDelta: {2:#,0.00MB}
  Elapsed real: {3}, GC count: {4}",
        message, elapsed, memDelta, elapsedReal, gcCountDelta);
    }
  }
}

Нашли чем меряться...

Здравствуйте, xvost, Вы писали:

X>Да, и еще:
X>Сейчас все массивы являются реализацие класса System.Array.
X>Какой базовый класс предлагаешь ты для иммутабельных массивов, и как он будет соотноситься с классом System.Array в терминах ООП?

На самом деле текущая реализация массивов с их виртуальным наследованием от System.Array — это результат кривого дизайна и приспосабливания имеющихся до дженерик-эры сущностей.

Если бы была моя воля, то я бы вообще избавил бы от встроенных типов данных и эмуляции System.Array.

Я бы поступил следующим образом:
1. Ввел бы базовый тип System.Array[T].
2. Создал бы двух его наследников System.MutableArray[T] и System.ImmutableArray[T].
3. Ввел бы концепцию "хвостовых массивов". Концепция очень простая. Разрешаем объявлять в конце любого класса массив память под который выделяется в рамках области памяти отведенной под основной объект. При этом физически формат будет очень простой сначал должно идти 32-битное поле "длинна", а затем элементы массива.
4. Ввести в рантайм признак неизменяемости для хвостовых массивов (что-то типа readonly, но распространяемого на хвостовые массивы).
6. Реализовать System.MutableArray[T] и System.ImmutableArray[T] с использованием хвостовых массивов при этом пометив хвостовой массив в System.ImmutableArray[T] как неизменяемый.
7. Ввести некий атрибут позволяющий помеченному им методы-инициализаторы. В рамках таких методов будет доступна инициализация поэлементная System.ImmutableArray[T], но после выхода управления из таких методов массив уже больше не может подвергаться модификации.

Здравствуйте, samius, Вы писали:

S>Я понял мысль. Но почему бы в таком случае проверяющему не выполнять проверку через GetType()? Хотя тип в рантайме тоже можно подменить unsafe-ом...
S>Да, надо подумать об этом.

Просто не надо химичить. В подобных случаях проще скопировать массив. Это не так дорого как кажется.

Здравствуйте, gandjustas, Вы писали:

G>ЗЫ. А кто мешает в качестве низкоуровневневых строительных блоков применять обычные массивы?

А вот их изменяемость и мешает.

G>Главное не отдавать их наружу.

А вот будь не изменяемые массивы их можно было бы смело отдавать наружу без копирования.

Здравствуйте, samius, Вы писали:

S>Это все понятно, но прежде всего такая фича не востребована массами. Если бы она действительна была нужна массам но ее бы не было, то тогда можно было бы ссылаться и на эти причины.

Дык менталитет масс формируют как раз те кто делает фичи (точнее не делает). Так что невостребованность закономерна.
Когда начинаешь плотно программировать на гибридном языке, то понимаешь, что фича нужна. А до этого действительно необходимости не чувствуется. Голова же думает исключительно теми шаблонами которые в нее заложили.

G>>ЗЫ. А кто мешает в качестве низкоуровневневых строительных блоков применять обычные массивы? Главное не отдавать их наружу.
S>То их и мешает использовать, что их надо тщательно прятать.

+1

Здравствуйте, VladD2, Вы писали:

VD>Я бы поступил следующим образом:
VD>1. Ввел бы базовый тип System.Array[T].
Как быть с Legacy, работающим именно с Array? Как описывать многомерные массивы?

VD>2. Создал бы двух его наследников System.MutableArray[T] и System.ImmutableArray[T].
Каст от одного к другому — копированием? Тогда вызов метода, принимающего ImmutableArray будет неэффективным.

Обёрткой? Тогда — никаких гарантий, что многопоточный код не изменит значения в ячейках массива.
Наконец, что делать, если значения в массиве — mutable?

VD>3. Ввел бы концепцию "хвостовых массивов".
Что это даст и в каких сценариях будет полезно? В 99.(9)% доступ к массиву осуществляется не напрямую, так что выигрыш будет съеден стоимостью вызова ацессора.

VD>4. Ввести в рантайм признак неизменяемости для хвостовых массивов (что-то типа readonly, но распространяемого на хвостовые массивы).
VD>6. Реализовать System.MutableArray[T] и System.ImmutableArray[T] с использованием хвостовых массивов при этом пометив хвостовой массив в System.ImmutableArray[T] как неизменяемый.
Зачем? Практически везде внутренняя реализация массивов отдана на откуп рантайму. Добавим уровень абстракции — пожертвуем производительностью и огребём проблем с интеропом.

VD>7. Ввести некий атрибут позволяющий помеченному им методы-инициализаторы. В рамках таких методов будет доступна инициализация поэлементная System.ImmutableArray[T], но после выхода управления из таких методов массив уже больше не может подвергаться модификации.
И ещё добавить трассировку — чтобы метод не вызвали более одного раза. И кидать исключения при попытке обратиться к элементам до инициализации.

Не много ли костылей мы ввели ради абстрактной чистоты?
А сколько придётся вводить для многомерных массивов/массивов с ненулевой индексацией?

Здравствуйте, gandjustas, Вы писали:

G>Но ведь не в этом проблема, а в быстродействии.

Проблема в том числе и в быстродействии. Но основная проблема в необходимости лишних абстракций.

G>Для immutable массивов будут следующие операции и их асимптотика
G>1)Изменение элемента: O(n)
G>2)Взятие подмасиива: O(n)
G>3)Добавление\удаление элемента: O(n)
G>4)и только взятие элемента по индексу: O(1)

Вот ты спрашивал "зачем?", но как тебе объяснить "зачем?", если ты мыслишь императивно.

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

В ФЯ где нет неизменяемых массивов используют связанные списки, так как они не изменяемые. Это довольно удобно (за тем исключением, что доступ по индексу требует O(n). Но это весьма затратно, так как на каждый элемент списка приходится создавать по отдельному объекту. Объект в дотнете — это минимум 12 байт оверхэда (в х64 бошльше). Конечно и так можно жить, но не ясно зачем платить больше?

G>Фактически immutable массив эффективен только в случае доступа на чтение по случайному индексу.

Фактически неизменяемые массивы всегда эффективнее чем изменяемые, если изменяемые массивы используются для хранения и не меняются. Эффективнее неизменяемые массивы и тем, что не требуется оберток для их защиты, и тем что для их управления не нужен сложных GC с барьером записи, и тем что имеются железные гарантии отсутствия ошибок связанных с изменением.

Здравствуйте, Аноним, Вы писали:

А>Вот действительно, зачем пустословить и рассуждать про readonly массивы, приведи проблему практического значения с которой ты столкнулся где потребовался readonly массив на уровне frameworkа. Может она решается без readonly массивов другими ограничениями.

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

Неизменяемые массивы можно было бы спокойно выставлять в публичном интерфейсе, их можно было бы хранить эффективнее не создавая оберток (читай лишних объектов) и безопасно обрабатывать в разных потоках.о

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

Здравствуйте, gandjustas, Вы писали:

G>А зачем тебе нужен неизменяемый массив? (вариант "патамушта" не катит)

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

Здравствуйте, gandjustas, Вы писали:

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

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

Здравствуйте, samius, Вы писали:

VD>>>>Кроме того хотелось бы получить возможность размещать в хвосте объекта один массив однородных элементов. Тогда типы вроде строк не пришлось бы хардодить в рантайме.
...
S>А что подразумевается под "хардкодить в рантайме"?

А ты погляди на конструкторы string-а через Рефлектор. Знаешь что в них интересного? То что их нет! Они реализованы на С++ в недрах самого рантайма. Потом можешь поглядеть на реализацию System.Array и тоже обраружить, что ее тоже в сущности нет. Ради эффективности их захардкодили в рантайме на плюсах. Потому работа с ними в рантайме весьма эффективна. Нет оверхэда, так как нет дополнительных объектов.

Но все это было бы не нужно, если бы в дотнете поддерживались бы хвостовые массивы.

Здравствуйте, VladD2, Вы писали:

S>>Гораздо интереснее как он будет соотноситься с классом System.Array в терминах ковариантности. Точнее это не сильно интересно, а должно иметь место. Т.е. нужно что бы изменяемый массив можно было подавать в качестве неизменяемого.
VD>Я считаю, что ковариантность для изменяемых массивов — это грубейшая ошибка дизайна! А возможность подстановки (без копирования) изменяемых массивов на место не изменяемых еще большая ошибка!!!

Да, это есть. Но неужели на этой платформе есть у кого-то надежда, что это (подобные "грубейшие ошибки дизайна" — их ведь даже не раз-два обчёлся, а поболее) когда либо изменится?

VD>Поступить надо так. Ковариантность и контравариантность надо разрешить только для неизменяемых массивов. Для изменяемых ее надо запретить. Все равно ею мало кто пользуется. А если пользуется, то скорее всего не меняет содержимого. Например, методы вроде em.Windows.Forms.ListBox.Items.AddRange(object[] items) должны быть изменены на принимающие неизменяемые массивы.

А почему не IEnumerable<object>

Здравствуйте, VladD2, Вы писали:

VD>Если бы была моя воля, то я бы вообще избавил бы от встроенных типов данных и эмуляции System.Array.
VD>Я бы поступил следующим образом:
VD>1. Ввел бы базовый тип System.Array[T].
VD>2. Создал бы двух его наследников System.MutableArray[T] и System.ImmutableArray[T].
…

Это всё очень интересно. Но должна быть, как мне кажется, стратегия принятия решений несколько иная (тем более есть уже устоявшаяся практика использования обычных массивов) — интересно вначале посмотреть на сценарии использования "неизменяемых массивов": всевозможные сценарии.

Чем они предподчтительнее других, имеющихся, структур данных (и не абстрактную воду "ФП и этим всё сказано" тут нужно показать, а конкретные примеры кода. Не все возможные

Различные).
Потом продемонстрировать: что вот де на, можно эмулировать через то, что есть, но при этом будут такие и такие огрехи, неприятности, которые могут оказаться значимыми тогда-то и тогда-то.
Потом рассказать об оптимизациях, которые можно будет делать с такой структурой (но это кажется немного сказано, но всё ли?).

Но самое интересное — примеры. Возмём существующую BCL. Где от неизменяемых массивов был бы толк?

Здравствуйте, _FRED_, Вы писали:

_FR>А почему не IEnumerable<object>

Скорее почему не ICollection<object>

— для методов типа AddRange полезно знать количество добавляемых элементов.

Здравствуйте, TK, Вы писали:

_FR>>А почему не IEnumerable<object>

TK>Скорее почему не ICollection<object>

"не ICollection<object>" — во-первых, потому что не ковариантна

Во-вторых, всё равно: внутри я бы делал как-то так:

AddRange(IEnumerable<object> items) {
  var collection = items as ICollection<object> ?? items.ToList();

TK>…для методов типа AddRange полезно знать количество добавляемых элементов.

Или просто сразу ToList() — смотря что уже внутри метода делается и действительно ли нужно знать "количество добавляемых элементов".
Потому что всё равно или вызывающему или вызываемому придётся где-то обрывать IEnumerable<> но с интерфейсом, принимающим IEnumerable<object> вызовы писать удобнее.

То есть, те, у кого уже есть количество элементов (ICollection<>) ничего не теряют (ну не считаю времени выполнения оператора "as") а вот всем остальным вызывать будет удобнее.

Здравствуйте, Ziaw, Вы писали:

G>>2)Взятие подмасиива: O(n)
Z>Можно спроектировать и как О(1), этож иммутабельный массив.
Оо, таки да... Не подумал.

Здравствуйте, Kalina9001, Вы писали:

VD>>Меня не очень интересуют языки. Меня интересует фича в рантайме. "const" мне тоже не нужен.
K>А я бы от "const" не отказался бы

В С++ const — это не более пометка переменных которая помогает компилятору (и программисту) выявлять случаи нецелевого использования. Во-превых, const можно обойти несколькими способами. А во-вторых, он не защищает данных как таковых.

В дотнете же можно добиться константности на уровне типов. Причем с контролем со стороны джит-компилятора и верификатора. Это намного более серьезные гарантии и такой контроль нельзя будет обойти без использования небезопасного кода.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, samius, Вы писали:

S>>Гораздо интереснее как он будет соотноситься с классом System.Array в терминах ковариантности. Точнее это не сильно интересно, а должно иметь место. Т.е. нужно что бы изменяемый массив можно было подавать в качестве неизменяемого.

VD>Я считаю, что ковариантность для изменяемых массивов — это грубейшая ошибка дизайна! А возможность подстановки (без копирования) изменяемых массивов на место не изменяемых еще большая ошибка!!!
Да, все верно. Если можно будет подавать изменяемый массив в качестве неизменяемого, то гарантии того что массив неизменяем не будет.

VD>Поступить надо так. Ковариантность и контравариантность надо разрешить только для неизменяемых массивов. Для изменяемых ее надо запретить. Все равно ею мало кто пользуется. А если пользуется, то скорее всего не меняет содержимого. Например, методы вроде em.Windows.Forms.ListBox.Items.AddRange(object[] items) должны быть изменены на принимающие неизменяемые массивы.
Согласен, но боюсь что этого уже не случится.

Здравствуйте, VladD2, Вы писали:

VD>Поступить надо так. Ковариантность и контравариантность надо разрешить только для неизменяемых массивов. Для изменяемых ее надо запретить. Все равно ею мало кто пользуется. А если пользуется, то скорее всего не меняет содержимого. Например, методы вроде em.Windows.Forms.ListBox.Items.AddRange(object[] items) должны быть изменены на принимающие неизменяемые массивы.

Кстати, по уму [ко/кнтр]вариантность надо разрешить для любых неизменяемых структур классов (ссылочных типов), а не только интерфейсов (как сейчас). Это еще одно неприятное упущение в дотнете.

Здравствуйте, _FRED_, Вы писали:

_FR>Не хватает часто

Но всегда удавалось обойтись ReadOnlyCollection<>

Понятно, что обойтись можно. Непонятно, зачем? Зачем терять память и такты понапрасну?

_FR>И всё-таки: где и как можно использовать "неизменяемый массив", что бы его нельзя было бы заменить ReadOnlyCollection? В голову только вариантность и приходит. Но это можно решить на уровне библиотеки.

Как минимум так где эффективность кода и объем потребляемой памяти важны.

Потом оборачивание в ReadOnlyCollection тоже требует сил и времени. Зачем их тратить?

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

_FR>А оверхед — ну разве что в названии типа, да он редко когда используется.

Оверхэд в создании двух объектов вместо одного и в постоянном (и свершенно лишнем) доступе по ссылке.

VD>>…да и исходный массив он от изменения не защищает.

_FR>Ну так просто надо как можно скорее исходный "обернуть" и не будет этой проблемы.

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

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, samius, Вы писали:

G>>>Фактически immutable массив эффективен только в случае доступа на чтение по случайному индексу.
S>>Он был бы эффективен в плане удобства использования в контрактах при отсутсвии оверхедов оберток.

S>Блин, ребят, вы определитесь — вы или за чистоту идеи, или за эффективность? 7 страниц трёпа как в КСВ

И за чистоту тоже.

S>Не, отдельным товарищам понятно зачем — пока не докажешь, что дотнет отстой, а все окружающие — идиоты, своё как-то не попиаришь. А вот если померить — окажется, что R/O обёртка добавляет к себе цену virtual call — как раз примерно 3x стоимости доступа по индексу. Увы, в реальном приложении экономия на спичках тут же сожрётся вызовами других методов.

S>Output:
S>

S>R/O collection:
S>

Ну вот, R/O collection... А что эта коллекция говорит об изменяемости данных коллекции? К сожалению она говорит только о том, что изменить их со стороны нельзя. Но не факт что данные не изменятся тем кто эту коллекцию создал.
А значит, что будь такая коллекция в чьем-либо API, никакой уверенности о неизменности данных она не дает. А значит и использовать ее в целях демонстрации неизменяемости данных — сомнительный ход.

Допускаю что это была лишь демонстрация цены вызова virtual call и что предлагается написать свою ImmutableCollection<T>. Но я уже отвечал, что такая коллекция имеет тот недостаток, что она местячковая а не из коробки и не может использоваться в качестве стандартной в межбиблиотечных контрактах.

Здравствуйте, _FRED_, Вы писали:

_FR>Да, это есть. Но неужели на этой платформе есть у кого-то надежда, что это (подобные "грубейшие ошибки дизайна" — их ведь даже не раз-два обчёлся, а поболее) когда либо изменится?

Ну, надежда она баба такая — умирает последней

. Если бы я нашел поддержку, то можно было бы и в коннект обратиться и через инсайдеров на МС подавить. Глядишь что-то и получилось бы. Но при текущем положении дел — это бесполезно.

VD>>Поступить надо так. Ковариантность и контравариантность надо разрешить только для неизменяемых массивов. Для изменяемых ее надо запретить. Все равно ею мало кто пользуется. А если пользуется, то скорее всего не меняет содержимого. Например, методы вроде em.Windows.Forms.ListBox.Items.AddRange(object[] items) должны быть изменены на принимающие неизменяемые массивы.

_FR>А почему не IEnumerable<object>

Ну, потому что там сейчас object[]. Хотя — согласен. Наличие там IEnumerable<object> было бы более к месту.

Здравствуйте, samius, Вы писали:

S>Ну вот, R/O collection... А что эта коллекция говорит об изменяемости данных коллекции?
То же самое, что и гипотетический R/O-массив. Заполнять его копированием будет _очень_ дорого, особенно в сравнении с сэкономленными спичками. К тому же, если ваш код пытается изменять выданные наружу данные, иммутабельность массивов — меньая из ваших проблем

Если хочется warning-ов при компиляции — есть FxCop|CodeAnalysis, написать правило, проверяющее инстанциирование R/O коллекции неизменяемым впоследствии массивом не так уж и сложно.

Здравствуйте, VladD2, Вы писали:

Ок, принято

Ещё чуть помучаю вопросами, чтобы указать на узкие (с моей точки зрения) места.

S>>Как описывать многомерные массивы?

VD>Эх. Это, на мой взгляд еще одна ошибка дизайна дотнета. Не надо было делать многомерные массивы встроенными типами. Их надо было реализовать как классы.

А как? Генерить кучу классов аля Array2D, Array3D, ... Array18D ...? Кошмарно ведь выглядит.
*Если честно, мне многомерные массивы в продакшн-коде пока использовать не пришлось, поэтому спорить насчёт их сомнительной полезности как-то не с руки

Есть — и хорошо.

VD>Ну, да тут ничего не поделаешь уже. Но их поддержка не должна повлиять в данном случае. Размерность массива — это еще один атрибут массива. На его неизменяемость или типизацию не влияющий.
Увы, есть свойства — индексаторы. Для каждой размерности — свои.

S>>Каст от одного к другому — копированием? Тогда вызов метода, принимающего ImmutableArray будет неэффективным.
S>>Обёрткой?
VD>Почему? Нет, конечно. Базовый тип просто не должен содержать реализации.
Эмм, я неправильно сформулировал вопрос.

int[] data = { 1, 2, 3 };
ImmutableArray<int> roData = new ImmutableArray<int> (data); // Вот тут - произойдёт копирование, или нет?

S>>Наконец, что делать, если значения в массиве — mutable?
VD>Если же в массиве лежит ссылка на объект содержащий изменяемые поля, то их можно будет по прежнему изменять, так как это память уже не принадлежит массиву.
Именно. И какая польза от immutable-массивов, если в половине случаев эту самую иммутабельность не обеспечить? Они тут же превращаются из главной фичи в приятную побочную мелочь. А только ради приятной мелочёвки никто рантайм корёжить не будет.

VD>>>3. Ввел бы концепцию "хвостовых массивов".
S>>Что это даст и в каких сценариях будет полезно? В 99.(9)% доступ к массиву осуществляется не напрямую, так что выигрыш будет съеден стоимостью вызова ацессора.

VD>Выигрыш в том, что объект и массив размещаются в единой области памяти. Не нужно тратить 12 байт на второй объект, и не нужно делать ссылки на него. Массив просто находится по определенному смещению в теле объекта.
Ок, понятно. Только почему 12?

Во всех источниках — 8:
http://msdn.microsoft.com/en-us/magazine/cc163791.aspx#S7
http://stackoverflow.com/questions/3815227/understanding-clr-object-size-between-32-bit-vs-64-bit
http://netinverse.com/devblogs/debugging/advanced-net-debugging-clr-objects-internal-structure/626/

VD>Затем чтобы:
VD>1) небыло хардкода в рантайме;
VD>2) прикладные программисты могли бы создавать контейнерные типы не менее эффективне нежели те, что захаркодены в рантайме.

А смысл? Весь выигрыш — потеря 8 байт на контейнер. Харкод в рантайме будет в любом случае, иначе не будет дешёвой аллокации.

VD>То что сделано в донтете сегодня — это просто кривой хардкодинг двух типов в рантайме и наплевательское отношение к остальным типам.
Можно называть кривым и идиотским абсолютно всё, что выглядит непонятным. Вот так (и ниже по ветке) это выглядит со стороны. Поэтому я обычно предпочитаю разбираться в первопричинах.

VD>Почему System.Strung эффективнее чем List<T>?
Потому что string — встроенный тип и разработчики не поленились оптимизировать под него рантайм.
Чуть подробней — http://www.codeproject.com/KB/dotnet/strings.aspx

VD>Никакая трассировка не нужна, так как каждый вызов такого метода будет создавать новую копию массива. Генерировать исключения тоже не надо, так как корректность доступа можно проверить статически во время джит-компиляции или верификации.
Тогда вся дискуссия о "эффективности контейнеров" сразу теряет смысл — стоимость копирования убивает все нанооптимизации на корню

S>>А сколько придётся вводить для многомерных массивов/массивов с ненулевой индексацией?
VD>Массивов с индексом отличным от нуля в дотнете и так нет.

      Array data = Array.CreateInstance(typeof(int), new[] { 1 }, new[] { 2 }); // длина, нижняя граница.
      data.SetValue(123, 2);

      Console.WriteLine(data.GetValue(2));
      Console.WriteLine(data.Length);

VD>Для эмуляции можно использовать классы. С многомерными массивами никаких проблем не будет. Ты их опять же сам придумал. Вся разница многомерных массивов заключается только в наличии у них метаатрибута "размерность". В остальном это такой же непрерывный участок памяти.

Индексаторы

А также куча других оптимизаций.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>Ну вот, R/O collection... А что эта коллекция говорит об изменяемости данных коллекции?
S>То же самое, что и гипотетический R/O-массив.
Отнюдь не то же самое. В одном случае данные могут быть изменены, в другом — нет. С неизменяемыми массивами можно кэшировать результат обработки, с ReadOnlyCollection<T> — требуется пересчитывать.

S>Заполнять его копированием будет _очень_ дорого, особенно в сравнении с сэкономленными спичками.
Не сильно дороже чем заполнять копированием строки

S>К тому же, если ваш код пытается изменять выданные наружу данные, иммутабельность массивов — меньая из ваших проблем

Мой код (и не только) пытается следовать гайдлайнам и защищать внутренние данные от модификации извне. Проблема тут обратная. Если данные не выглядят защищенными, то почему бы не воспользоваться этим по месту и не изменить их при необходимости (Вы же не копируете каждый массив, созданный не вами?). Ой, изменили, а там где-то что-то сломалось...
Т.е. проблема не в том что кто-то пытается изменять данные, а в том что по данным (по типу) не видно, можно ли их изменять, изменятся ли они "сами" со временем, как в случае со строкой.

S>Если хочется warning-ов при компиляции — есть FxCop|CodeAnalysis, написать правило, проверяющее инстанциирование R/O коллекции неизменяемым впоследствии массивом не так уж и сложно.
Вообще не так уж и сложно обеспечить себя вполне MyИммутабельнымМассивом, MyWarning-ами, MyПравилами. Но речь идет о штуке из коробки, которая может быть использована всеми, а не только мной.

Здравствуйте, samius, Вы писали:

S>>Заполнять его копированием будет _очень_ дорого, особенно в сравнении с сэкономленными спичками.
S>Не сильно дороже чем заполнять копированием строки

Embedded-cтроки очень эффективно инициализируются, а напрямую ими манипулируют относительно редко. С массивами, напротив, большинство сценариев — на заполнение/изменение/передачу буфера. Например, поблочное копирование с одного потока в другой при вашем подходе не взлетит.

S>>К тому же, если ваш код пытается изменять выданные наружу данные, иммутабельность массивов — меньая из ваших проблем

S>Мой код (и не только) пытается следовать гайдлайнам и защищать внутренние данные от модификации извне.

immutable массив бесполезен без поддержки immutable-типов. Пока их нет, достаточно отдавать ReadOnlyCollection и копировать аргументы (там, где это важно).

S>Проблема тут обратная. Если данные не выглядят защищенными, то почему бы не воспользоваться этим по месту и не изменить их при необходимости (Вы же не копируете каждый массив, созданный не вами?). Ой, изменили, а там где-то что-то сломалось...
При известном усердии... ну, вы поняли.
Повторюсь, если в команде низкая культура кодирования — вас ничего не спасёт. При невозможности уследить за всеми — только бить по рукам FxCop-ом.

S>Т.е. проблема не в том что кто-то пытается изменять данные, а в том что по данным (по типу) не видно, можно ли их изменять, изменятся ли они "сами" со временем, как в случае со строкой.
3 простых правила:
— Все коллекции, переданные в метод, должны рассматриваться как RO, если иное не очевидно из названия параметров/метода.
— Все коллекции, сохраняемые как значение поля, должны копироваться (исключение — для классов-обёрток).
— Все коллекции, хранимые в поле и отдаваемые наружу, должны отдаваться либо в виде r/o-обёртки, либо копией. В последнем случае должен использоваться метод GetSmth().

Разумеется, есть исключения, но они достаточно редки.

S>Вообще не так уж и сложно обеспечить себя вполне MyИммутабельнымМассивом, MyWarning-ами, MyПравилами. Но речь идет о штуке из коробки, которая может быть использована всеми, а не только мной.

Повторюсь, проблему иммутабельных данных одними неизменяемыми массивами не решить. Поэтому, либо следим за стилем кодирования, либо смиряемся с бардаком.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>Не сильно дороже чем заполнять копированием строки

S>Embedded-cтроки очень эффективно инициализируются, а напрямую ими манипулируют относительно редко. С массивами, напротив, большинство сценариев — на заполнение/изменение/передачу буфера. Например, поблочное копирование с одного потока в другой при вашем подходе не взлетит.
А зачем использовать иммутабельные массивы для поблочного копирования?

S>>Мой код (и не только) пытается следовать гайдлайнам и защищать внутренние данные от модификации извне.

S>immutable массив бесполезен без поддержки immutable-типов. Пока их нет, достаточно отдавать ReadOnlyCollection и копировать аргументы (там, где это важно).
Не обязательно быть immutable что бы была польза от immutable массивов. Для всех Value-типов такая польза уже есть. Кроме того есть immutable из коробки — System.String. И еще куча иммутабл типов в коробках других языков (Nemerle, F#). Так что их есть достаточно что бы была польза от immutable массивов уже сейчас, не говоря о том, что некоторые создают преимущественно иммутабельные типы в своих проектах.

S>>Проблема тут обратная. Если данные не выглядят защищенными, то почему бы не воспользоваться этим по месту и не изменить их при необходимости (Вы же не копируете каждый массив, созданный не вами?). Ой, изменили, а там где-то что-то сломалось...
S>При известном усердии... ну, вы поняли.
S>Повторюсь, если в команде низкая культура кодирования — вас ничего не спасёт. При невозможности уследить за всеми — только бить по рукам FxCop-ом.
Странно, но иммутабельность стринга спасает как от попыток его модифицировать так и от попыток скоприровать его для защиты от модификации
S>

S>>Т.е. проблема не в том что кто-то пытается изменять данные, а в том что по данным (по типу) не видно, можно ли их изменять, изменятся ли они "сами" со временем, как в случае со строкой.
S>3 простых правила:
S>- Все коллекции, переданные в метод, должны рассматриваться как RO, если иное не очевидно из названия параметров/метода.
Я не против. Но рассматривание коллекции в качестве RO не гарантирует то что через милисекунду содержимое не изменится.
S>- Все коллекции, сохраняемые как значение поля, должны копироваться (исключение — для классов-обёрток).
О, копироваться. А переданный иммутабельный массив копировать не нужно. А почему исключение для оберток? Кто будет гарантировать что обернутая коллекция не изменится?
S>- Все коллекции, хранимые в поле и отдаваемые наружу, должны отдаваться либо в виде r/o-обёртки, либо копией. В последнем случае должен использоваться метод GetSmth().
RO обертка не гарантирует неизменности содержимого тому кто берет ее снаружи. А копия не может быть закэширована и должна отдаваться наружу каждый раз новая. Иммутабельный массив решил бы этот вопрос.

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

За стилем-то мы следим. И вот как раз изменяемый массив позволил бы следить за ним немного меньше.

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, VladD2, Вы писали:

VD>>Это ты расскажи тем кто ошибки делает (а кто их не делает?). Лично моя практика четко показывает, что при использовании неизменяемых структур надежность кода существенно увеличивается (при его упрощении).

_FR>Совершенно верно. Но, ИМХО, пропаганда использования имеющихся и рекомендации пл проектированию новых "правильных" типов была бы гораздо полезнее...

Пропаганда была бы полезнее если бы в рантайме и FCL были бы "правильные" коллекции. А так получается, что "правильный" тип создать не проблема, а складывание его в коллекцию приводит к получению неправильного типа. Смысл от использования правильных типов теряется.
_FR>, чем ругань кривого дизайна и проектирование того, чего с огромной долей вероятности скорее всего не будет

Хотя было бы здорово конешно

ругань — конечно плохо. Но тут частенько за ругань принимается критика и позиция несогласия с принятыми решениями.

Здравствуйте, samius, Вы писали:

VD>>>Это ты расскажи тем кто ошибки делает (а кто их не делает?). Лично моя практика четко показывает, что при использовании неизменяемых структур надежность кода существенно увеличивается (при его упрощении).
_FR>>Совершенно верно. Но, ИМХО, пропаганда использования имеющихся и рекомендации пл проектированию новых "правильных" типов была бы гораздо полезнее...
S>Пропаганда была бы полезнее если бы в рантайме и FCL были бы "правильные" коллекции. А так получается, что "правильный" тип создать не проблема, а складывание его в коллекцию приводит к получению неправильного типа. Смысл от использования правильных типов теряется.

Не понял, о каких типах и каких складываниях (и, =>, что неправильного) речь?

_FR>>, чем ругань кривого дизайна и проектирование того, чего с огромной долей вероятности скорее всего не будет

Хотя было бы здорово конешно

S>ругань — конечно плохо. Но тут частенько за ругань принимается критика и позиция несогласия с принятыми решениями.

Да нет, ругань — это "Не уж то ООП совсем в мозг внедрился?" и прочие уколы.

Здравствуйте, samius, Вы писали:

S>А зачем использовать иммутабельные массивы для поблочного копирования?
Как минимум один из методов должен только читать из блока. Что выберете:
— ввести ro-обёртку вокруг массива;
— копировать массив в ImmutableArray и передавать уже его;
— пожертвовать абстрактной красивостью и оставить как есть
?

На практике подобных задач — с множеством вспомогательных методов — выше крыши; сценариев, когда требуется совсем неизменяемая коллекция, настолько мало, что они с головой покрываются new ReadOnlyCollection<T>(source.ToArray());

S>Не обязательно быть immutable что бы была польза от immutable массивов. ... И еще куча иммутабл типов в коробках других языков (Nemerle, F#). Так что их есть достаточно что бы была польза от immutable массивов уже сейчас, не говоря о том, что некоторые создают преимущественно иммутабельные типы в своих проектах.

Я ещё раз повторю — без возможности явно объявить о иммутабельности типа (например, generic-ограничением), вы не можете полагаться на иммутабельность данных в целом. Следовательно, RO-коллекции превращаются из повсевместной фичи в приятный хелпер. В фреймворке уже есть готовый хелпер, и он поддерживает все сценарии — и с обёрткой, и с копированием. Смысла производить фундаментальные изменения в рантайме ради одной недофичи (и изменять ещё раз — при введении полноценной поддержки immutable) я не вижу.

S>RO обертка не гарантирует неизменности содержимого тому кто берет ее снаружи.
Зачастую и не должна. Как пример — Dictionary.Keys.

S> А копия не может быть закэширована и должна отдаваться наружу каждый раз новая.
Почему? Всё та же new ReadOnlyCollection<T>(source.ToArray()).

S>Я особо не рассчитываю на внедрение иммутабельного массива. Но считаю что если бы он был внедрен хотя бы с фреймворком 2.0, то это сильно бы изменило положение вещей на текущий момент.
Да не изменило бы оно нифига. Кому надо — давно добавили extension CopyToReadOnly и соответствующее правило в FxCop. Кому не надо — философствуют на 11й(?) странице. Я явно отношусь к последним

Приведите хоть одно место в фреймворке (кроме ляпа с Path.InvalidChars), где immutable-массивы явно исправят положение к лучшему.

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, samius, Вы писали:

VD>>>>Это ты расскажи тем кто ошибки делает (а кто их не делает?). Лично моя практика четко показывает, что при использовании неизменяемых структур надежность кода существенно увеличивается (при его упрощении).
_FR>>>Совершенно верно. Но, ИМХО, пропаганда использования имеющихся и рекомендации пл проектированию новых "правильных" типов была бы гораздо полезнее...
S>>Пропаганда была бы полезнее если бы в рантайме и FCL были бы "правильные" коллекции. А так получается, что "правильный" тип создать не проблема, а складывание его в коллекцию приводит к получению неправильного типа. Смысл от использования правильных типов теряется.

_FR>Не понял, о каких типах и каких складываниях (и, =>, что неправильного) речь?

Повыделял выше. Речь о неизменяемых структурах и о том что их пропаганда была бы эффективнее, будь в FW или в рантайме неизменяемые коллекции. А так — смысл использования неизменяемого объекта в изменяемой коллекции ровно такой же как и у использования изменяемого объекта в изменяемой коллекции.

Здравствуйте, samius, Вы писали:

S>Повыделял выше. Речь о неизменяемых структурах и о том что их пропаганда была бы эффективнее, будь в FW или в рантайме неизменяемые коллекции. А так — смысл использования неизменяемого объекта в изменяемой коллекции ровно такой же как и у использования изменяемого объекта в изменяемой коллекции.

А почему ReradOnlyCollection<> изменяемая?

А у меня есть ещё ReadOnlyCollection2 (которая от ICollection<>), а так же сеты и словари и мне хватает

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>А зачем использовать иммутабельные массивы для поблочного копирования?
S>Как минимум один из методов должен только читать из блока. Что выберете:
S>- ввести ro-обёртку вокруг массива;
S>- копировать массив в ImmutableArray и передавать уже его;
S>- пожертвовать абстрактной красивостью и оставить как есть
S>?
То есть речь о том, что если бы были такие массивы, то в методе записи в Stream должен был бы использвоаться иммутабельный массив, и тогда для блочного копирования пришлось бы задвинуть на реюз блоков?
Вообще говоря я не предлагал переписывать фреймворк, но если бы такое случилось, я бы предпочел что бы Stream.Write принимал бы иммутабельный буфер, либо перегруженный метод, принимающий иммутабельный буфер.

S>На практике подобных задач — с множеством вспомогательных методов — выше крыши; сценариев, когда требуется совсем неизменяемая коллекция, настолько мало, что они с головой покрываются new ReadOnlyCollection<T>(source.ToArray());
Как бы ROC<T> не была создана, сам вид ROC<T> не обеспечивает видимости гарантии неизменности данных извне. Т.е. для того что бы понять, будут меняться данные или нет в этом ROC<T>, мне нужно открыть рефлектор и убедиться что ROC<T> создан с копированием данных, а не как-то иначе.

S>Я ещё раз повторю — без возможности явно объявить о иммутабельности типа (например, generic-ограничением), вы не можете полагаться на иммутабельность данных в целом. Следовательно, RO-коллекции превращаются из повсевместной фичи в приятный хелпер. В фреймворке уже есть готовый хелпер, и он поддерживает все сценарии — и с обёрткой, и с копированием. Смысла производить фундаментальные изменения в рантайме ради одной недофичи (и изменять ещё раз — при введении полноценной поддержки immutable) я не вижу.
я вижу.

S>>RO обертка не гарантирует неизменности содержимого тому кто берет ее снаружи.
S>Зачастую и не должна. Как пример — Dictionary.Keys.
Речь о неизменяемых коллекциях. Dictionary.Keys таковой не является и не может быть использована для гарантии неизменности содержимого.

S>> А копия не может быть закэширована и должна отдаваться наружу каждый раз новая.
S>Почему? Всё та же new ReadOnlyCollection<T>(source.ToArray()).
А откуда должно быть известно снаружи что содержимое этого экземеляра не изменится в будущем?

S>>Я особо не рассчитываю на внедрение иммутабельного массива. Но считаю что если бы он был внедрен хотя бы с фреймворком 2.0, то это сильно бы изменило положение вещей на текущий момент.
S>Да не изменило бы оно нифига. Кому надо — давно добавили extension CopyToReadOnly и соответствующее правило в FxCop. Кому не надо — философствуют на 11й(?) странице. Я явно отношусь к последним

S>Приведите хоть одно место в фреймворке (кроме ляпа с Path.InvalidChars), где immutable-массивы явно исправят положение к лучшему.
Даже не буду пытаться, т.к. в любом случае изменение фреймворка убьет совместимость. Однако, разработка приложений не ограничивается использованием одного только фреймворка и сопряжена с разработкой новых структур данных. В них-то и предполагается использование бенефитов иммутабельного массива.

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, samius, Вы писали:

S>>Повыделял выше. Речь о неизменяемых структурах и о том что их пропаганда была бы эффективнее, будь в FW или в рантайме неизменяемые коллекции. А так — смысл использования неизменяемого объекта в изменяемой коллекции ровно такой же как и у использования изменяемого объекта в изменяемой коллекции.

_FR>А почему ReradOnlyCollection<> изменяемая?

Потому что ее содержимое может измениться любым кто владеет переданной на конструктор коллекций втайне от тех кто владеет оберткой.
_FR> А у меня есть ещё ReadOnlyCollection2 (которая от ICollection<>), а так же сеты и словари и мне хватает

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

Здравствуйте, samius, Вы писали:

S>То есть речь о том, что если бы были такие массивы, то в методе записи в Stream должен был бы использвоаться иммутабельный массив, и тогда для блочного копирования пришлось бы задвинуть на реюз блоков?
Ну да, ваша же аргументация —

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

Я всего лишь довёл до абсурда, т.к. все предыдущие намёки на сомнительную полезность immutable-массивов при существующем положении дел как-то прошли мимо.

S>Вообще говоря я не предлагал переписывать фреймворк, но если бы такое случилось, я бы предпочел что бы Stream.Write принимал бы иммутабельный буфер, либо перегруженный метод, принимающий иммутабельный буфер.
А заполнялся бы этот immutable буфер копированием. Потому что в ряде сценариев буфер сначала собирают по кусочкам, из нескольких источников, а затем — скармливают в output.

S>Как бы ROC<T> не была создана, сам вид ROC<T> не обеспечивает видимости гарантии неизменности данных извне. Т.е. для того что бы понять, будут меняться данные или нет в этом ROC<T>, мне нужно открыть рефлектор и убедиться что ROC<T> создан с копированием данных, а не как-то иначе.

Это _очень_ редкий и абсолютно бесполезный для самого фреймворка юз-кейз. Поэтому или писать правило для FxCop, или создавать свою коллекцию, или писать в feedback, или ждать, пока МС вплотную займётся поддержкой неизменяемых типов данных.

Здравствуйте, samius, Вы писали:

S>>>Повыделял выше. Речь о неизменяемых структурах и о том что их пропаганда была бы эффективнее, будь в FW или в рантайме неизменяемые коллекции. А так — смысл использования неизменяемого объекта в изменяемой коллекции ровно такой же как и у использования изменяемого объекта в изменяемой коллекции.

_FR>>А почему ReradOnlyCollection<> изменяемая?

S>Потому что ее содержимое может измениться любым кто владеет переданной на конструктор коллекций втайне от тех кто владеет оберткой.

Ой ли? Или мы владеем тем, что передаём туда, или копируем. Поэтому не "может", а "можно сделать", если делать абы как

Так что всё зависит только от того, что "заворачивает".

Здравствуйте, samius, Вы писали:

_FR>>>>А почему ReradOnlyCollection<> изменяемая?

S>>>Потому что ее содержимое может измениться любым кто владеет переданной на конструктор коллекций втайне от тех кто владеет оберткой.
_FR>>Ой ли? Или мы владеем тем, что передаём туда, или копируем. Поэтому не "может", а "можно сделать", если делать абы как

Так что всё зависит только от того, что "заворачивает".

S>Что говорит о том что однозначного ответа на вопрос изменяемости данных ReadOnlyCollection нет, в сравнении со списками F#-а, или Nemerle. Все зависит от абы как, от того что и кто, и что случится когда.

Вывод совершенно не верный. Сравнивать ReadOnlyCollection<> предлагается не "со списками F#-а, или Nemerle" (тогда уж надо взять имутабельный список для шарпа) а с "неизменяемым массивом".

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, samius, Вы писали:

_FR>>>>>А почему ReradOnlyCollection<> изменяемая?

S>>Что говорит о том что однозначного ответа на вопрос изменяемости данных ReadOnlyCollection нет, в сравнении со списками F#-а, или Nemerle. Все зависит от абы как, от того что и кто, и что случится когда.

_FR>Вывод совершенно не верный. Сравнивать ReadOnlyCollection<> предлагается не "со списками F#-а, или Nemerle" (тогда уж надо взять имутабельный список для шарпа) а с "неизменяемым массивом".
(что за иммутабельный список для шарпа?)
Предполагается что содержимое неизменяемого массива нельзя изменить после создания. В этом контексте ReadOnlyCollection с ним не сравнивается.

Здравствуйте, VladD2, Вы писали:

VD>>>Меня не очень интересуют языки. Меня интересует фича в рантайме. "const" мне тоже не нужен.
K>>А я бы от "const" не отказался бы

VD>В С++ const — это не более пометка переменных которая помогает компилятору (и программисту) выявлять случаи нецелевого использования.

Вот иммено от такой помощи я бы и не отказался

... << RSDN@Home 1.2.0 alpha 4 rev. 1478>>

Здравствуйте, Kalina9001, Вы писали:

VD>>В С++ const — это не более пометка переменных которая помогает компилятору (и программисту) выявлять случаи нецелевого использования.

K>Вот иммено от такой помощи я бы и не отказался

А зачем, когда есть лучшее решение с железными гарантиями?

Здравствуйте, Sinix, Вы писали:

S>Эмм, я неправильно сформулировал вопрос.
S>

S>int[] data = { 1, 2, 3 };
S>ImmutableArray<int> roData = new ImmutableArray<int> (data); // Вот тут - произойдёт копирование, или нет?
S>

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

ImmutableArray<int> roData = new ImmutableArray<int> () { 1, 2, 3 }; // Тут - не будет

S>>>Наконец, что делать, если значения в массиве — mutable?
VD>>Если же в массиве лежит ссылка на объект содержащий изменяемые поля, то их можно будет по прежнему изменять, так как это память уже не принадлежит массиву.
S>Именно. И какая польза от immutable-массивов, если в половине случаев эту самую иммутабельность не обеспечить? Они тут же превращаются из главной фичи в приятную побочную мелочь. А только ради приятной мелочёвки никто рантайм корёжить не будет.

Нужна иммутабельность именно самого массива, без него ты не можешь ни отдать его наружу ни запомнить внутри. Всегда надо делать копии. Ты только представь, что такая беда была бы со строками: сделай такое сейчас, когда все уже привыкли, народ взвоет, но как и с массивами, многие бы не представляли бы зачем нужна их иммутабельность если бы они изначально были mutable. Все методы BCL меняли бы текущую строку, а заводить копию стало бы легким и привычным действием.

VD>>>>3. Ввел бы концепцию "хвостовых массивов".
S>>>Что это даст и в каких сценариях будет полезно? В 99.(9)% доступ к массиву осуществляется не напрямую, так что выигрыш будет съеден стоимостью вызова ацессора.

Так он потому и не напрямую

S>Ок, понятно. Только почему 12?

Во всех источниках — 8:

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

S>А смысл? Весь выигрыш — потеря 8 байт на контейнер. Харкод в рантайме будет в любом случае, иначе не будет дешёвой аллокации.

Нет, выигрыш в том, чтобы широко использовать массивы.

VD>>Никакая трассировка не нужна, так как каждый вызов такого метода будет создавать новую копию массива. Генерировать исключения тоже не надо, так как корректность доступа можно проверить статически во время джит-компиляции или верификации.
S>Тогда вся дискуссия о "эффективности контейнеров" сразу теряет смысл — стоимость копирования убивает все нанооптимизации на корню

Пользуются же сейчас StringBuilder для создания строк? Строка неэффективный контейнер? Наноптимизации будут на наноуровне. На их основе код пишется по другим принципам, которые могут дать самый эффективный вид оптимизации, алгоритмический.

	От:	MxMsk
	Дата:	30.01.11 20:28
	Оценка:

От:	Пельмешко	blog
Дата:	30.01.11 16:22
Оценка:	2 (2) +2

От:	VladD2	www.nemerle.org
Дата:	30.01.11 16:59
Оценка:	-4

От:	samius	http://sams-tricks.blogspot.com
Дата:	30.01.11 20:37
Оценка:	86 (4) +2

От:	VladD2	www.nemerle.org
Дата:	30.01.11 18:29
Оценка:	1 (1) -5

От:	Sinclair	https://github.com/evilguest/
Дата:	31.01.11 09:15
Оценка:	7 (1) +3

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	31.01.11 06:52
Оценка:	+1 -1

От:	adontz	http://adontz.wordpress.com/
Дата:	30.01.11 17:03
Оценка:	1 (1)

	От:	Аноним
	Дата:	30.01.11 19:03
	Оценка:	1 (1)

От:	xvost	http://www.jetbrains.com/company/people/Pasynkov_Eugene.html
Дата:	31.01.11 05:55
Оценка:	+1

От:	_FRED_	@ViIvanov
Дата:	31.01.11 15:55
Оценка:	+1

От:	bl-blx	http://yegodm.blogspot.com
Дата:	31.01.11 10:26
Оценка:

От:	TK	кывт.рф
Дата:	31.01.11 17:21
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	03.02.11 17:17
Оценка:

От:	_Eter_	http://mnazarov.ru
Дата:	08.02.11 19:53
Оценка:

	От:	Mira
	Дата:	04.02.11 19:42
	Оценка:	+1 -1