OberonCore

В Oberon at glance указано ограничение для ARM-версии
Open arrays as parameters cannot have more than one dimension.
Значит, что-то может и на динамически создаваемые массивы влиять.
Смотрим дальше.

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

Я таки дико извиняюсь, но при чем тут ОС? Менеджер памяти это чисто библиотечное средство. В частности их можно легко менять, и вообще можно написать свой.

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

Это, опять таки, к массивам с размером неизвестным на этапе компиляции, отношения не имеет.

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

Как-то так, в общем...

И? Каким образом релокация массива к массивам с неизвестным размером на этапе компиляции? От темы не стоит отклоняться таки

Рапортую о том как опасны динамические массивы

На работе несколько лет иногда у клиентов в программе память текла "на ровном месте" ни с того ни с сего. Дорастает до 3.5 гигабайтов и на что израсходовано - не понятно. В лабораторных условиях воспроизвести не получалось.

На что только не думали...

И вот, сейчас думаем, что вроде как нашли...

Там иногда (в зависимости от действий клиентов) временно создаются большие динамические массивы. Используется Mono 2.4. Сборщик мусора не перемещающий. Вот и наступает фрагментация памяти.

Вывод.

Хочешь динамические массивы - заодно хоти и перемещающий сборщик мусора.

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

Может быть, это синдром for-array поднимает свою ugly head?

В Блэкбоксе, видимо, сборщик мусора как раз неперемещающий?

Фрагментации можно добиться и без массивов, если, например, есть два или более вида записей, с размерами отличающимися в разы. Может сложится ситуация, что суммарной памяти достаточно, а память под запись бОльшего размера выделить не получается.

Чтобы не было фрагментации, тогда надо, чтобы все выделяемые куски памяти были одного и того же размера, тогда они будут взаимозаменяемы.

> это синдром for-array

А ещё синдром найма дешёвых "студентов", после которых весь код надо переписывать.

> Фрагментации можно добиться и без массивов

Да, но со 100 Мб массивами быстрее. Мне мерещится, что при фрагментации память растёт логарифмически, поэтому при использовании небольших объектов программа без рестарта может работать неделями-месяцами, а ежели начать баловаться большими объектами - съешь всю память за считанные дни-часы.

Только такой вариант не скомпилируется, из-за того, что базовым типом у Stream не является тип "запись".