Автор Тема: Oberon & GCless modules  (Прочитано 24568 раз)

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: Oberon & GCless modules
« Ответ #15 : Август 09, 2012, 05:30:29 pm »
Впрочем, если вдруг в какой-нибудь mono тупой консервативный (или даже точный, но без поколений) сборщик мусора, то ой.
Это, кстати, отсекает наивные (простые) реализации .net/c#, java и так далее. Они дефакто не конкурентноспособны, просто из за того что будут вот подобные вот проблемы. Повышается порог вхождения для новых реализаций .net/java/haskell. Уменьшается конкуренция и имеем больше vendor lock in. В общем, это не слишком здорово, да. Хотя иногда вполне терпимо.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Губанов Сергей Юрьевич

  • Hero Member
  • *****
  • Сообщений: 590
    • Просмотр профиля
    • Домашняя страница
Re: Oberon & GCless modules
« Ответ #16 : Август 09, 2012, 07:15:23 pm »
И неплохо бы изначально убедиться что они не используют динамическую память.
Сам по себе NEW не шибко вреден, вред причиняет слишком частый его вызов и слишком большое количество динамических объектов, а это автоматической тулзовиной из исходников не вытянешь, самому врубаться надо.

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: Oberon & GCless modules
« Ответ #17 : Август 10, 2012, 07:42:05 am »
3) Сторонняя тулза которая прошерстит исходники даденых модулей и скажет если вдруг кто-то динамической памятью там пользуется (хм. можно просто сделать grep * NEW).
Лично я именно про это и подумал сразу - grep и все дела. Просто и надежно. Список всех модулей для "проверяемого" проекта все равно обязан быть на руках.
Кстати, grep не поможет если у нас используются сторонние проприентарные либы (ака пачки модулей). То есть сторонние модули в виде бинарей. Конкретная реализация оберона может вместо вызова функции NEW делать инлайн оной функции и grep ничего не даст.

Таким образом на уровне языка все же нужны изменения. Вариант от Kemet'a мне понравился.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: Oberon & GCless modules
« Ответ #18 : Август 10, 2012, 07:51:00 am »
И неплохо бы изначально убедиться что они не используют динамическую память.
Сам по себе NEW не шибко вреден, вред причиняет слишком частый его вызов и слишком большое количество динамических объектов, а это автоматической тулзовиной из исходников не вытянешь, самому врубаться надо.
Зависит от сценария и окружения. Если у тебя памяти всего порядка единиц килобайт и есть требования к реалтайму (не софт реалтайм, как в телекоме, а настоящий реалтайм - если не уложился во время переферийное устройство просто зависнет нафик, потребудется перезагрузка), то сборщик мусора становится категорически противопоказан в любых колличествах. Это с одной стороны.

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

DIzer

  • Гость
Re: Oberon & GCless modules
« Ответ #19 : Август 10, 2012, 11:36:04 am »
чем больше читаю постов в этой теме, тем более укрепляется ощущение что в этой области публике больше прокатит упрощенный СИ...

Romiras

  • Sr. Member
  • ****
  • Сообщений: 264
    • Просмотр профиля
    • Romiras Dev Lab
Re: Oberon & GCless modules
« Ответ #20 : Август 10, 2012, 11:41:41 am »
Не хотите сборщика мусора? Берите Модулу-2.

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re: Oberon & GCless modules
« Ответ #21 : Август 10, 2012, 11:50:52 am »
Не хотите сборщика мусора? Берите Модулу-2.
Зачем же сразу Модулу-2? В описании Оберона (тех самых 16 страницах) ничего же не говорится про сборщик мусора, GC является обязательным лишь для Компонентного Паскаля...
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: Oberon & GCless modules
« Ответ #22 : Август 10, 2012, 12:15:11 pm »
Не хотите сборщика мусора? Берите Модулу-2.
Зачем же сразу Модулу-2? В описании Оберона (тех самых 16 страницах) ничего же не говорится про сборщик мусора, GC является обязательным лишь для Компонентного Паскаля...
Начиная как минимум с Оберона-2. Возможно даже еще в Object Oberon'e. См. дерево: http://www.oberon.ethz.ch/language/genealogy/ Отлично видно, что Oberon, Oberon-07/12 принадлежат к другой ветке.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Romiras

  • Sr. Member
  • ****
  • Сообщений: 264
    • Просмотр профиля
    • Romiras Dev Lab
Re: Oberon & GCless modules
« Ответ #23 : Август 10, 2012, 02:17:59 pm »
Не хотите сборщика мусора? Берите Модулу-2.
Зачем же сразу Модулу-2? В описании Оберона (тех самых 16 страницах) ничего же не говорится про сборщик мусора, GC является обязательным лишь для Компонентного Паскаля...
А каким образом освобождать выделенную динамическую память?

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: Oberon & GCless modules
« Ответ #24 : Август 10, 2012, 02:20:26 pm »
Не хотите сборщика мусора? Берите Модулу-2.
Зачем же сразу Модулу-2? В описании Оберона (тех самых 16 страницах) ничего же не говорится про сборщик мусора, GC является обязательным лишь для Компонентного Паскаля...
А каким образом освобождать выделенную динамическую память?
Это уже детали реализации.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Romiras

  • Sr. Member
  • ****
  • Сообщений: 264
    • Просмотр профиля
    • Romiras Dev Lab
Re: Oberon & GCless modules
« Ответ #25 : Август 10, 2012, 02:51:35 pm »
Не хотите сборщика мусора? Берите Модулу-2.
Зачем же сразу Модулу-2? В описании Оберона (тех самых 16 страницах) ничего же не говорится про сборщик мусора, GC является обязательным лишь для Компонентного Паскаля...
А каким образом освобождать выделенную динамическую память?
Это уже детали реализации.
Мне известно о двух видах работы с памятью: ручного (программистом) и автоматического сбора памяти (сборщиком мусора). Если для ручного сбора выделенной памяти отсутствует операция для освобождения памяти, то следует подразумевать, что она будет освобождена автоматически, без явного указания.
Какой разработчик компилятора Оберона с ручным управлением памяти допустит использование процедуры NEW без соответствующей ей пары в виде DISPOSE?
Или, по-твоему, в таком компиляторе будет использоваться дополнительный модуль для ручного сбора памяти (наподобие MemMgr.DISPOSE)? :)

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: Oberon & GCless modules
« Ответ #26 : Август 10, 2012, 03:07:12 pm »
Это уже детали реализации.
Мне известно о двух видах работы с памятью: ручного (программистом) и автоматического сбора памяти (сборщиком мусора). Если для ручного сбора выделенной памяти отсутствует операция для освобождения памяти, то следует подразумевать, что она будет освобождена автоматически, без явного указания.
Какой разработчик компилятора Оберона с ручным управлением памяти допустит использование процедуры NEW без соответствующей ей пары в виде DISPOSE?
Или, по-твоему, в таком компиляторе будет использоваться дополнительный модуль для ручного сбора памяти (наподобие MemMgr.DISPOSE)? :)
Например DISPOSE можно запихать в какой-нибудь псевдомодуль, например SYSTEM. Ну а на крайняк, почему бы и не в отдельный настоящий модуль вроде MemMgr?
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Romiras

  • Sr. Member
  • ****
  • Сообщений: 264
    • Просмотр профиля
    • Romiras Dev Lab
Re: Oberon & GCless modules
« Ответ #27 : Август 10, 2012, 03:15:14 pm »
Ну если тебе так больше нравится, то уж лучше сразу NEW и DISPOSE отделить от языка.

Влад Жаринов

  • Full Member
  • ***
  • Сообщений: 189
    • Просмотр профиля
Re: Oberon & GCless modules
« Ответ #28 : Август 10, 2012, 03:21:20 pm »
Кстати, в спецификации О-2 от Вирта явно определена нужность сбора мусора и основы его реализации (пп. D3,5).

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re: Oberon & GCless modules
« Ответ #29 : Август 10, 2012, 03:25:59 pm »
Кстати, в спецификации О-2 от Вирта явно определена нужность сбора мусора и основы его реализации (пп. D3,5).
Oberon-2 не совсем от Вирта все же. И да, про этом в этом топике уже упоминалось:

Не хотите сборщика мусора? Берите Модулу-2.
Зачем же сразу Модулу-2? В описании Оберона (тех самых 16 страницах) ничего же не говорится про сборщик мусора, GC является обязательным лишь для Компонентного Паскаля...
Начиная как минимум с Оберона-2. Возможно даже еще в Object Oberon'e. См. дерево: http://www.oberon.ethz.ch/language/genealogy/ Отлично видно, что Oberon, Oberon-07/12 принадлежат к другой ветке.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"