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

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

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

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

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

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

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

Думаю, что без ленивости такие массивы неинтересны.

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

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

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

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

Соответственно писать приходится на C# и тут возникает когнитивный диссонанс без надежды обрести катарсис.

А неизменяемый массив вобщем то ни при чем

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

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

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

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

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

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

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

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

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

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

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

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

const T* ptr; — константный указатель на константный объект.
Ломается в два счёта:
((T*)((void*)(const void*)ptr))[0] = value;

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

XR>const T* ptr; — константный указатель на константный объект.
XR>Ломается в два счёта:
XR>((T*)((void*)(const void*)ptr))[0] = value;

Сломать можно все, unsafe в шарпе и вперед

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

M>Или это как-то косвенно имеется?

Конечно имеется. Разбиваете контракт Вашего типа на интерфейсы по признаку read\write. В нашем случае то что write ещё и отнаследовано от read. Далее что кому надо, то и указываете как тип параметра. Метод универсален для любого количества признаков и их комбинаций.

*Развитая типизация рулит

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

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

So here it is, my current position as of december '96...

То есть, это написано 14+ лет назад. Позже он же написал, что очередная версия DX не хуже OGL в техническом плане (но она не кроссплатформенна, а это минус). Хотя там тот же ООП-ный подход. Просто многие начинают с D3DIM7/8/9/10 и даже не знают, какое говнище DX был раньше.

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

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

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


А еще бывает не хватает штуки типа readonly, но чтобы инициализация была бы не только в конструкторе, а в любом месте с последующим запретом изменения (хотя я допускаю, что такая потребность возникает при не очень прямом дизайне)

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

_E_>Мне, наверно, тоже не хватает таких массивов, но возможно их не просто добавить, чтобы это было естественно и не вызывало путаницы.

Для этого всего лишь нужна политическая воля (как любят говорить наши политики).

_E_>А еще бывает не хватает штуки типа readonly, но чтобы инициализация была бы не только в конструкторе, а в любом месте с последующим запретом изменения (хотя я допускаю, что такая потребность возникает при не очень прямом дизайне)

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