Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 2376 27-01-2007 03:54 | |
сообщение от модератораJack of Shadows, Сергей Перовский:
Для обсуждения Hascel vs Basic у вас есть отдельная ветка, здесь это оффтопик.
№ 2375 27-01-2007 02:30 | |
Ответ на »сообщение 2372« (AVC)
___________________________
Читал ли кто-нибудь статью Вирта "Tasks versus threads" (1996)? Где ее можно найти?
Ее можно попробовать заказать в Springer. Это была не только статья в журнале "Software - Concepts and Tools" (изд-во Springer), но и лекция с которой Вирт выступал в Новосибирском академгородке при вручении ему звания почетного доктора НГУ. Я слышала эту лекцию: там речь шла, если память не изменяет, о том, почему Вирт выбрал для системы Oberon именно такой подход для работы с процессами. По рукам тогда ходили и репринты. Возможно у кого-то они сохранились.
№ 2374 27-01-2007 01:01 | |
Ответ на »сообщение 2373« (AVC)
___________________________
Ответ на »сообщение 2371« (info21)
___________________________
Какие-то странные слова насчет сбора мусора народ говорит.
Ну не используйте NEW, и все.
Наверное, необязательно так радикально.
В некоторых случаях можно просто складывать "отработанные" объекты в некий пул, и извлекать оттуда повторно в случае надобности.
Это и имелось в виду -- управлять вручную, раз охота :))
№ 2373 26-01-2007 18:40 | |
Ответ на »сообщение 2371« (info21)
___________________________
Какие-то странные слова насчет сбора мусора народ говорит.
Ну не используйте NEW, и все.
Наверное, необязательно так радикально.
В некоторых случаях можно просто складывать "отработанные" объекты в некий пул, и извлекать оттуда повторно в случае надобности.
Если пул реализован как стек, то среднее время "создания" и "уничтожения" объекта составит O(1).
Это может быть актуально для real-time, а также для использования объекта локально внутри процедуры, не завязываясь на реализацию объекта в другом модуле.
Пример (сильно упрощенный, пул состоит всего из одного объекта).
MODULE M1;
TYPE Object = POINTER TO LIMITED RECORD ... END;
VAR pool: Object;
PROCEDURE New* (): Object;
VAR new: Object;
BEGIN
IF pool = NIL THEN NEW(new)
ELSE
new := pool;
pool := NIL
END;
...
RETURN new
END New;
PROCEDURE Dispose* (p: Object);
BEGIN
IF pool = NIL THEN pool := p END
END Dispose;
END M1.
№ 2372 26-01-2007 17:38 | |
Читал ли кто-нибудь статью Вирта "Tasks versus threads" (1996)?
Где ее можно найти?
№ 2371 26-01-2007 16:17 | |
Ответ на »сообщение 2361« (Alexey Veselovsky)
___________________________
Ответ на »сообщение 2359« (dfg)
___________________________
Ответ на »сообщение 2357« (Сергей Перовский)
___________________________
А в Oberon очень нужен сборщик мусора?
Не сильнее чем С, но, возможно, сильнее чем С++.
Какие-то странные слова насчет сбора мусора народ говорит.
Ну не используйте NEW, и все.
Капитальное какое-то непонимание. Вроде сто раз уже пережевали...
№ 2370 26-01-2007 16:15 | |
Ответ на »сообщение 2368« (Jack Of Shadows)
___________________________
Надоел оффтоп.
Модераторы, ау!
№ 2369 26-01-2007 14:39 | |
Ответ на »сообщение 2368« (Jack Of Shadows)
___________________________
Вам всего то хаскель скачать, да книжку к нему, и через пару недель вы уже сможете вполне компетентно сказать нам сойдет Васек как замена хаскелю или не сойдет :))
"Кто имеет знания и делает вид незнающего, тот на высоте. Кто без знаний делает вид всезнающего, тот болен". (Лао-Цзы)
"Больше всего люди интересуются тем, что их совершенно не касается". (Бернард Шоу)
"Сколько нелепостей говорится людьми только из желания сказать что-нибудь новое". (Вольтер)
От себя добавлю: Когда у человека потеряно чувство меры, это множит печаль.
Можно спорить до посинения о том, почему ФП лучше ИП. Обсуждаются Haskell, Erlang, C++, Basic, только не Oberon. Понимаю, что бывает просто нечем заняться. Но почему здесь? Неужели нет другого места?
№ 2368 26-01-2007 12:56 | |
Ответ на »сообщение 2356« (Сергей Перовский)
___________________________
Я не согласен с тем, что функциональное представление удобнее ДЛЯ ЛЮБОГО АЛГОРИТМА.
Не согласен - не пишите :)) В том и удобство функциональных языков, что вы сами решаете какое представление алгоритма вам удобнее. Вам доступны оба представления.
Я всегда выбираю. Нет проблем с написанием фрагментов кода в функциональном стиле в любом современном
языке. Даже Васек сойдет.
Есть проблемы с написанием кода в функциональном стиле на ИЯ. И Васек НЕ сойдет.
Дело не в том чтобы вы выбрали себе ФЯ и официально отреклись от своей веры :))
Дело в том что говоря что там сойдет или не сойдет вы занимаетесь самообманом. По той простой причине что невозможно сравнивать то что знаешь с тем что НЕ знаешь. А вы не знаете ни черта об ФП уважаемый Сергей.
И узнавать судя по всему не собираетесь.
Хотя я уже говорил, уж вам то легче чем тем кто хочет использовать ФЯ.
Вам не нужно искать среды, библиотеки.
Вам всего то хаскель скачать, да книжку к нему, и через пару недель вы уже сможете вполне компетентно сказать нам сойдет Васек как замена хаскелю или не сойдет :))
№ 2367 26-01-2007 09:43 | |
Ответ на »сообщение 2365« (Илья Ермаков)
А вообще-то торможение от сборщика может быть значительным лишь при частом выделении короткоживущих мелких объектов. Для этого можно использовать буферизацию с явным выделением-возвратом.
Здесь имелся ввиду сборщик мусора без поколений (реализованный в BlackBox). В .Net & JVM используется сборщик мусора ранжирующий объекты по поколениям и для него короткоживущие мелкие объекты, наоборот, являются "подароком судьбы" - он их вычищает в несколько раз быстрее чем все остальные объекты. Зато для него проблема когда время жизни всех объектов примерно одинаковое. В этом случае он в несколько (2-3) раз медленнее сборщика мусора без поколений.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|