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

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

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

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

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

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

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

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

Автор: samius
Дата: 30.01.11

. Но вряд ли можно понять их не меняя менталитет.

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

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

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

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

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

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

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

Автор: VladD2
Дата: 31.01.11

.

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

Здравствуйте, _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") а вот всем остальным вызывать будет удобнее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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>. Но я уже отвечал, что такая коллекция имеет тот недостаток, что она местячковая а не из коробки и не может использоваться в качестве стандартной в межбиблиотечных контрактах.

Здравствуйте, 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>А сколько придётся вводить для многомерных массивов/массивов с ненулевой индексацией?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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