Oberon & GCless modules

[Valery Solovey]

Псевдомодуль GC добавляет предопределённую процедуру NEW, а псевдомодуль DM добавляет процедуры NEW и DROP. Модули взаимоисключаемые, и за этим может следить компилятор.

[valexey]

Ну если тебе так больше нравится, то уж лучше сразу NEW и DISPOSE отделить от языка.

Я слабо представляю как можно NEW отделить от языка - это не типичная процедура и/или функция. Средствами языка нельзя реализовать процедуру NEW.

[Влад Жаринов]

Кстати, в спецификации О-2 от Вирта явно определена нужность сбора мусора и основы его реализации (пп. D3,5).

Oberon-2 не совсем от Вирта все же. И да, про этом в этом топике уже упоминалось:
...

Да, точно... Сборку мусора для Оберона он описывает в "Проекте Оберон", и это ессно не описание языка...

[DIzer]

Ну если тебе так больше нравится, то уж лучше сразу NEW и DISPOSE отделить от языка.

Я слабо представляю как можно NEW отделить от языка - это не типичная процедура и/или функция. Средствами языка нельзя реализовать процедуру NEW.

И что ? можно рассматривать Оберон без GC(и динамически распределяемой памятью) как подмножество Оберона с  GC(как это делают в Австралии) - хотя правомерно ли называть Обероном это подмножество..вопрос еще тот, поэтому не проще ли будет повысить СИ , или понизить С++

[Geniepro]

Мне известно о двух видах работы с памятью: ручного (программистом) и автоматического сбора памяти (сборщиком мусора).

Ну есть ещё как минимум третий: http://en.wikipedia.org/wiki/Region-based_memory_management

[Romiras]

Всё же чутьё подсказывает, что таки проще изменить Оберон нежели Си.

А как называть - не вопрос. Называйте хоть Абероном. "А" - альтернативный. Прям как форум.

P.S.
Кстати, "DROP" не надо. Сильно ассоциируется с SQL.

[DIzer]

А чем он идеологически отличается от ручного управления?
пара
createRegion()
destroyRegion()
присутствует...

[valexey]

Всё же чутьё подсказывает, что таки проще изменить Оберон нежели Си.

А как называть - не вопрос. Называйте хоть Абероном. "А" - альтернативный. Прям как форум.

P.S.
Кстати, "DROP" не надо. Сильно ассоциируется с SQL.

Hello, my name is "Robert'); DROP TABLE Students; --"

:-)

[DIzer]

Всё же чутьё подсказывает, что таки проще изменить Оберон нежели Си.

А как называть - не вопрос. Называйте хоть Абероном. "А" - альтернативный. Прям как форум.

P.S.
Кстати, "DROP" не надо. Сильно ассоциируется с SQL.

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

[DIzer]

... точнее динамической компоновки модулей.

[Geniepro]

Hello, my name is "Robert'); DROP TABLE Students; --"

:-)

ненене, вот как там было: 

[Geniepro]

А чем он идеологически отличается от ручного управления?
пара
createRegion()
destroyRegion()
присутствует...

Да, немного неудачный пример я привёл.

Ну, во-первых, в языках типа C# можно автоматизировать вызов процедуры destroyRegion(), если оформить это в конструкцию using:

Код: [Выделить]

using (Region r = new Region())
{
    // Здесь используем этот регион
    Object o = r.New<Object>();
    ...
}
// А здесь компилятор вставляет вызов уничтожения региона
В языках без конструкции using (типа оберона) или без возможности создать аналог using самостоятельно (а это легко можно сделать в тех же лиспе, смоллтоке или хаскелле -- в языках с замыканиями), там да, придётся вручную освобождать регионы...

Во-вторых, ведутся работы по автоматическому управлению регионами. Хотя это, наверное, уже вариация на тему GC...

[DIzer]

Во-вторых, ведутся работы по автоматическому управлению регионами. Хотя это, наверное, уже вариация на тему GC...

Второй наводящий вопрос - в чем принципиально отличается "автоматическое управление регионами", от автоматического управления загрузкой\выгрузкой модулей (в том смысле как они понимаются в Обероне), и в свою очередь от GC? Ох а как вспомнишь, что Обероны в принципе допускают кроссмодульную неявную рекурсию.....

[valexey]

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

Ну, то есть это обычный RAII/умные указатели в С++ :-)

[Geniepro]

Во-вторых, ведутся работы по автоматическому управлению регионами. Хотя это, наверное, уже вариация на тему GC...

Второй наводящий вопрос - в чем принципиально отличается "автоматическое управление регионами", от автоматического управления загрузкой\выгрузкой модулей (в том смысле как они понимаются в Обероне), и в свою очередь от GC? Ох а как вспомнишь, что Обероны в принципе допускают кроссмодульную неявную рекурсию.....

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

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

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