Re[28]: СИСТЕМНОСТЬ
От: Cyberax Марс  
Дата: 19.01.05 13:43
Оценка: 35 (7) +1
Сергей Губанов пишет:

> C> В _30_ раз быстрее Линукса? А защита памяти там есть?

> Именно там она, в отличие от систем написанных на Си, как раз-то и есть!

Нет, нету там защиты памяти. Если "внешняя библиотека", которые из-за
убогости языка нужны очень часто, запишет что-то "не туда" — *все* упадет.

Кстати, посмотрел XDS:
1. Тестируем modулу:
|Please, wait about 60 seconds Dhrystone time for 4000000 passes = 1
This machine benchmarks at 4000000 dhrystones/second |

2. Тестируем C-версию (отладочный режим, без оптимизаций, компилятор
MSVC 8 Beta 1):
|D:\XDS\SAMPLES\BENCH\BENCH\BENCH\Debug>BENCH.exe Please, wait about 60
seconds Dhrystone time for 4000000 passes = 4 This machine benchmarks at
1000000 dhrystones/second |

Боже мой! Разница в _4_ раза! Наверное все-таки С — это полный отстой.
Но смотрим дальше:

3. Тестируем C-версию (*релизный* режим, максимальные оптимизации,
компилятор MSVC 8 Beta 1):
|D:\XDS\SAMPLES\BENCH\BENCH\BENCH\Release>BENCH.exe Please, wait about
60 seconds Dhrystone time for 4000000 passes = 0 |
И в этом месте программа падает с ошибкой деления на 0. После правки
теста получаем результат 12000000 попугайчиков.

Так что это XDS проигрывает в *3 раза* по скорости. И это я еще не
использовал Profile-Guided Optimization и не искал "узкие места" в
тесте. Да, кстати, размер исполняемого файла XDS: 53760 байт, а
скомпилированного Студией Сшника: 52463 байт.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[9]: Оберон vs все остальное
От: AndrewJD США  
Дата: 13.01.05 15:14
Оценка: 2 (2) +6
Здравствуйте, Сергей Губанов, Вы писали:

C>>Да, а почему сам используешь при этом возможности Object Pascal'я, а не

C>>обычный Pascal?

СГ>Я не понял Ваш вопрос. Вообще-то я тут говорил про Component Pascal от Никлауса Вирта. При чем тут борландовские поделки ума не приложу...


ИМХО только благодаря "борландовским поделкам" паскаль все еще остается популярным.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Re[4]: Оберон vs С#
От: Silver_s Ниоткуда  
Дата: 21.01.05 17:11
Оценка: :))) :))) :))
А может лучше так? C# такое на ура проглотит, главное не окосеть самому.


public delegate Action Action(Action Action);
class Insane
{
    Action Action(Action Action)
    {
        Action(Action);
        return Action;
    }
    public void Call()
    {
        Action(new Action(Action));
    }
}
Re[13]: Оберон vs все остальное
От: Cyberax Марс  
Дата: 14.01.05 09:07
Оценка: 1 (1) +4
Сергей Губанов пишет:

> Бортовой компьютер (получивший, кстати, имя OLGA = Oberon Language

> Goes Airborne) оказался настолько компактным благодаря компактности и
> эффективности получившихся программ (использовалось подмножество языка
> Оберон), что вес машины удалось резко снизить по сравнению с
> предыдущими версиями конструкции — всего до 15 кг. (Потомки компьютера
> OLGA используются в компании weControl.)
>
Ой, ну не надо ля-ля. Однокристалки в 10 грамм веса с JVM на борту
сейчас почти в каждом мобильнике.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[4]: Оберон vs все остальное
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.01.05 13:17
Оценка: -1 :))) :)
Здравствуйте, Кодёнок, Вы писали:


J>>> и еще отсутствие разделения на процедуры и функции


СГ>>Загадка. Слабо на Си или Си++ написать тип функции принимающей в качестве аргумента и возвращающей переменную ее собственного типа?


Кё>Загадка 1. Как на Component Pascal реализуется ну простейшая задача — одномерный динамический массив (список) объектов? Интересует как синтаксически, так и по скорости. Типа vector<CMyType>.


ARRAY OF CMyType

POINTER TO ARRAY OF CMyType


Кё>Загадка 2. Как на нем же реализуется собственный тип, который по поведению аналогичен простому типу. Пример: Math.Complex, DateTime. Как синтаксически будет выглядеть работа с этим типом?

TYPE
  Complex = RECORD re, im: REAL; END;

  DateTime = RECORD 
    year : INTEGER; 
    month: BYTE;
    day  : BYTE;
    hour : BYTE;
    min  : BYTE;
    sec  : BYTE;
  END;

PROCEDURE Sum(IN a,b: Complex; OUT c: Complex);
BEGIN
  c.re := a.re + b.re; c.im := a.im + b.im
END Sum;

...


Кё>Загадка 3. Как часто мне приходилось решать твою загадку на пракике?


Наверное Вы ее встретили в первый раз здесь. Ранее она просто в голову не могла придти. Язык ограничивает мышление.
Re[11]: Оберон vs все остальное
От: Кодёнок  
Дата: 14.01.05 08:16
Оценка: +4
СГ>Ах вот в чем дело. То есть термином "гибкость" здесь названо, то, что другие люди называют термином "грязный хак". Дело в том, что когда возникает необходимость определить процедуру принимающую произвольное количество аргументов различных типов, то это решается элементарнейшим способом:

Сам-то понял что написал? Нет ни у меня хака, ни у тебя элементарности.
Re[12]: Оберон vs все остальное
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 14.01.05 09:00
Оценка: :))) :)
Здравствуйте, Курилка, Вы писали:

К> Приведи-ка, плиз, реализации его в embedded systems, если не трудно, конечно...

К>(просто интересно )

Несколько ссылок можно найти там: http://www.inr.ac.ru/~info21/info/wirth_avia.htm

Еще один проект, в котором Н.Вирт участвовал в течение нескольких лет начиная с 1995 г., был посвящен созданию беспилотного вертолета, способного автономно пролететь по заданному маршруту (проект, предпринятый в the Institute of Automatic Control and Measurement; создание "умных" беспилотных летательных аппаратов вызывает огромный интерес во всем мире, в том числе и в России, и прежде всего, конечно, у военных). Н.Вирт написал для проекта все программное обеспечение, начиная с компилятора для процессора StrongARM и кончая бортовой управляющей системой реального времени. Бортовой компьютер (получивший, кстати, имя OLGA = Oberon Language Goes Airborne) оказался настолько компактным благодаря компактности и эффективности получившихся программ (использовалось подмножество языка Оберон), что вес машины удалось резко снизить по сравнению с предыдущими версиями конструкции — всего до 15 кг. (Потомки компьютера OLGA используются в компании weControl.)

Читатель может прикинуть, сколько весила бы машина, если бы ее ПО создавалось на основе таких популярных языков как Java или C++ — и когда был бы закончен проект. В качестве масштабного множителя можно предложить отношение объемов описаний языков — 16 стр. для Оберона, 200 для Java и больше 1000 для C++. )

Re[3]: Оберон vs все остальное
От: Трурль  
Дата: 28.01.05 14:25
Оценка: +1 -3
Здравствуйте, Cyberax, Вы писали:

C>И в итоге получится аналог .NET, только с гораздо более уродливым

C>языком, чем C#
и кучей других недостатков (отсутствием стандарта
C>интероперабельности и т.п.).
Трудно проидумать что-либо более уродливое, чем C#.

Мы еще посмотрим, кто из нас убогий.

Re: Оберон vs все остальное
От: Кодт Россия  
Дата: 18.02.05 00:21
Оценка: 51 (2) :)
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Загадка. Слабо на Си или Си++ написать тип функции принимающей в качестве аргумента и возвращающей переменную ее собственного типа?


СГ>На Component Pascal это элементарно:

СГ>
СГ>TYPE
СГ>  Action = PROCEDURE (a: Action): Action;
СГ>


Решение для С++, правда, требующее класса-хелпера.
#include <iostream>
using namespace std;

struct action_wrapper
{
  typedef action_wrapper (*func_type) (action_wrapper a, int x);

  func_type func; // обёрнутое данное

  action_wrapper(func_type f) : func(f) {} // приведение функции к обёртке
  operator func_type() const { return func; } // приведение обёртки к функции
};
typedef action_wrapper::func_type action; // вынесем, для удобства, в глобальное пространство имён

// это - глобальные функции
action_wrapper foo(action_wrapper a, int x);
action_wrapper bar(action_wrapper a, int x);
action_wrapper buz(action_wrapper a, int x);

// реализацию сделаем какую-нибудь кудрявую, чтобы не было шансов для инлайна
action_wrapper foo(action_wrapper a, int x)
{
  cout << "foo(" << x << ")" << endl;
  return x%2 ? a : bar;
}
action_wrapper bar(action_wrapper a, int x)
{
  cout << "bar(" << x << ")" << endl;
  return foo(buz,x);
}
action_wrapper buz(action_wrapper a, int x)
{
  cout << "buz(" << x << ")" << endl;
  return a(foo,x);
}

int main()
{
  cout << "--- цепочка ---" << endl;
  buz(foo,1)(bar,2)(buz,3);

  cout << "--- автомат ---" << endl;
  action f = foo, g = bar;
  for(int i=1; i<10; ++i)
  {
    g = f(g,i);
    f = g;
  }
  return 0;
}

Заметь, мне не пришлось рожать классы для каждой функции — ровно один класс на тип. И шаблонов здесь тоже нет. И трюков с реинтерпретацией.
А ещё заметь, что sizeof(action_wrapper) == sizeof(FUNCPTR), то есть никаких накладных расходов!
Перекуём баги на фичи!
Оберон vs все остальное
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.01.05 11:33
Оценка: 2 (1) -1 :)
Здравствуйте, jazzer, Вы писали:

J> и еще отсутствие разделения на процедуры и функции


Загадка. Слабо на Си или Си++ написать тип функции принимающей в качестве аргумента и возвращающей переменную ее собственного типа?

На Component Pascal это элементарно:
TYPE
  Action = PROCEDURE (a: Action): Action;


21.01.05 11:51: Ветка выделена из темы Слабо?
Автор: DEMON HOOD
Дата: 06.01.05
— AndrewVK
Re[7]: Оберон vs все остальное
От: jazzer Россия Skype: enerjazzer
Дата: 13.01.05 11:19
Оценка: 2 (1) +2
Здравствуйте, Сергей Губанов, Вы писали:

СГ>А я может капризный такой, вот не хочу тяжеловесное и громоздкое ООП, а хочу самую что ни на есть пересамую завалящуюся обыкновенную функцию...


Может, в этом и проблема оберона, что простейший класс в С++, ничем не отличающийся и не несущий большей нагрузки для компилятора и рантайма, чем указатель на функцию, на обероне превращается в "тяжеловесное и громоздкое ООП" из-за обязательных GC и т.д?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[3]: Оберон vs все остальное
От: Кодёнок  
Дата: 12.01.05 12:16
Оценка: +3
J>> и еще отсутствие разделения на процедуры и функции

СГ>Загадка. Слабо на Си или Си++ написать тип функции принимающей в качестве аргумента и возвращающей переменную ее собственного типа?


Загадка 1. Как на Component Pascal реализуется ну простейшая задача — одномерный динамический массив (список) объектов? Интересует как синтаксически, так и по скорости. Типа vector<CMyType>.

Загадка 2. Как на нем же реализуется собственный тип, который по поведению аналогичен простому типу. Пример: Math.Complex, DateTime. Как синтаксически будет выглядеть работа с этим типом?

Загадка 3. Как часто мне приходилось решать твою загадку на пракике?
Re[20]: Системность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 18.01.05 13:20
Оценка: :)))
Здравствуйте, Poudy, Вы писали:

P>Ты действительно уверен, что это из-за Оберона?


Да.
Re[17]: Оберон vs все остальное
От: WolfHound  
Дата: 19.01.05 08:56
Оценка: +3
Здравствуйте, Сергей Губанов, Вы писали:

WH>>Типизировано? Или как всегда полиморфно?

СГ>Как пожелаете.
А типизированно как всегда ручками для каждого типа? Если да то в лес такое решение.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[24]: Системность
От: WolfHound  
Дата: 19.01.05 09:16
Оценка: +2 -1
Здравствуйте, Сергей Губанов, Вы писали:

СГ>цитата из статьи http://www.uni-vologda.ac.ru/oberon/infoart/fromm2o.htm

СГ>

СГ>...Компилятор для Oberon’а был реализован для процессоров семейства NS32000 и был встроен в операционную среду Oberon [GuW89]. Этот компилятор требует менее 50 Кбайт памяти, состоит из 6 модулей, общим размером около 4000 строк исходного текста и сам себя компилирует примерно за 15 секунд на рабочей станции с 25 МГц процессором типа NS32532...

И? А что мешает на мощьной станции откомпилировать и оптимизировать по самые не балуйся программу, а потом залить ее в железку?

ЗЫ Я не верю что в 4000 строк мог поместится оптимизирующий компилятор. А отсутствие оптимизации это как ни крути приговор.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[27]: СИСТЕМНОСТЬ
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 21.01.05 14:27
Оценка: :)))
Здравствуйте, alexeiz, Вы писали:

A>Здравствуйте, Сергей Губанов, Вы писали:


СГ>>Компилятор Oberon for Aos (в Aos BlueBottle, та самая в которой минимальный системный вызов в 30 раз быстрее чем в Linux), ...


A>Кстати, в это не так уж и трудно поверить. Системный вызов достаточно накладен. Параметры на валидность нужно проверить, данные из user mode в kernel mode скопировать, режим переключить. Так как в BlueBottle ничего подобного нет, то не стоит удивляться, что данная фича в нём быстрее.


3D игры надо под нее писать. Все будет просто летать.
Re[2]: Оберон vs все остальное
От: Cyberax Марс  
Дата: 28.01.05 10:02
Оценка: +3
Borisman2 пишет:

> Однако, странная постановка вопроса! Правильный ответ — конечно,

> отстрелите себе ногу!!! И результат мало зависит от конкретной ОС или
> там от сборщика мусора.
> Тем не менее. Когда апологеты Оберона отвечают, что надо УДАЛИТЬ
> АКТИВНЫЙ ОБЪЕКТ, который выполняет данный код, противники (иногда)
> начинают измываться — "эта мол что, оберон мой объект прибил??? Ай,
> нехорошо...." Вы уж определитесь, что вам нужно. И замените термин
> "процесс" на термин "активный объект"

Вроде который раз пытаемся уже сказать, что НЕ ПОЛУЧИТСЯ просто так
удалить "активный объект". Это приведет к куче проблем, так как на
удаленный объект могут ссылаться другие активные объекты, или если
активный объект использует дефецитные ресурсы. Чтобы таких ситуаций не
возникало — нужна определенная изоляция, хотя бы такая как AppDomain'ы в
dotNET, а это тянет за собой длиныый список вопросов о маршаллинге,
сериализации и т.д.

И в итоге получится аналог .NET, только с гораздо более уродливым
языком, чем C# и кучей других недостатков (отсутствием стандарта
интероперабельности и т.п.).

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[26]: СИСТЕМНОСТЬ
От: serg_mo  
Дата: 14.02.05 16:28
Оценка: +3
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Ну сейчас я наподдам еще, не смогу отказать себе в таком удовольствии...


СГ>Вот что значит грамотный дизайн!!! А Вы все шаблоны да генерики, да не нужны они — головой надо думать...


Ну, если уж на то пошло, Лисп тут всех обошел:

Это было для меня большим открытием, я был тогда в аспирантуре, когда я понял, что пол листа кода, в верхней половине страницы 13 в руководстве по Lisp 1.5 был Lisp на самом себе.

(с) Alan Kay
... << RSDN@Home 1.1.3 stable >>
Re[22]: Системность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 19.01.05 07:11
Оценка: 27 (2)
Здравствуйте, Poudy, Вы писали:

P>Здравствуйте, Сергей Губанов, Вы писали:


P>>>Ты действительно уверен, что это из-за Оберона?

СГ>>Да.
P>Хотя это уже становится не смешно. Это уже становится интересно. Давай ты попробуешь привести немного другую аргументацию. Тогда, вероятно, когда ты в очередной раз повторишь "Oberon — системный язык", я скажу "Ааааа... Понял!" .


Ну что же, давайте.

Прочтите пожалуйста:
http://www.uni-vologda.ac.ru/oberon/infoart/proj0.htm

Потом вот это:
http://www.uni-vologda.ac.ru/oberon/infoart/fromm2o.htm

Все остальные ссылки там:
[[ http://www.uni-vologda.ac.ru/oberon/#Публикации%20на%20русском ]]
Re[25]: Системность
От: AVC Россия  
Дата: 19.01.05 12:32
Оценка: 7 (2)
Здравствуйте, WolfHound, Вы писали:

СГ>>...Компилятор для Oberon’а был реализован для процессоров семейства NS32000 и был встроен в операционную среду Oberon [GuW89]. Этот компилятор требует менее 50 Кбайт памяти, состоит из 6 модулей, общим размером около 4000 строк исходного текста и сам себя компилирует примерно за 15 секунд на рабочей станции с 25 МГц процессором типа NS32532...

СГ>>[/q]
WH>И? А что мешает на мощьной станции откомпилировать и оптимизировать по самые не балуйся программу, а потом залить ее в железку?

Я что-то не понял Вашего вопроса. В какую железку?
Oberon, о котором идет речь, — операционная система для рабочей станции Ceres.
Компилятор — часть этой операционной системы.
То, вся операционная система занимает 200K, из них 50K — компилятор, это достоинство дизайна системы.
Что Вы хотели сказать — осталось загадкой.

WH>ЗЫ Я не верю что в 4000 строк мог поместится оптимизирующий компилятор. А отсутствие оптимизации это как ни крути приговор.


Опять же, приговор — чему, кому?
Оберону, что ли? Так компиляторы Модулы-2 и Оберона-2 лучше оптимизируют код, чем компиляторы Си++. (Впрочем, это неудивительно. Причина названа в "красном драконе" Ахо, Ульмана и Сети. Почитайте.)
На днях скачал из интереса старую версию компилятора XDS (для некоммерческого использования). Прогнал drystone для MS Visual C++ и XDS Modula-2.
Результат: разница была даже не в процентах. XDS "покрыл" Visual в три раза. Возможно, надо было поизощреннее выставлять ключи оптимизации для Visual C++, но ему это все равно было бы что мертвому припарки.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[23]: Системность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 19.01.05 07:37
Оценка: 1 (1) -1
СГ>Ну что же, давайте.

цитата из статьи http://www.uni-vologda.ac.ru/oberon/infoart/fromm2o.htm

...Компилятор для Oberon’а был реализован для процессоров семейства NS32000 и был встроен в операционную среду Oberon [GuW89]. Этот компилятор требует менее 50 Кбайт памяти, состоит из 6 модулей, общим размером около 4000 строк исходного текста и сам себя компилирует примерно за 15 секунд на рабочей станции с 25 МГц процессором типа NS32532...

Re: Оберон vs все остальное!!! Действительно, фанатик...
От: Borisman2 Киргизия  
Дата: 23.01.05 07:32
Оценка: 1 (1) +1
Здравствуйте, Сергей Губанов

Однако, Ваше vs. все остальное звучит крайне фанатично.
Краткий ответ: На С/С++ ТАКОЕ писать невозможно и НЕ НАДО.

Полный ответ:На С/С++ ТАКОЕ писать НЕ НАДО, потому что C/C++ не являются строго типизированными функциональными языками, как скажем Hackell с его системой типов Х.-Милнера. В этом сила и слабость С/C++. Спросите программистов С, чем им нравится С? Они ответят — гибкий язык, можно делать многие вещи, доступные только ассемблеру. И вовсе незачем из них пытаться строить функциональные языки со строгой системой типов.

Каждый язык — это определенная культура, свой, самобытный взгляд на вещи. Система догм, если угодно. И не надо пытаться в эту систему догм втиснуть еретические веяния. Интересуют еретические веяния ? Выберите другой язык.

Ваш Оберон так же не является самым лучшим с любых позиций. Есть целая куча вещей (гляньте на тот же Лисп!), которые на Обероне сделать практически невозможно.

В институте программистам на первом курсе подробно объясняют, что НЕТ ЛУЧШЕГО ЯЗЫКА ПРОГРАММИРОВАНИЯ. Есть просто набор языков, каждый со своими плюсами и минусами, наша же работа — выбрать язык, наиболее хорошо подходящий под задачу. Лучшее, что можно сделать — это наладить СВЯЗИ, мосты между языками, как это стараются делать, например, в Perl (Inline module).

Ну сколько можно твердить прописные истины!
Re[4]: Оберон vs все остальное
От: Павел Кузнецов  
Дата: 12.01.05 22:16
Оценка: +2
jazzer,

> СГ>На Component Pascal это элементарно:

> СГ>
> СГ>TYPE
> СГ>  Action = PROCEDURE (a: Action): Action;
> СГ>


> Если не секрет, зачем это нужно? Какую задачу такая штука решает?


Построение конечного автомата, в котором действие возвращает следующее состояние. Предвосхищая продолжение: да, согласен, такое решние не облокотилось при наличии множества других вариантов, доступных в т.ч. и из C++.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[7]: Оберон vs все остальное
От: Кодёнок  
Дата: 13.01.05 11:09
Оценка: +2
СГ>Вот например, язык Си в некотором смысле есть подмножество языка Си++, а Oberon-1 в некотором смысле есть подмножество языка Component Pascal. Можно сказать, что языки Си и Оберон-1 довольно таки низкоуровневые — все что в них есть, грубо говоря, это просто голые процедуры. Поэтому они очень простые языки. Программы на этих языках используются во встроенных системах. Встроенные системы должны обходиться очень малым количеством ресурсов и, зачастую, не могут позволить себе такое расточительство как runtime system языка С++.

Какая там runtime system? RTTI редко когда включают, обработка исключений разве что и stack unwinding. Но вот тот же GC в разы более расточителен, обработку исключений тоже можно выключить, если STL не нужна.

СГ>безусловно является самым простым средством. Привлечение же тяжеловесного механизма ООП для той же самой задачи как раз и есть стрельба из пушки по воробъям.


Нет ничего тяжеловесного в (фактически) макросах. Проблема у встроенных систем не с требовательностью языка C++ (нет никакой особой требовательности у него вообще), а в трудности создания компилятора С++. А что касается ресурсов, то встроенные системы обычно легко позволяют себе Java, сбору мусора, и не жужжат

Короче, не надо оправдывать куцость синтаксиса Component Pascal его скоростью , и называть это достоинством. Если там не дай бог нет inline-функций или оптимизатор не сообразит, что в некоторых отдельных случаях приведенную тобой функцию Sum(Complex,Complex,out Complex) можно и подставить, то это еще больший удар по бедной встроенной системе
Re[13]: Оберон vs все остальное
От: Cyberax Марс  
Дата: 13.01.05 19:56
Оценка: +2
Сергей Губанов пишет:

> S> В общем, опять занимаемся изобретением однотипных велосипедов в

> разных ракурсах. Наличие в языке generic'ов запросто решает эту проблему.
> Э-э-э, а какую проблему?
> Написать три строчки кода:
>
> NEW(tmp, LEN(a) + 100);
> FOR i := 0 TO LEN(tmp)-1 DO tmp[i] := a[i] END;
> a := tmp;
>
> это что теперь проблемой называется????

Да, когда повторяется n раз (n>100)

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[10]: Оберон vs все остальное
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 14.01.05 08:08
Оценка: -1 :)
Здравствуйте, Кодёнок, Вы писали:

Кё>Число параметров и типы могут отличаться, короче — быть любыми. Что, будешь писать разные процедуры для каждой новой комбинации?


Кё>
Кё>PROCEDURE bind_void_void(IN A: PROCEDURE; ...): functor
Кё>PROCEDURE bind_void_int(IN A: PROCEDURE(a:integer); ...): functor
Кё>PROCEDURE bind_void_real(IN A: PROCEDURE(a:read...): functor
Кё>PROCEDURE bind_void_int_real(IN A: PROCEDURE(a:read...)
Кё>PROCEDURE bind_void_real_int(IN A: PROCEDURE(a:read...)
Кё>


Ах вот в чем дело. То есть термином "гибкость" здесь названо, то, что другие люди называют термином "грязный хак". Дело в том, что когда возникает необходимость определить процедуру принимающую произвольное количество аргументов различных типов, то это решается элементарнейшим способом:
TYPE
  Params = ABSTRACT RECORD END;

PROCEDURE Bind(VAR params: Params);


TYPE
  Params1 = RECORD (Params)
    (* Какие угодно параметры *)
  END;

PROCEDURE Bind1(VAR params: Params);
BEGIN
  WITH params: Params1 DO (* ... *) ELSE (* ... *) END
END Bind1;

TYPE
  Params2 = RECORD (Params)
    (* Какие угодно параметры *)
  END;

PROCEDURE Bind2(VAR params: Params);
BEGIN
  WITH params: Params2 DO (* ... *) ELSE (* ... *) END
END Bind2;
Re[18]: Системность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 14.01.05 12:49
Оценка: :))
Здравствуйте, Cyberax, Вы писали:

C>То есть железо должно быть спроектировано специально для Oberon'а?

C>Закатайте губы обратно — такого железа не будет.

Это для Си++ такого железа не было и не будет
Re[19]: Системность
От: Cyberax Марс  
Дата: 14.01.05 12:51
Оценка: +2
Сергей Губанов пишет:

> C>То есть железо должно быть спроектировано специально для Oberon'а?

> C>Закатайте губы обратно — такого железа не будет.
> Это для Си++ такого железа не было и не будет

А чего у меня передо мной стоит такое с монитором? Под С++ НЕ НУЖНО
проектировать железо.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[25]: СИСТЕМНОСТЬ
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 19.01.05 13:20
Оценка: :))
Здравствуйте, WolfHound, Вы писали:

WH>ЗЫ Я не верю что в 4000 строк мог поместится оптимизирующий компилятор.



О-о-о... Значит ЗАЦЕПИЛО наконец-то!!!!!!!!!!!

Ну сейчас я наподдам еще, не смогу отказать себе в таком удовольствии...

Компилятор Oberon for Aos (в Aos BlueBottle, та самая в которой минимальный системный вызов в 30 раз быстрее чем в Linux), так вот тот компилятор занимает 8'667 строчек.

Можно еще сравнить размеры исходных кодов операционных систем

For a native multiprocessor operating system, Aos is small, with a
kernel of 7,210 lines of source or about 50KB of object code. For comparison,
the 4.4BSD kernel (cf. 8.1.2) consists of 58,289 lines of C code
(excluding file systems, network protocols and device drivers, which
add another 143,962 lines) [65]. Version 2.4 of the Linux kernel consists
of approximately 420,000 lines of C code (excluding drivers, file systems
and architecture-specific code, which bring the total to 2.4 million
lines) [128], and has a minimum size of around 500KB on Intel processors.
Microsoft boasts that Windows 2000 “consists of over 29 million
lines of code”, but does not say what is included in this figure, so it is
not possible to compare specifics.

Aos subsystem sizes.

Subsystem         Var  Const    Code   Lines
Kernel          18088   1296   48434   7210
Service support   164   1620   30001   2532
File system        96   1928   55462   4624
User interface    128    792   20468   2204
Network          1512   3368   62126   6200
Oberon for Aos   2396   3332  112893   8667
Total           22384  12336  329384  31437

Цитата взята из докторской диссертации Питера Мюллера — создателя Aos (http://www.cs.inf.ethz.ch/~muller/).


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


Кстати сказать, компилятор языка Limbo написанный на языке Си занимает, если мне не изменяет память, очень много — целых 30'000 строчек.
Re[26]: СИСТЕМНОСТЬ
От: Cyberax Марс  
Дата: 19.01.05 13:27
Оценка: +2
Сергей Губанов пишет:

>

>Aos subsystem sizes.
>
>Subsystem Var Const Code Lines
>Kernel 18088 1296 48434 7210
>Service support 164 1620 30001 2532
>File system 96 1928 55462 4624
>User interface 128 792 20468 2204
>Network 1512 3368 62126 6200
>Oberon for Aos 2396 3332 112893 8667
>Total 22384 12336 329384 31437
>
> Цитата взята из докторской диссертации Питера Мюллера — создателя Aos
> (http://www.cs.inf.ethz.ch/~muller/
> <http://www.cs.inf.ethz.ch/%7Emuller/&gt;).
> Вот что значит грамотный дизайн!!! А Вы все шаблоны да генерики, да не
> нужны они — головой надо думать...

Если сравнивать с аналогичной системой — то нужно смотреть на QNX. Там в
микроядро в 20Кб вместилось управление процессами и защита памяти.
Причем системы на QNXе работают десятилетиями без перезагрузок — такой
он стабильный.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[2]: Оберон vs все остальное!!! Действительно, фанатик...
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 24.01.05 08:43
Оценка: :))
Здравствуйте, Borisman2, Вы писали:

B>Однако, Ваше vs. все остальное звучит крайне фанатично.

B>Ну сколько можно твердить прописные истины!

А я ТУ ветку форума не начинал и ТАКОЕ название не давал. Меня подставили!

Посмотрите на заметку внизу того сообщения:

21.01.05 11:51: Ветка выделена из темы Слабо? — AndrewVK

Re[3]: Оберон vs все остальное
От: AVC Россия  
Дата: 27.01.05 12:54
Оценка: :))
Здравствуйте, Трурль, Вы писали:

B>>1) Что будет, если я попытаюсь выстрелить себе в ногу при помощи кода вида:

B>>while(True) {
B>> list.append(1)
B>>}
B>>(ну или как это будет выглядеть на Оберон-2)

Т>А что будет, если пальнуть вот таким кодом?

Т>crazy.bat:
Т>
Т>loop:
Т>start crazy.bat
Т>goto loop
Т>


Поубывав бы!
Windows-95 умерла, не охнув.
К моему удивлению, Windows XP тоже не удалось вывести из состояния "грогги".
Она как-бы не умерла, но, из-за засилья модальных окошек, все остальные приложения (включая Task Manager) оказались недоступными.

Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

Хоар
Re[2]: MS, Windows и стратегический внедрёж ;-)
От: SilverCloud Россия http://rodonist.wordpress.com
Дата: 13.02.05 13:40
Оценка: +1 :)
Здравствуйте, Cyberax, Вы писали:

C>Истории про зависшие компы с WinCE в hi-end автомобилях все слышали?


Слышали. Вот только подробностей не было. Непонятно, что там у них зависло. Вы уверены, что это косяки Майкрософт?
Who needs information?
Re[11]: Оберон vs все остальное
От: Курилка Россия http://kirya.narod.ru/
Дата: 14.01.05 08:50
Оценка: 2 (1)
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Cyberax, Вы писали:


C>>Плевать, два потока, исполняющие один код я запустить уже не смогу.

C>>А контекст нужно передавать ВСЕГДА (в 99.99% случаев), иногда только
C>>можно для целей оптимизации использовать глобальные переменные.

СГ>А если система встроенная и там потоков нет?


Т.е. получаем, что оберон имеет всего лишь узкую нишу применения и не более того? Приведи-ка, плиз, реализации его в embedded systems, если не трудно, конечно...
(просто интересно )
Re[3]: Оберон vs С#
От: Silver_s Ниоткуда  
Дата: 21.01.05 17:02
Оценка: 1 (1)
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Не то же самое: второй вариант возвращает void, в то время как первый — значение своего же типа.


Ну ладно, сами напросились, пусть будет так


public delegate Action Action(Action md);
class Insane
{
    Action Action(Action act)
    {
        act(act);
        return act;
    }
    public void Call()
    {
        Action(new Action(Action));
    }
}


Все замечательно работает.
Вещь несомненно довольно полезная в хозяйстве.
Re[4]: Оберон vs все остальное
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.01.05 13:28
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

C>Сергей Губанов пишет:


>> J> и еще отсутствие разделения на процедуры и функции

>> Загадка. Слабо на Си или Си++ написать тип функции принимающей в
>> качестве аргумента и возвращающей переменную ее собственного типа?
>> На Component Pascal это элементарно:

C> Да пожалуйста, правда будет не функция, а функтор


Класс объекты которого имеют метод принимающий в качестве аргумента и возвращающий указатели на объекты этого класса интереса для меня не представляет.

Я хочу тип обычной функции.

TYPE
  Action = PROCEDURE (a: Action) : Action;


PROCEDURE^ g(a: Action): Action; (* forward declaration *)

PROCEDURE f(a: Action): Action;
BEGIN
  (* ... *)
  IF a # NIL THEN RETURN a ELSE RETURN g END
END f;

PROCEDURE g(a: Action): Action;
BEGIN
  (* ... *)
  IF a # NIL THEN RETURN a ELSE RETURN f END
END g;
Re[5]: Оберон vs все остальное
От: Кодёнок  
Дата: 13.01.05 04:59
Оценка: +1
Кё>>Загадка 1. Как на Component Pascal реализуется ну простейшая задача — одномерный динамический массив (список) объектов? Интересует как синтаксически, так и по скорости. Типа vector<CMyType>.

СГ>ARRAY OF CMyType

СГ>POINTER TO ARRAY OF CMyType
СГ>PROCEDURE Init(VAR a: ARRAY OF CMyType);
СГ>VAR i: INTEGER;
СГ>BEGIN
СГ> FOR i := 0 TO LEN(a)-1 DO
СГ> a[i] := ....
СГ> END
СГ>END Init

Я немного не об этом. Динамические массивы в паскале — не новость для меня Я имел ввиду:

1. Вызов деструкторов при очищении массива, или перезаписывании одного элемента другим, или — если классы содержат такие указатели, что не могут быть просто так побитово скопированы — правильное копирование при реаллоке памяти, сдвигах при вставке и удалении.
2. Вставка и удаление элементов.
3. list<CMyType> — список объектов
4. map<string,CMyType>, hash_map — словарь

Кё>>Загадка 2. Как на нем же реализуется собственный тип, который по поведению аналогичен простому типу. Пример: Math.Complex, DateTime. Как синтаксически будет выглядеть работа с этим типом?


СГ>PROCEDURE Sum(IN a,b: Complex; OUT c: Complex);

СГ>BEGIN
СГ> c.re := a.re + b.re; c.im := a.im + b.im
СГ>END Sum;

Вот именно. Только вычисляемое надо в возвращаемое значение: [pascal]procedure Sum(a,b:Complex): Complex[pascal]. И выглядеть это будет что-то вроде DateTimeIsGreater(DateTimeDiff(a, b), DateTimeDiff(c, d)) вместо a — b > c — d

Кё>>Загадка 3. Как часто мне приходилось решать твою загадку на пракике?


СГ>Наверное Вы ее встретили в первый раз здесь. Ранее она просто в голову не могла придти. Язык ограничивает мышление.


В конечном автомате Action наверняка будет объектом. Не только выполняемым, но и наверняка со свойствами/данными.

Хотя — пожалуйста. Может так понравится?

#include <iostream>
using namespace std;

struct Action;

typedef Action (* ActionFunc)(const Action& action);

struct Action
{
    ActionFunc actionFunc_;
    Action(ActionFunc f) : actionFunc_(f) { }
    // action_proc(const action_proc& p);
    // ...
    //
    operator ActionFunc () const { return actionFunc_; }
    operator bool () const { return actionFunc_ != 0; }
    Action operator ()(const Action& a) const { return actionFunc_(a); }
};

Action g(const Action&);

Action f(const Action& a)
{
    // ...
    cout << "f()" << endl;
    if (a) a(0);
    return a ? a : g;
}

Action g(const Action& a)
{
    // ...
    cout << "g()" << endl;
    if (a) a(0);
    return a ? a : f;
}

void main()
{
    f(g);
}


Если только не капризничать "хочу чисто функцию и все тут", то это 100% аналогично приведенному тобой коду на паскале.
Re[6]: Оберон vs все остальное
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 13.01.05 10:37
Оценка: :)
Здравствуйте, Кодёнок, Вы писали:

Кё>1. Вызов деструкторов при очищении массива, или перезаписывании одного элемента другим, или — если классы содержат такие указатели, что не могут быть просто так побитово скопированы — правильное копирование при реаллоке памяти, сдвигах при вставке и удалении.


Язык Component Pascal предполагает наличие сборщика мусора, то есть никаких деструкторов не бывает, у динамического объекта вместо деструктора есть метод FINALIZE-, который может вызвать только GC.

Кё>2. Вставка и удаление элементов.

Кё>3. list<CMyType> — список объектов
Кё>4. map<string,CMyType>, hash_map — словарь

Это все пишется врукопашную. для каждого конкретного типа отдельно. Впрочем можно написать это для какого-нибудь базового типа (например, для ANYPTR), а потом использовать эти же контейнеры для объектов типы которых есть расширения того базового типа (потомки) — использовать динамическое приведение типов.

Кё> Если только не капризничать "хочу чисто функцию и все тут", то это 100% аналогично приведенному тобой коду на паскале.


А я может капризный такой, вот не хочу тяжеловесное и громоздкое ООП, а хочу самую что ни на есть пересамую завалящуюся обыкновенную функцию...
Re[8]: Оберон vs все остальное
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 13.01.05 14:41
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

C>Да, а почему сам используешь при этом возможности Object Pascal'я, а не

C>обычный Pascal?

Я не понял Ваш вопрос. Вообще-то я тут говорил про Component Pascal от Никлауса Вирта. При чем тут борландовские поделки ума не приложу...

C>а покажи на Паскале аналог вот этого:

C>========================================
C>class Something : public virtual boost::signals::trackable
C>{
C>public:
C> void processMessage(std::vector<int> some1, double some2)
C> {
C> ....
C> }
C>};
C>...
C>boost::signal<void(std::vector<int>, double)> sig;
C>Something s1=new Something();
C>Something s2=new Something();
C>...

C>sig.connect(boost::bind(&Something::processMessage,s1,_1,_2));

C>sig.connect(boost::bind(&Something::processMessage,s2,_1,_2));
C>sig(param1,param2);
C>delete s1;
C>sig(param1,param2);
C>delete s2;
C>========================================


Да, загадали загадку так загадали, ну какой вопрос — такой и ответ, смотрите:
TYPE
    Something = POINTER TO RECORD (Signals.Trackable) END;

PROCEDURE ProcessMessage (this: Something; IN some1: ARRAY OF INTEGER; some2: REAL);
BEGIN
    (* ... *)
END ProcessMessage;


...

VAR sig: Signal; s1, s2: Something;
BEGIN
    NEW(s1); NEW(s2);
    sig.Connect(bind(ProcessMessage, s1, _1, _2));
    sig.Connect(bind(ProcessMessage, s2, _1, _2));    
    sig(param1, param2);
    s1 := NIL;
    sig(param1, param2);    
    s2 := NIL;
Re[10]: Оберон vs все остальное
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 13.01.05 15:50
Оценка: :)
Здравствуйте, Кодёнок, Вы писали:


Кё>>>OK, аналогично C#. Но как копирование? Как массив копирует объекты при прераспределении памяти — всегда побитово?


СГ>>Что значит перераспределение памяти?


Кё>Добавление еще 100 элементов, когда для них нет размера.


Куда добавляем-то, массив же уже создан...

Нужно вручную создать совершенно другой новый массив, который на 100 элементов длиннее, и вручную скопировать в него то что хотите. О старом массиве забыть.
NEW(tmp, LEN(a) + 100);
FOR i := 0 TO LEN(tmp)-1 DO tmp[i] := a[i] END;
a := tmp;
Re[14]: Оберон vs все остальное
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 14.01.05 07:54
Оценка: -1
Здравствуйте, Кодёнок, Вы писали:

Кё> Да нет, проблема — это вылавливать в коде на 25000 строк LEN(tmp) вместо LEN(tmp)-1, написанные по привычке tmp[i] := a[i] вместо DeepCopy(tmp[i], a[i]). Причем в разных случая циклы могут чуть-чуть отличаться, как в случае с DeepCopy, например, так что процедурой не отмажешься, и придется в каждый кусок кода вникать. Тут — копирование, там — вставка, там — сдвиг, там — элементы ссылаются на индексы друг друга в этом массиве. Через неделю ты забудешь, что эта программа делает


Да ладно Вам фантазировать, ничего вылавливать не надо, все пишется в 1 экземпляре в одном модуле.
Re[11]: Оберон vs все остальное
От: Cyberax Марс  
Дата: 14.01.05 08:49
Оценка: +1
Сергей Губанов пишет:

> C>Плевать, два потока, исполняющие один код я запустить уже не смогу.

> C>А контекст нужно передавать ВСЕГДА (в 99.99% случаев), иногда только
> C>можно для целей оптимизации использовать глобальные переменные.
> А если система встроенная и там потоков нет?

Тогда там нечего делать GC, и код следует писать на С/Asm. Кроме того,
проблема реентерабельности никуда не исчезает и без потоков (что будет,
если я захочу два конечных автомата, вызывающих друг друга?).

Кстати, на С такая функция будет выглядеть так:
=========
void* func(void* someFunc)
{
return someFunc;
}

...
void funcPtr=func(&func);
assert(funcPtr==&func);
=========
Хотя нетипобезопасно получается, но во встроенных системах (если уж о
них разговор) это обычно не так важно.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[14]: Оберон vs все остальное
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 14.01.05 08:56
Оценка: :)
Здравствуйте, Курилка, Вы писали:


К>Берём ситуацию, что в with ты забудешь один из типов по запарке, бывает такое, ну и оберон твой нихрена не скажет, всё будет ништяк, но работать-то будет в итоге прога не правильно.



If no type test is satisfied and if an ELSE clause is missing the program is aborted.
Re[14]: Системность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 14.01.05 10:23
Оценка: :)
Здравствуйте, Кодёнок, Вы писали:

Кё> ...объяснение, какова принципиальная проблема в использовании другого языка? Java например.


Причина просто в том что Oberon — системный язык, в то время как Java или С# таковыми не являются.

Просто посмотрим на типы данных:

RECORD — запись в памяти, переменная размещается статически на стеке (аналог struct в C#, Java — просто отдыхает)

EXTENSIBLE RECORD, ABSTRACT RECORD — тоже самое, но с возможностью расширения типа (C# + Java отдыхают вместе, в Java нет статики, а в C# нет наследования от value type)

POINTER TO RECORD, POINTER TO EXTENSIBLE RECORD, POINTER TO ABSTRACT RECORD — в C# и Java этому эквивалентны sealed class, class и в некотором смысле interface, хотя ABSTRACT RECORD может иметь данные, в то время как интерфейс может иметь только методы.

ARRAY Dim1, Dim2, Dim3,... OF SomeType — многомерный массив чего-то, который размещается на стеке (C# + Java отдыхают вместе — там массивов на стеке не бывает)

POINTER TO ARRAY Dim1, Dim2, Dim3,... OF SomeType тот же массив только в динамической памяти

POINTER TO ARRAY OF SomeType динамический массив — только такие есть в Java и C#.


Передача параметров по ссылке (VAR, IN, OUT), например, процедуре

PROCEDURE f(VAR points: ARRAY OF REAL);

можно передать:
p1: ARRAY N OF REAL; (* статический массив *)
p2: POINTER TO ARRAY OF REAL; (* динамический массив *)
VAR|IN|OUT p3: ARRAY OF REAL; (* ссылка на массив полученная как входной параметр в объемлющей процедуре. Например для рекурсии, когда f(points) вызывает себя передавая points — полученный ею самой на предыдущем шаге рекурсии *)


Короче говоря, в языках Java и C# просто нету возможности создавать системно необходимые типы данных.
Re[16]: Системность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 14.01.05 10:43
Оценка: :)
Здравствуйте, Кодёнок, Вы писали:

Кё> А почему тогда не C++?


А потому что:

1) Полное исчерпывающее описание Оберона занимает 16-30 страниц (в зависимости от шрифта), а полное исчерпывающее описание С++ занимает несколько сотен страниц. Проблема обучения.

2) Сколько ресурсов надо затратить чтобы написать новый правильно работающий компилятор С++ под новый тип чипа просто не сопоставимо с той же работой для Оберона. В ETH портирование Оберона на новый тип чипа делают студенты за месяц.

3) Сопровождение кода на С++ эффективно может делать только автор этого кода, любой другой программист лучше заново по своему напишет чем разбереться с уже написанным.

4) С++ — unsafe, Оберон — safe (работа с адресной арифметикой, если таковая необходима, в Обероне осуществляется через внешние библиотеки).
Re[17]: Оберон vs все остальное
От: Cyberax Марс  
Дата: 14.01.05 10:44
Оценка: +1
Сергей Губанов пишет:

> К>А какже сказанное тобою тут про встроенные системы и отсутствие

> потоков? Как это с универсальностью соотносится?
> Так ведь в Си/Си++ многопоточность тоже появляется только через
> внешние библиотеки.

Так ведь в языке С++ есть все средства, чтобы многопоточность можно было
сделать библиотеками (кстати, а в Oberon'е есть volatile?). В этом-то и
суть С++ — к нему с помощью библиотек почти все можно подключить.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[17]: Системность
От: Cyberax Марс  
Дата: 14.01.05 11:06
Оценка: +1
tarkil пишет:

> C>Системный язык — это С, с натяжкой, С++.

> А почему С++ — с натяжкой?

Слишком высокоуровневый для системного программирования в некоторых
случаях (RTTI, исключения). Хотя достоинство С++ в том, что
высокоуровневые фичи можно и не использовать.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[24]: Системность
От: Privalov  
Дата: 19.01.05 12:21
Оценка: -1
Здравствуйте, Сергей Губанов, Вы писали:

СГ>>Ну что же, давайте.


СГ>цитата из статьи http://www.uni-vologda.ac.ru/oberon/infoart/fromm2o.htm

СГ>

СГ>...Компилятор для Oberon’а был реализован для процессоров семейства NS32000 и был встроен в операционную среду Oberon [GuW89]. Этот компилятор требует менее 50 Кбайт памяти, состоит из 6 модулей, общим размером около 4000 строк исходного текста и сам себя компилирует примерно за 15 секунд на рабочей станции с 25 МГц процессором типа NS32532...


И что? Сколько времени и сил отнимает разработка приложений, если в распоряжении разработчика есть только голый компилятор, даже если он так мал? Этот вопрос уже обсуждался не раз. Не вижу смысла к нему возвращаться. Скажу только, что компилятор — только составная часть системы программирования.

Если следовать по пути авторов тех статей, то надо выбросить миллионы строк реально работающих программ и перейти к "правильному программированию". Но реалии таковы, что никто этого не позволит.

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

Вирт стоит выше всего этого, он уже может позволить себе фантазировать.
Re[20]: Системность
От: Privalov  
Дата: 19.01.05 12:23
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>А чего у меня передо мной стоит такое с монитором? Под С++ НЕ НУЖНО

C>проектировать железо.

И, кстати, под еще целую массу языков тоже не нужно.
Re[5]: Оберон vs все остальное
От: _Obelisk_ Россия http://www.ibm.com
Дата: 21.01.05 13:17
Оценка: +1
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>jazzer,


>> СГ>На Component Pascal это элементарно:

>> СГ>
>> СГ>TYPE
>> СГ>  Action = PROCEDURE (a: Action): Action;
>> СГ>


>> Если не секрет, зачем это нужно? Какую задачу такая штука решает?


ПК>Построение конечного автомата, в котором действие возвращает следующее состояние. Предвосхищая продолжение: да, согласен, такое решние не облокотилось при наличии множества других вариантов, доступных в т.ч. и из C++.


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



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[28]: СИСТЕМНОСТЬ
От: Курилка Россия http://kirya.narod.ru/
Дата: 21.01.05 14:30
Оценка: :)
Здравствуйте, Сергей Губанов, Вы писали:

СГ>3D игры надо под нее писать. Все будет просто летать.


Со стола в окно
Re[11]: Оберон vs все остальное
От: Sergey__ Россия  
Дата: 24.01.05 15:38
Оценка: +1
Здравствуйте, Сергей Губанов, Вы писали:

СГ> а есть люди оставшиеся на Delphi 6 (поскольку в семерке для них ничего нового не было а QReports был заменен на Rave)

вообще-то
для тех кто ищет это чудо — QReports (это при том что есть FastReport и AfalinaSoft XL Report)
в Delphi 7 и никак не может его найти :
достаточно в папочке с замаскированным названием Delphi7\Demos\Quickrpt
открыть файл QReport_README.txt
и прочесть ... что QReports по-прежнему с нами !!!
Sergey
Re[3]: Оберон vs все остальное
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 28.01.05 14:15
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

C>Вроде который раз пытаемся уже сказать, что НЕ ПОЛУЧИТСЯ просто так удалить "активный объект". Это приведет к куче проблем, так как на удаленный объект могут ссылаться другие активные объекты, или если активный объект использует дефецитные ресурсы. Чтобы таких ситуаций не возникало — нужна определенная изоляция, хотя бы такая как AppDomain'ы в dotNET, а это тянет за собой длиныый список вопросов о маршаллинге, сериализации и т.д.


Среда .NET запускается отдельно для каждого процесса (именно поэтому каждая запущенная .NET программа захватывает очень много памяти). Таким образом внутри каждой .NET системы процессов вообще нет (процесс — это она сама) там есть только потоки. Вот если бы .NET была одна единственная на все процессы — вот другое дело.

Вы сами возьмите и попробуйте в .NET программе удалить поток. Далее цитирую Вас же: Это приведет к куче проблем, так как на этот поток могут ссылаться другие потоки, или если поток использует дефецитные ресурсы....

C>И в итоге получится аналог .NET


Наоборот, это .NET есть аналог Оберон систем, разрабатываемых с 1985 года.
Re[4]: Оберон vs все остальное
От: Сантехник Беларусь  
Дата: 07.02.05 15:26
Оценка: :)
Здравствуйте, Трурль, Вы писали:

Т>Трудно проидумать что-либо более уродливое, чем C#.


Объясни, если не трудно, что именно тебе в нем кажется уродливым.
... << RSDN@Home 1.1.4 beta 3 rev. 264>>
Re[3]: MS, Windows и стратегический внедрёж ;-)
От: Cyberax Марс  
Дата: 14.02.05 05:18
Оценка: :)
SilverCloud пишет:

> C>Истории про зависшие компы с WinCE в hi-end автомобилях все слышали?

> Слышали. Вот только подробностей не было. Непонятно, что там у них
> зависло. Вы уверены, что это косяки Майкрософт?

Нет, но сам факт того, что МС притягивает к себе такие проблемы (типа
японского премьера, которого компьютер наглухо закрыл в автомобиле) —
весьма интересен.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[7]: Оберон vs все остальное
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 17.02.05 11:14
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, mister-AK, Вы писали:


MA>>навскидку:

MA>>1. приведение типов по колличеству написания скобочек проигрывает делфям в 1,5 раза
S>Оччень интересно.
S>
S>(int)i 
S>

S>супротив
S>
S>int(i)
S>

S>Может, у меня проблемы с устным счетом?
  ((MyClass) obj).xxx


супротив

       MyClass(obj).xxx


Согласенн нужно тебе немного подучить арифметику
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[16]: Оберон vs все остальное
От: XopoSHiy Россия http://cleancodegame.github.io/
Дата: 21.02.05 12:05
Оценка: +1
Здравствуйте, Кодёнок, Вы писали:


СГ>>Да ладно Вам фантазировать, ничего вылавливать не надо, все пишется в 1 экземпляре в одном модуле.


Кё>Это опыт работы с Дельфи...


У плохого танцора всегда Дельфи виновата
В Дельфи есть стандартные контейнеры. Даже если бы и не было, можно было бы написать.
Точно также как и в обероне, я уверен, можно написать набор стандартных контейнеров о которых вы молвите.
Отсутствие generic-ов в Языке причиняет некоторые неудобства — это факт, но и без них можно достаточно легко обходится стандартными контейнерами.
---
http://twitter.com/xoposhiy
http://xoposhiy.moikrug.ru
Re[3]: Оберон vs все остальное
От: Cyberax Марс  
Дата: 12.01.05 12:27
Оценка:
Сергей Губанов пишет:

> J> и еще отсутствие разделения на процедуры и функции

> Загадка. Слабо на Си или Си++ написать тип функции принимающей в
> качестве аргумента и возвращающей переменную ее собственного типа?
> На Component Pascal это элементарно:

Да пожалуйста, правда будет не функция, а функтор:
============================
struct ReccuringFunctor
{
ReccuringFunctor* operator()(ReccuringFunctor* some)
{
return some;
}
};
ReccuringFunctor weirdFunc;
ReccuringFunctor *weirdFuncPtr;

//Вызов
weirdFuncPtr=weirdFunc(&weirdFunc);
assert(weirdFuncPtr==&weirdFunc);
============================

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[5]: Оберон vs все остальное
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 12.01.05 13:50
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

Кё>>Загадка 1. Как на Component Pascal реализуется ну простейшая задача — одномерный динамический массив (список) объектов? Интересует как синтаксически, так и по скорости. Типа vector<CMyType>.


СГ>
СГ>ARRAY OF CMyType

СГ>POINTER TO ARRAY OF CMyType
СГ>


простите, забыл привести код использования


PROCEDURE Init(VAR a: ARRAY OF CMyType); 
VAR i: INTEGER;
BEGIN
  FOR i := 0 TO LEN(a)-1 DO 
    a[i] := ....
  END
END Init


VAR 
  dynam: POINTER TO ARRAY OF CMyType;  (* Размещается в динамической памяти *)
  stat : ARRAY 512 OF CMyType;         (* Размещается на стеке              *)
BEGIN
  NEW(dynam, 10); (* Создали массив из 10 элементов *)
  Init(dynam);
  Init(stat);
Re[3]: Оберон vs все остальное
От: jazzer Россия Skype: enerjazzer
Дата: 12.01.05 20:45
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, jazzer, Вы писали:


J>> и еще отсутствие разделения на процедуры и функции


СГ>Загадка. Слабо на Си или Си++ написать тип функции принимающей в качестве аргумента и возвращающей переменную ее собственного типа?


СГ>На Component Pascal это элементарно:

СГ>
СГ>TYPE
СГ>  Action = PROCEDURE (a: Action): Action;
СГ>


Если не секрет, зачем это нужно? Какую задачу такая штука решает?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[5]: Оберон vs все остальное
От: jazzer Россия Skype: enerjazzer
Дата: 12.01.05 20:46
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Cyberax, Вы писали:


C>>Сергей Губанов пишет:


>>> J> и еще отсутствие разделения на процедуры и функции

>>> Загадка. Слабо на Си или Си++ написать тип функции принимающей в
>>> качестве аргумента и возвращающей переменную ее собственного типа?
>>> На Component Pascal это элементарно:

C>> Да пожалуйста, правда будет не функция, а функтор


СГ>Класс объекты которого имеют метод принимающий в качестве аргумента и возвращающий указатели на объекты этого класса интереса для меня не представляет.


СГ>Я хочу тип обычной функции.


почему?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[6]: Оберон vs все остальное
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 13.01.05 10:49
Оценка:
Здравствуйте, jazzer, Вы писали:

СГ>>Я хочу тип обычной функции.


J>почему?


Вот например, язык Си в некотором смысле есть подмножество языка Си++, а Oberon-1 в некотором смысле есть подмножество языка Component Pascal. Можно сказать, что языки Си и Оберон-1 довольно таки низкоуровневые — все что в них есть, грубо говоря, это просто голые процедуры. Поэтому они очень простые языки. Программы на этих языках используются во встроенных системах. Встроенные системы должны обходиться очень малым количеством ресурсов и, зачастую, не могут позволить себе такое расточительство как runtime system языка С++.

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


Тип:
TYPE
  A = PROCEDURE(a: A): A;

безусловно является самым простым средством. Привлечение же тяжеловесного механизма ООП для той же самой задачи как раз и есть стрельба из пушки по воробъям.
Re[7]: Оберон vs все остальное
От: Кодёнок  
Дата: 13.01.05 10:53
Оценка:
СГ>Язык Component Pascal предполагает наличие сборщика мусора, то есть никаких деструкторов не бывает, у динамического объекта вместо деструктора есть метод FINALIZE-, который может вызвать только GC.

OK, аналогично C#. Но как копирование? Как массив копирует объекты при прераспределении памяти — всегда побитово?

Кё>>2. Вставка и удаление элементов.

Кё>>3. list<CMyType> — список объектов
Кё>>4. map<string,CMyType>, hash_map — словарь

СГ>Это все пишется врукопашную. для каждого конкретного типа отдельно. Впрочем можно написать это для какого-нибудь базового типа (например, для ANYPTR), а потом использовать эти же контейнеры для объектов типы которых есть расширения того базового типа (потомки) — использовать динамическое приведение типов.


Ну вот, а сказал — не хочешь тяжеловесное и громоздкое ООП. Вот тебе и громоздкость, и ООП, и синтаксическая некрасивость.

Кё>> Если только не капризничать "хочу чисто функцию и все тут", то это 100% аналогично приведенному тобой коду на паскале.


СГ>А я может капризный такой, вот не хочу тяжеловесное и громоздкое ООП, а хочу самую что ни на есть пересамую завалящуюся обыкновенную функцию...


То, что тебе привели, абсолютно ничего тяжеловесного и громоздкого не содержит. Равно как и ООП. Просто считай, Action — пользовательский тип, размером с указатель на функцию, к которому добавлены специальные инструкции компилятору — как его вызывать (как и указатель на ф-ю), как проверять на ноль, и т.д. Все это inline-функции, которые оптимизируются в простейшие инструкции, почти полностью идентичные работе с указателем на функцию.
Re[7]: Оберон vs все остальное
От: Cyberax Марс  
Дата: 13.01.05 11:11
Оценка:
Сергей Губанов пишет:

> СГ>>Я хочу *тип обычной функции*.

> J>почему?
> Вот например, язык Си в некотором смысле есть подмножество языка Си++,
> а Oberon-1 в некотором смысле есть подмножество языка Component
> Pascal. Можно сказать, что языки Си и Оберон-1 довольно таки
> низкоуровневые — все что в них есть, грубо говоря, это просто голые
> процедуры. Поэтому они очень простые языки. Программы на этих языках
> используются во встроенных системах. Встроенные системы должны
> обходиться очень малым количеством ресурсов и, зачастую, не могут
> позволить себе такое расточительство как runtime system языка С++.

Runtime для С++ может быть очень небольшим...

> Я хочу самую обычную переобычную самую завалящуюся функцию потому, что

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

Да, а почему сам используешь при этом возможности Object Pascal'я, а не
обычный Pascal? Тем более, что функторы — это вовсе не "пушка". Кстати,
а покажи на Паскале аналог вот этого:
========================================
class Something : public virtual boost::signals::trackable
{
public:
void processMessage(std::vector<int> some1, double some2)
{
....
}
};
...
boost::signal<void(std::vector<int>, double)> sig;
Something s1=new Something();
Something s2=new Something();
...

sig.connect(boost::bind(&Something::processMessage,s1,_1,_2));
sig.connect(boost::bind(&Something::processMessage,s2,_1,_2));
sig(param1,param2);
delete s1;
sig(param1,param2);
delete s2;
========================================

>

> Тип:
>
>TYPE
> A = PROCEDURE(a: A): A;
>
>
> безусловно является самым простым средством. Привлечение же
> тяжеловесного механизма ООП для той же самой задачи как раз и есть
> стрельба из пушки по воробъям.

Почему "механизм ООП" тяжеловесен? Кстати, а как твоим функциям
передавать КОНТЕКСТ вычислений? Или как обычно, через глобальные переменные?

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[7]: Оберон vs все остальное
От: jazzer Россия Skype: enerjazzer
Дата: 13.01.05 11:25
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, jazzer, Вы писали:


СГ>>>Я хочу тип обычной функции.


J>>почему?


СГ>Вот например, язык Си в некотором смысле есть подмножество языка Си++, а Oberon-1 в некотором смысле есть подмножество языка Component Pascal. Можно сказать, что языки Си и Оберон-1 довольно таки низкоуровневые — все что в них есть, грубо говоря, это просто голые процедуры. Поэтому они очень простые языки. Программы на этих языках используются во встроенных системах. Встроенные системы должны обходиться очень малым количеством ресурсов и, зачастую, не могут позволить себе такое расточительство как runtime system языка С++.


А можно с этого места подробнее?
Как-то я не испытываю проблем при написании программ на С++ для КПК, и никакогорасточительного рантайма С++ не замечал — в С++ ведь нету никакой постулированной модульности и обязательной сборки мусора и т.д. и т.п..

СГ>Я хочу самую обычную переобычную самую завалящуюся функцию потому, что не гоже стрелять из пушки по воробъям, во всех случаях где только возможно нужно использовать самые простые средства.


class в С++ самое простое средство. В смысле, не сложнее, чем функция.

СГ>Тип:

СГ>
СГ>TYPE
СГ>  A = PROCEDURE(a: A): A;
СГ>

СГ>безусловно является самым простым средством. Привлечение же тяжеловесного механизма ООП для той же самой задачи как раз и есть стрельба из пушки по воробъям.

мой ответ — в ответе на твой ответ Кодёнку :)
В двух словах — в С++ механизм ООП не тяжеловесен, поэтому в С++ ты можешь выбрать то, что удобнее — эффективность не изменится.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[8]: Оберон vs все остальное
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 13.01.05 14:18
Оценка:
Здравствуйте, Кодёнок, Вы писали:


Кё>OK, аналогично C#. Но как копирование? Как массив копирует объекты при прераспределении памяти — всегда побитово?


Что значит перераспределение памяти?
Re[9]: Оберон vs все остальное
От: Кодёнок  
Дата: 13.01.05 14:27
Оценка:
Кё>>OK, аналогично C#. Но как копирование? Как массив копирует объекты при прераспределении памяти — всегда побитово?

СГ>Что значит перераспределение памяти?


Добавление еще 100 элементов, когда для них нет размера.
Re[9]: Оберон vs все остальное
От: Cyberax Марс  
Дата: 13.01.05 15:10
Оценка:
Сергей Губанов пишет:

> C>Да, а почему сам используешь при этом возможности Object Pascal'я, а не

> C>обычный Pascal?
> Я не понял Ваш вопрос. Вообще-то я тут говорил про Component Pascal от
> Никлауса Вирта. При чем тут борландовские поделки ума не приложу...

Ошибся, как раз Component Pascal и имел в виду...

> C>а покажи на Паскале аналог вот этого:

> C>========================================
> C>class Something : public virtual boost::signals::trackable
> C>{
> C>public:
> C> void processMessage(std::vector<int> some1, double some2)
> C> {
> C> ....
> C> }
> C>};
> C>...
> C>boost::signal<void(std::vector<int>, double)> sig;
> C>Something s1=new Something();
> C>Something s2=new Something();
> C>...
>
> C>sig.connect(boost::bind(&Something::processMessage,s1,_1,_2));
> C>sig.connect(boost::bind(&Something::processMessage,s2,_1,_2));
> C>sig(param1,param2);
> C>delete s1;
> C>sig(param1,param2);
> C>delete s2;
> C>========================================
>
> Да, загадали загадку так загадали, ну какой вопрос — такой и ответ,
> смотрите:
>
>TYPE
> Something = POINTER TO RECORD (Signals.Trackable) END;
>
>PROCEDURE ProcessMessage (this: Something; IN some1: ARRAY OF INTEGER; some2: REAL);
>BEGIN
> (* ... *)
>END ProcessMessage;
>
>
>...
>
>VAR sig: Signal; s1, s2: Something;
>BEGIN
> NEW(s1); NEW(s2);
> sig.Connect(bind(ProcessMessage, s1, _1, _2));
> sig.Connect(bind(ProcessMessage, s2, _1, _2));
> sig(param1, param2);
> s1 := NIL;
> sig(param1, param2);
> s2 := NIL;
>
>
Э, нет. Во-первых, в моем примере Something это объект, причем он
автоматически отключается от сигнала при уничтожении. Далее, с помощью
boost::bind'а я создаю функтор-адаптер, который позволяет мне подключить
к сигналу обработчик с другой сигнатурой функционального оператора.
Можно еще усложнить пример:
==============
class Something : public virtual boost::signals::trackable
{
public:
void processMessage(std::vector<int> some1, double some2, int
THIRD_PARAMETER)
{
....
}
};
...
boost::signal<void(std::vector<int>, double)> sig;
Something s1=new Something();
Something s2=new Something();
...

sig.connect(boost::bind(&Something::processMessage,s1,_1,_2,111111));
sig.connect(boost::bind(&Something::processMessage,s2,_1,_2,222222));
sig(param1,param2);
delete s1;
sig(param1,param2);
delete s2;
==============
Причем все типы проверяются на этапе компиляции, поэтому такой код:
sig.connect(boost::bind(&Something::processMessage,s2,_1,));
просто не скомпилится.

Такой гибкости Паскалю и близко не снилось.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[11]: Оберон vs все остальное
От: Schade Россия  
Дата: 13.01.05 16:27
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Куда добавляем-то, массив же уже создан...

СГ>Нужно вручную создать совершенно другой новый массив, который на 100 элементов длиннее, и вручную скопировать в него то что хотите. О старом массиве забыть.

В общем, опять занимаемся изобретением однотипных велосипедов в разных ракурсах. Наличие в языке generic'ов запросто решает эту проблему. Или в "настоящих модульных компонентных ... etc. системах" это не нужно, лишено смысла? Может, все-таки никому не нужны такие вот системы?

З.Ы. Я уж надеялся, что флейм об Обероне ушел в прошлое. Зачем же паутину с него смахивать?
... << RSDN@Home 1.1.4 @@subversion >>
Re[12]: Оберон vs все остальное
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 13.01.05 19:51
Оценка:
Здравствуйте, Schade, Вы писали:

S> В общем, опять занимаемся изобретением однотипных велосипедов в разных ракурсах. Наличие в языке generic'ов запросто решает эту проблему.


Э-э-э, а какую проблему?

Написать три строчки кода:
  NEW(tmp, LEN(a) + 100);
  FOR i := 0 TO LEN(tmp)-1 DO tmp[i] := a[i] END;
  a := tmp;

это что теперь проблемой называется????

А я то думал, что проблема, это, например, придумать хорошую эвристику для NP-задачи...
Re[9]: Оберон vs все остальное
От: Кодёнок  
Дата: 14.01.05 05:32
Оценка:
СГ>Да, загадали загадку так загадали, ну какой вопрос — такой и ответ, смотрите:

Мимо Пропущена реализация Signal и функтора, которая собственно и интересует. Вспоминая GC в C# — тут обязательно придется привлечь WeakReferences.

СГ> sig.Connect(bind(ProcessMessage, s1, _1, _2));


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

PROCEDURE bind_void_void(IN A: PROCEDURE; ...): functor
PROCEDURE bind_void_int(IN A: PROCEDURE(a:integer); ...): functor
PROCEDURE bind_void_real(IN A: PROCEDURE(a:read...): functor
PROCEDURE bind_void_int_real(IN A: PROCEDURE(a:read...)
PROCEDURE bind_void_real_int(IN A: PROCEDURE(a:read...)

Главное запастись травой на год!

СГ> sig.Connect(bind(ProcessMessage, s2, _1, _2));

СГ> sig(param1, param2);
СГ> s1 := NIL;

А вот это не приведет к удалению. Потому что ссылка на s1 уже хранится где-то в функторе, коорый возвращает bind().

Это уже к спору о проблемах GC
Re[13]: Оберон vs все остальное
От: Кодёнок  
Дата: 14.01.05 05:44
Оценка:
СГ>Куда добавляем-то, массив же уже создан...

СГ>Нужно вручную создать совершенно другой новый массив, который на 100 элементов длиннее, и вручную скопировать в него то что хотите. О старом массиве забыть.


Ладно, Cray X, я думаю, справится с таким языком

СГ>Написать три строчки кода:

СГ>
СГ>  NEW(tmp, LEN(a) + 100);
СГ>  FOR i := 0 TO LEN(tmp)-1 DO tmp[i] := a[i] END;
СГ>  a := tmp;
СГ>

СГ>это что теперь проблемой называется????

СГ>А я то думал, что проблема, это, например, придумать хорошую эвристику для NP-задачи...


Да нет, проблема — это вылавливать в коде на 25000 строк LEN(tmp) вместо LEN(tmp)-1, написанные по привычке tmp[i] := a[i] вместо DeepCopy(tmp[i], a[i]). Причем в разных случая циклы могут чуть-чуть отличаться, как в случае с DeepCopy, например, так что процедурой не отмажешься, и придется в каждый кусок кода вникать. Тут — копирование, там — вставка, там — сдвиг, там — элементы ссылаются на индексы друг друга в этом массиве. Через неделю ты забудешь, что эта программа делает
Re[15]: Оберон vs все остальное
От: Кодёнок  
Дата: 14.01.05 07:58
Оценка:
СГ>Да ладно Вам фантазировать, ничего вылавливать не надо, все пишется в 1 экземпляре в одном модуле.

Это опыт работы с Дельфи...
Re[11]: Оберон vs все остальное
От: Курилка Россия http://kirya.narod.ru/
Дата: 14.01.05 08:17
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

<skipped>

Т.е. проверку делаем в рантайме со всеми вытекающими (довольно "грязными") последствиями?
Re[8]: Оберон vs все остальное
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 14.01.05 08:22
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Кстати, а как твоим функциям передавать КОНТЕКСТ вычислений? Или как обычно, через глобальные переменные?


Да.

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



Впрочем, если возникает необходимость в нескольких контекстах вычисления одновременно, то Вы правы, тут уже надо использовать ООП, и смысл в именно такой функции какую просил я значительно снижается — ведь можно использовать для того же самого другие средства уже свойственные только ООП.
Re[9]: Оберон vs все остальное
От: Cyberax Марс  
Дата: 14.01.05 08:33
Оценка:
Сергей Губанов пишет:

> C>Кстати, а как твоим функциям передавать КОНТЕКСТ вычислений? Или как

> обычно, через глобальные переменные?
> Да.

В морг. СРАЗУ же, без разговоров.

> Только глобальные переменные в модульных языках — это вовсе не тоже

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

Плевать, два потока, исполняющие один код я запустить уже не смогу.
Реентерабельности тоже нет. И не нужно говорить, что это все фигня — это
важнейшие вещи.

> Впрочем, если возникает необходимость в нескольких контекстах

> вычисления одновременно, то Вы правы, тут уже надо использовать ООП, и
> смысл в именно такой функции какую просил я значительно снижается —
> ведь можно использовать для того же самого другие средства уже
> свойственные только ООП.

А контекст нужно передавать ВСЕГДА (в 99.99% случаев), иногда только
можно для целей оптимизации использовать глобальные переменные.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[11]: Оберон vs все остальное
От: Cyberax Марс  
Дата: 14.01.05 08:35
Оценка:
Сергей Губанов пишет:

> Кё>Число параметров и типы могут отличаться, короче — быть любыми.

> Что, будешь писать разные процедуры для каждой новой комбинации?
> Кё>
>
>Кё>PROCEDURE bind_void_void(IN A: PROCEDURE; ...): functor
>Кё>PROCEDURE bind_void_int(IN A: PROCEDURE(a:integer); ...): functor
>Кё>PROCEDURE bind_void_real(IN A: PROCEDURE(a:read...): functor
>Кё>PROCEDURE bind_void_int_real(IN A: PROCEDURE(a:read...)
>Кё>PROCEDURE bind_void_real_int(IN A: PROCEDURE(a:read...)
>Кё
>
>
> Ах вот в чем дело. То есть термином "гибкость" здесь названо, то, что
> другие люди называют термином "грязный хак". Дело в том, что когда
> возникает необходимость определить процедуру принимающую произвольное
> количество аргументов различных типов, то это решается элементарнейшим
> способом:

Не совсем то. Вот есть у меня функциональный оператор с сигнатурой "void
(int,int)", я хочу на него сделать
адаптер вида "void(int)", а второй параметр сделать равным 2. С boost'ом
это делается так:
=============
boost::bind(xxx,указатель_на_функтор,_1,2);
=============
У меня создается функтор, принимающий один параметр, делегирующий вызов
моему функтору, устанавливая второй его параметр в 2.

И еще раз — совместимость типов проверяется на этапе компиляции.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[12]: Оберон vs все остальное
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 14.01.05 08:36
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Т.е. проверку делаем в рантайме со всеми вытекающими (довольно "грязными") последствиями?


В оберонах вообще и в Component Pascal в частности нет множественного наследования, а есть просто расширение типа. В связи с этим инструкция конкретизации типа
WITH v: T1 DO S1 | v: T2 DO S2 | v: T3 DO S3 ... ELSE Sn END

не обладает ни какими грязными последствиями, а также выполняется очень быстро — примерно так же быстро как выполнялся бы обычный CASE (или switch) по скрытому тэгу в записи (ну разьве только что если иерархия расширения типов будет глубокой — вот из-за этого может быть чуток медленнее).
Re[10]: Оберон vs все остальное
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 14.01.05 08:40
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Плевать, два потока, исполняющие один код я запустить уже не смогу.

C>А контекст нужно передавать ВСЕГДА (в 99.99% случаев), иногда только
C>можно для целей оптимизации использовать глобальные переменные.

А если система встроенная и там потоков нет?
Re[13]: Оберон vs все остальное
От: Курилка Россия http://kirya.narod.ru/
Дата: 14.01.05 08:43
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Курилка, Вы писали:


К>>Т.е. проверку делаем в рантайме со всеми вытекающими (довольно "грязными") последствиями?


СГ>В оберонах вообще и в Component Pascal в частности нет множественного наследования, а есть просто расширение типа. В связи с этим инструкция конкретизации типа

СГ>
СГ>WITH v: T1 DO S1 | v: T2 DO S2 | v: T3 DO S3 ... ELSE Sn END
СГ>

СГ>не обладает ни какими грязными последствиями, а также выполняется очень быстро — примерно так же быстро как выполнялся бы обычный CASE (или switch) по скрытому тэгу в записи (ну разьве только что если иерархия расширения типов будет глубокой — вот из-за этого может быть чуток медленнее).

С чего это не обладает?
Например:
Берём ситуацию, что в with ты забудешь один из типов по запарке, бывает такое, ну и оберон твой нихрена не скажет, всё будет ништяк, но работать-то будет в итоге прога не правильно.
А в плюсах тебе компилер скажет — нифига нет определения с такими параметрами, соответственно ты прогу даже скомпилить не сможешь.
Что ты скажешь хотябы на это?
Re[15]: Оберон vs все остальное
От: Курилка Россия http://kirya.narod.ru/
Дата: 14.01.05 09:01
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Курилка, Вы писали:



К>>Берём ситуацию, что в with ты забудешь один из типов по запарке, бывает такое, ну и оберон твой нихрена не скажет, всё будет ништяк, но работать-то будет в итоге прога не правильно.



СГ> If no type test is satisfied and if an ELSE clause is missing the program is aborted.


Супер
Значит вместо ошибки компиляции мы получим, что у заказчика прога просто закроется ничего даже не сказав, нет, ну такие системы понравятся заказчикам, особенно в критически важных приложениях такое поведение просто то, что нужно!
Re[15]: Оберон vs все остальное
От: Курилка Россия http://kirya.narod.ru/
Дата: 14.01.05 09:08
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, Курилка, Вы писали:



К>>Берём ситуацию, что в with ты забудешь один из типов по запарке, бывает такое, ну и оберон твой нихрена не скажет, всё будет ништяк, но работать-то будет в итоге прога не правильно.



СГ> If no type test is satisfied and if an ELSE clause is missing the program is aborted.



Теперь подумай о "грязности"

— И эти люди запрещают мне в носу ковыряться? (ц) Вовочка
Re[15]: Оберон vs все остальное
От: Кодёнок  
Дата: 14.01.05 09:28
Оценка:
К>>Берём ситуацию, что в with ты забудешь один из типов по запарке, бывает такое, ну и оберон твой нихрена не скажет, всё будет ништяк, но работать-то будет в итоге прога не правильно.

СГ> If no type test is satisfied and if an ELSE clause is missing the program is aborted.


Бедный беспилотный вертолет! . Хочешь доказать, что одну дополнительную проверку правильности программы можно переложить на рантайм?
Re[13]: Оберон vs все остальное
От: Кодёнок  
Дата: 14.01.05 09:46
Оценка:
СГ>Еще один проект, в котором Н.Вирт участвовал в течение нескольких лет начиная с 1995 г.,

Вирт добивается успеха не потому что использует Оберон, а потому что он Вирт Как будто, если бы он был вынужден исопльзовать С++, этот вертолет ждал бы полный крах! Или ему бы потребовалось времени больше? (Только если языка не знает ) Или отлаживал бы дольше?

СГ>Читатель может прикинуть, сколько весила бы машина, если бы ее ПО создавалось на основе таких популярных языков как Java или C++ — и когда был бы закончен проект. В качестве масштабного множителя можно предложить отношение объемов описаний языков — 16 стр. для Оберона, 200 для Java и больше 1000 для C++. )


Не может читатель такого прикинуть, т.к. принципиальной разницы между Oberon и Java, например, в данном случае не видит. Половину восхвалений Вирта и Оберона можно было заменить на объяснение, какова принципиальная проблема в использовании другого языка? Java например.
Re[14]: Оберон vs все остальное
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 14.01.05 09:55
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ой, ну не надо ля-ля. Однокристалки в 10 грамм веса с JVM на борту

C>сейчас почти в каждом мобильнике.

Да я не против Java или даже C#, я против Си/Си++.

Только у Java и C# есть свои области применения (интернет/бизнес), а вот Си/Си++ позиционируются как системный/универсальный, так вот языки Oberon/Component Pascal позиционируются тоже как системный/универсальный как раз вместо Си/Си++, но не вместо Java и C#.
Re[15]: Оберон vs все остальное
От: Курилка Россия http://kirya.narod.ru/
Дата: 14.01.05 10:03
Оценка:
Здравствуйте, Сергей Губанов, Вы писали:

СГ>Только у Java и C# есть свои области применения (интернет/бизнес), а вот Си/Си++ позиционируются как системный/универсальный, так вот языки Oberon/Component Pascal позиционируются тоже как системный/универсальный как раз вместо Си/Си++, но не вместо Java и C#.


А какже сказанное тобою тут про встроенные системы и отсутствие потоков? Как это с универсальностью соотносится?
Re[15]: Оберон vs все остальное
От: Кодёнок  
Дата: 14.01.05 10:23
Оценка:
C>>Ой, ну не надо ля-ля. Однокристалки в 10 грамм веса с JVM на борту
C>>сейчас почти в каждом мобильнике.

СГ>Да я не против Java или даже C#, я против Си/Си++.


СГ>Только у Java и C# есть свои области применения (интернет/бизнес), а вот Си/Си++ позиционируются как системный/универсальный, так вот языки Oberon/Component Pascal позиционируются тоже как системный/универсальный как раз вместо Си/Си++, но не вместо Java и C#.


Мало ли что как позиционируется. Интересно, что они реально могут. А как тут уже показали на паре примеров, до универсальности им далеко, и даже попыток что-то не делается.

P.S. Microsoft не суется с Windows во встроенные системы с повышенными требованиями к надежности, а Вирт похоже не собирается приводить язык на рынок бизнес- и десктопных приложений. А если кто-то возьмется, тот тут-то и начнутся в правильном и красивом языке хак на хаке и разные расширения компилятора, как у Borland. В научных статьях Вирта оно конечно здорово смотрится но не более того.
Re[16]: Оберон vs все остальное
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 14.01.05 10:25
Оценка:
Здравствуйте, Курилка, Вы писали:

К>А какже сказанное тобою тут про встроенные системы и отсутствие потоков? Как это с универсальностью соотносится?


Так ведь в Си/Си++ многопоточность тоже появляется только через внешние библиотеки.
Re[15]: Системность
От: Кодёнок  
Дата: 14.01.05 10:30
Оценка:
Кё>> ...объяснение, какова принципиальная проблема в использовании другого языка? Java например.

СГ>Причина просто в том что Oberon — системный язык, в то время как Java или С# таковыми не являются.


СГ>Просто посмотрим на типы данных:


Ну не все так плохо с Java Железо может быть специально предназначено для JVM и только для нее. Но можно признать. А почему тогда не C++?
Re[15]: Системность
От: Cyberax Марс  
Дата: 14.01.05 10:47
Оценка:
Сергей Губанов пишет:

> Кё> ...объяснение, какова принципиальная проблема в использовании

> другого языка? Java например.
> Причина просто в том что Oberon — системный язык, в то время как Java
> или С# таковыми не являются.

Да какой он, нафиг, системный? Он же не умеет работать без GC и
runtime-системы. Он такой же системный как и Java.

Системный язык — это С, с натяжкой, С++.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[15]: Оберон vs все остальное
От: Cyberax Марс  
Дата: 14.01.05 10:50
Оценка:
Сергей Губанов пишет:

> C>Ой, ну не надо ля-ля. Однокристалки в 10 грамм веса с JVM на борту

> C>сейчас почти в каждом мобильнике.
> Да я не против Java или даже C#, я против Си/Си++.
> Только у Java и C# есть свои области применения (интернет/бизнес), а
> вот Си/Си++ позиционируются как системный/универсальный

А он такой и есть, так как существует множество _работающих_ систем всех
видов на С++. Начиная от ОС и кончая сложными бизнес-приложениями. Это
доказательство того, что С++ — универсальный.

> так вот языки Oberon/Component Pascal позиционируются тоже как

> системный/универсальный как раз вместо Си/Си++, но не вместо Java и C#.

Только вот себя они не доказали на реальных примерах (да и не докажут —
нафиг они никому кроме Вирта не нужны).

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[16]: Системность
От: tarkil Россия http://5209.copi.ru/
Дата: 14.01.05 10:51
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Системный язык — это С, с натяжкой, С++.


А почему С++ — с натяжкой?
--
wbr, Peter Taran
Re[10]: Оберон vs все остальное
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 14.01.05 10:51
Оценка:
Здравствуйте, AndrewJD, Вы писали:

AJD>ИМХО только благодаря "борландовским поделкам" паскаль все еще остается популярным.


Однако Delphi 8, Delphi 2005 многих разочаровали. Например я так и остался на Delphi 7, а есть люди оставшиеся на Delphi 6 (поскольку в семерке для них ничего нового не было а QReports был заменен на Rave) или даже на Delphi 5.


Ошибки и особенности обнаруженные в Delphi 2005
http://asysoev.nm.ru/ForForums/Delphi2005_is_Bugs_Bag.htm
последнее обновление 11.01.2005 число записей 17
Re[18]: Оберон vs все остальное
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 14.01.05 10:56
Оценка:
Здравствуйте, Cyberax, Вы писали:

C> кстати, а в Oberon'е есть volatile?


Нету.

Если Вам так интересна многопоточность, то есть специально придуманный для нее Оберон под названием Active Oberon. Там объекты активные, то есть объект = поток.

Операционка написанная на нем тут: http://bluebottle.ethz.ch/

Так же есть дальний родственник Оберона — Zonnon это переосмысление Active Oberon for .NET http://www.zonnon.ethz.ch/
Re[16]: Системность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 14.01.05 11:03
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Да какой он, нафиг, системный? Он же не умеет работать без GC и

C>runtime-системы. Он такой же системный как и Java.

Просто GC+runtime реализуются непосредственно поверх железа, а уже все остальное (включая операционку) пишется на языке высокого уровня. Например, именно так и было сделано в операционке Aos BlueBottle






Кроме того для специальных случаев встроенных систем — тех где динамическая память отсутсвует в принципе, можно использовать обрезанный Оберон без инструкции NEW и без динамической загрузки модулей.
http://www.inr.ac.ru/~info21/cpascal/cp_report_1.4_rus.htm#D

За исключением полностью слинкованных приложений, в которых при исполнения не нужно загружать никакие модули, для модулей требуется динамический загрузчик [linking loader]. Встроенные системы являются важными примерами приложений, которые могут быть полностью слинкованы.

Re[17]: Системность
От: Cyberax Марс  
Дата: 14.01.05 11:05
Оценка:
Сергей Губанов пишет:

> Кё> А почему тогда не C++?

> А потому что:
> 1) Полное исчерпывающее описание Оберона занимает 16-30 страниц (в
> зависимости от шрифта), а полное исчерпывающее описание С++ занимает
> несколько сотен страниц. Проблема обучения.

Не надо народ смешить. Спека "системного" языка занимать 30 страниц не
может.

Где в спеке Оберона описывается взаимодействие с нативным кодом, способы
передачи параметров, расположения структур в памяти, обработку машинных
исключений? Ни за что не поверю, что все вошло в 16 страниц.

> 2) Сколько ресурсов надо затратить чтобы написать новый правильно

> работающий компилятор С++ под новый тип чипа просто не сопоставимо с
> той же работой для Оберона. В ETH портирование Оберона на новый тип
> чипа делают студенты за месяц.
>
Берем GCC и добавляем туда поддержку еще одного процессора. Делается
элементарно — сам разговаривал с человеком, который это сделал за пару
недель. Для GCC просто нужно описать систему команд процессора, ну и
портировать runtime (если нужно).

> 3) Сопровождение кода на С++ эффективно может делать только автор

> этого кода, любой другой программист лучше заново по своему напишет
> чем разбереться с уже написанным.
>
Ой, ну конечно. Я спокойно читаю код на С++, если конечно в нем не
используется черная магия в виде многоуровневых шаблонов. Мои коллеги
тоже что-то не испытывают проблем с чтением C/С++.

> 4) С++ — unsafe, Оберон — safe (работа с адресной арифметикой, если

> таковая необходима, в Обероне осуществляется через внешние библиотеки).

Ха, какой он тогда "системный"?

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[19]: Оберон vs все остальное
От: Cyberax Марс  
Дата: 14.01.05 11:10
Оценка:
Сергей Губанов пишет:

> C> кстати, а в Oberon'е есть volatile?

> Нету.
> Если Вам так интересна многопоточность, то есть специально придуманный
> для нее Оберон под названием Active Oberon. Там объекты активные, то
> есть объект = поток.

В качестве эксперимента — пойдет. Для практики нафиг не нужен — даже не
сравним с Erlang'ом.

> Операционка написанная на нем тут: http://bluebottle.ethz.ch/


Чего-то маловато в ней функциональности...

> Так же есть дальний родственник Оберона — Zonnon это переосмысление

> Active Oberon for .NET http://www.zonnon.ethz.ch/

Очередная поделка...

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[17]: Системность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 14.01.05 11:11
Оценка:
http://www.inr.ac.ru/~info21/cpascal/cp_report_1.4_rus.htm#D


Приложение D: Обязательные требования к среде выполнения

Определение Компонентного Паскаля опирается на три фундаментальных предположения.

1) Во время исполнения программ доступна информация, позволяющая проверять динамический тип объекта. Это нужно для реализации проверок типов и охраны типов.

2) Отсутствует процедура DISPOSE <освобождение памяти под более не используемые объекты>. Память <занимаемая объектом> не может быть освобождена по явной инструкции программиста, поскольку это создало бы проблемы безопасности, связанные с потерей памяти [memory leaks] <память, занимаемая объектами, недоступными ни через какие указатели, которую программист забыл освободить> и с висячими указателями [dangling pointers] <доступные указатели, продолжающие указывать на области памяти, по ошибке преждевременно освобожденные>. За исключением таких встроенных систем, где не используется динамическое управление памятью, или где ее можно разместить только однажды и никогда не нужно освобождать, требуется автоматический сбор мусора.

3) Модули и по крайней мере их экспортированные процедуры (команды) и экспортированные типы должны быть доступны динамически. Если необходимо, это может вызывать загрузку модулей. Программный интерфейс, используемый для загрузки модулей или для доступа к указанной мета-информации, не определяется языком, но компилятор должен сохранять эту информацию при генерации кода.
За исключением полностью слинкованных приложений, в которых при исполнения не нужно загружать никакие модули, для модулей требуется динамический загрузчик [linking loader]. Встроенные системы являются важными примерами приложений, которые могут быть полностью слинкованы.

Реализация, которая не удовлетворяет этим требованиям к компилятору и среде выполнения, не считается удовлетворяющей определению Компонентного Паскаля.

Re[17]: Системность
От: Cyberax Марс  
Дата: 14.01.05 11:12
Оценка:
Сергей Губанов пишет:

> C>Да какой он, нафиг, системный? Он же не умеет работать без GC и

> C>runtime-системы. Он такой же системный как и Java.
> Просто GC+runtime реализуются непосредственно поверх железа

То есть железо должно быть спроектировано специально для Oberon'а?
Закатайте губы обратно — такого железа не будет.

> а уже все остальное (включая операционку) пишется на языке высокого

> уровня. Например, именно так и было сделано в операционке Aos
> BlueBottle <http://bluebottle.ethz.ch/&gt;

Таких JavaOS — куча. _Практичных_ — ноль.

--
С уважением,
Alex Besogonov (alexy@izh.com)
Posted via RSDN NNTP Server 1.9
Sapienti sat!
Re[18]: Системность
От: tarkil Россия http://5209.copi.ru/
Дата: 14.01.05 11:34
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Слишком высокоуровневый для системного программирования в некоторых

C>случаях (RTTI, исключения). Хотя достоинство С++ в том, что
C>высокоуровневые фичи можно и не использовать.

Вот-вот, и я к тому же. Страуструп одной из задач ставил, чтоб C++ мог использоваться для всех задач C с неменьшей эффективность. Эти фичи не повязаны жёстко друг на друга, можно от чего-то отказаться.

А чего, на мой взгляд, не хватает в компиляторах, так это гибко настроить ограничения на использование разных возможностей языка. Скажем, запретить для системного проекта виртуальные функции. Или для прикладного проекта — арифметику с указателями...
--
wbr, Peter Taran
Re[18]: Системность
От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
Дата: 14.01.05 12:48
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>То есть железо должно быть спроектировано специально для Oberon'а?

C>Закатайте губы обратно — такого железа не будет.


Ага щассс...


  • Язык как основа архитектуры. Проект Lilith
    http://www.rol.ru/news/it/press/cwm/19_98/pdp.htm

  • Язык как основа архитектуры. Проект "Кронос" и путь к технологиям XDS
    http://www.rol.ru/news/it/press/cwm/20_98/kron.htm

  • Язык как основа архитектуры. Средства кроссразработки и технологии XDS
    http://www.rol.ru/news/it/press/cwm/21_98/micro.htm

  • ОТ РАЗРАБОТКИ ЯЗЫКОВ ПРОГРАММИРОВАНИЯ К КОНСТРУИРОВАНИЮ КОМПЬЮТЕРОВ
    Никлаус Вирт
    Выступление при получении премии Тьюринга
    http://www.uni-vologda.ac.ru/oberon/wirth/wirth-turing.htm

  • http://www.inr.ac.ru/~info21/info/wirth_avia.htm

    ...Бортовой компьютер (получивший, кстати, имя OLGA = Oberon Language Goes Airborne) оказался настолько компактным благодаря компактности и эффективности получившихся программ (использовалось подмножество языка Оберон), что вес машины удалось резко снизить по сравнению с предыдущими версиями конструкции — всего до 15 кг. (Потомки компьютера OLGA используются в компании weControl.)

  • Re[19]: Системность
    От: Cyberax Марс  
    Дата: 14.01.05 12:53
    Оценка:
    Сергей Губанов пишет:

    > C>То есть железо должно быть спроектировано специально для Oberon'а?

    > C>Закатайте губы обратно — такого железа не будет.
    > Ага щассс...

    И где оно сейчас? Я же не зря написал "не будет". Всякие Lisp-машины
    тоже благополучно сдохли...

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[19]: Системность
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 14.01.05 12:57
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Здравствуйте, Cyberax, Вы писали:


    C>>То есть железо должно быть спроектировано специально для Oberon'а?

    C>>Закатайте губы обратно — такого железа не будет.


    СГ>Ага щассс...


    <skipped>

    Да, ужасно распространённые системы, люди на них миллиарды долларов делают
    Re[20]: Системность
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 14.01.05 13:07
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Сергей Губанов пишет:


    >> C>То есть железо должно быть спроектировано специально для Oberon'а?

    >> C>Закатайте губы обратно — такого железа не будет.
    >> Ага щассс...

    C>И где оно сейчас? Я же не зря написал "не будет". Всякие Lisp-машины

    C>тоже благополучно сдохли...

    А, кстати, ничего не можешь сказать, линков кинуть как раз по лиспмашинам? Они совсем сдохли пару десятков лет назад или всё-же есть живые экземпляры?
    Re[21]: Системность
    От: Cyberax Марс  
    Дата: 14.01.05 13:14
    Оценка:
    Курилка пишет:

    >>> C>То есть железо должно быть спроектировано специально для Oberon'а?

    >>> C>Закатайте губы обратно — такого железа не будет.
    >>> Ага щассс...
    > C>И где оно сейчас? Я же не зря написал "не будет". Всякие Lisp-машины
    > C>тоже благополучно сдохли...
    > А, кстати, ничего не можешь сказать, линков кинуть как раз по
    > лиспмашинам? Они совсем сдохли пару десятков лет назад или всё-же есть
    > живые экземпляры?

    Ничего не умирает полностью в мире компьютеров — я даже не один
    работающий комп с перофокартами видел. Есть какие-то отдельные
    Лисп-процессоры — развитие старых образцов, но про новые разработки
    что-то не слышно.

    А ссылки можно найти в Гугле по слову Symbolics.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[19]: Системность
    От: GlebZ Россия  
    Дата: 14.01.05 13:15
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    Джентельмены, а зачем машины для языка? Мое мнение, что это язык должен оптимально портироваться. И если процессор может выполнять достаточно высокоуровневые команды, то тогда именно язык должен портироваться на них (но не наоборот).

    С уважением, Gleb.

    PS: Я слышал о отдельных процах в mainframe для байт-кода Java(ито мельком), но кто мешает воспользоваться другим языком для портирования под него?
    Re[20]: Системность
    От: Cyberax Марс  
    Дата: 14.01.05 14:12
    Оценка:
    GlebZ пишет:

    > PS: Я слышал о отдельных процах в mainframe для байт-кода Java(ито

    > мельком), но кто мешает воспользоваться другим языком для портирования
    > под него?

    Есть два подхода для аппаратных процессоров:
    1. _Некоторые_ команды JVM микрокодом транслировать в непосредственный
    код. Получается не особо быстро, зато сложно и дорог.
    2. Использовать аппаратную поддержку для ускорения JIT'а и GC. Именно
    так и работают сейчас нормальные Java-процы.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[21]: Системность
    От: GlebZ Россия  
    Дата: 14.01.05 14:46
    Оценка:
    Здравствуйте, Cyberax, Вы писали:


    C>2. Использовать аппаратную поддержку для ускорения JIT'а и GC. Именно

    C>так и работают сейчас нормальные Java-процы.

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

    С уважением, Gleb.
    Re[17]: Оберон vs все остальное
    От: Bigger Российская Империя  
    Дата: 14.01.05 15:17
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Здравствуйте, Курилка, Вы писали:


    К>>А какже сказанное тобою тут про встроенные системы и отсутствие потоков? Как это с универсальностью соотносится?


    СГ>Так ведь в Си/Си++ многопоточность тоже появляется только через внешние библиотеки.


    Отсюда поподробнее пожауйста

    Программист — это шаман..., подарите бубен!
    Re[22]: Системность
    От: Cyberax Марс  
    Дата: 14.01.05 15:47
    Оценка:
    GlebZ пишет:

    > C>2. Использовать *аппаратную поддержку* для ускорения JIT'а и GC. Именно

    > C>так и работают сейчас нормальные Java-процы.
    > Специально подчеркнул. Уже давно настали времена, когда софтварно
    > большинство вещей делается намного дешевле (и быстрей если брать
    > отношение стоимости и производительности) чем на аппаратном уровне.

    Да, но тот же GC с совсем небольшой аппаратной поддержкой можно сделать
    ЗНАЧИТЕЛЬНО эффективнее, как и JIT. Требуется ведь не полная их
    аппаратная реализация, а просто несколько особых фич.

    > Это стало понятно, еще когда была бадяга между пентюхом и risk

    > процами. А под эту аппаратную поддержку, наверняка можно и MSIL
    > навернуть. Не так уж они и концептуально различаются.

    Да, есть и для MSIL решения.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[22]: Системность
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.01.05 20:27
    Оценка:
    Здравствуйте, GlebZ, Вы писали:

    GZ>Специально подчеркнул. Уже давно настали времена, когда софтварно большинство вещей делается намного дешевле (и быстрей если брать отношение стоимости и производительности) чем на аппаратном уровне. Это стало понятно, еще когда была бадяга между пентюхом и risk процами.


    Ага. Поэтому х86, несмотря на свою неимоверную кривость, до сих пор поддерживается на аппаратном уровне.
    ... << RSDN@Home 1.1.4 beta 3 rev. 283>>
    AVK Blog
    Re[17]: Системность
    От: Poudy Россия  
    Дата: 18.01.05 09:00
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Просто GC+runtime реализуются непосредственно поверх железа, а уже все остальное (включая операционку) пишется на языке высокого уровня. Например, именно так и было сделано в операционке Aos BlueBottle


    Three buttons recommended for Oberon


    Это никак шутка?
    Re[19]: Системность
    От: Poudy Россия  
    Дата: 18.01.05 09:04
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>...Бортовой компьютер (получивший, кстати, имя OLGA = Oberon Language Goes Airborne) оказался настолько компактным благодаря компактности и эффективности получившихся программ (использовалось подмножество языка Оберон), что вес машины удалось резко снизить по сравнению с предыдущими версиями конструкции — всего до 15 кг. (Потомки компьютера OLGA используются в компании weControl.)

    СГ>[/q]

    Ты действительно уверен, что это из-за Оберона? Это к другому спору "если би Пушкин родился в Германии, стал бы он писать стихи".
    Re[13]: Оберон vs все остальное
    От: WolfHound  
    Дата: 18.01.05 17:02
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Написать три строчки кода:

    СГ>
    СГ>  NEW(tmp, LEN(a) + 100);
    СГ>  FOR i := 0 TO LEN(tmp)-1 DO tmp[i] := a[i] END;
    СГ>  a := tmp;
    СГ>

    СГ>это что теперь проблемой называется????
    Да. Сравни с
    a.push_back(123);

    или если нужно добюавить не один элемент в хвост а именно 100 то
    a.resize(a.size()+100);

    отдельной функции нет ибо нужно очень редко.

    А теперь представь это в разных сочетаниях в 1000 мест...

    СГ>А я то думал, что проблема, это, например, придумать хорошую эвристику для NP-задачи...

    А зачем ее придумывать? С вероятность 99% она уже придумана надо только потрясти гугль. А если и нет то раз в несколько лет можно и попридумывать...
    Просто у современных программистов другие проблемы... и ты похоже это никане не можешь/не хочешь понять.
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[21]: Системность
    От: Poudy Россия  
    Дата: 18.01.05 21:22
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    P>>Ты действительно уверен, что это из-за Оберона?

    СГ>Да.
    Хотя это уже становится не смешно. Это уже становится интересно. Давай ты попробуешь привести немного другую аргументацию. Тогда, вероятно, когда ты в очередной раз повторишь "Oberon — системный язык", я скажу "Ааааа... Понял!" .
    Re[14]: Оберон vs все остальное
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 19.01.05 07:04
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Здравствуйте, Сергей Губанов, Вы писали:


    WH>Да. Сравни с

    WH>
    WH>a.push_back(123);
    WH>

    WH>или если нужно добюавить не один элемент в хвост а именно 100 то
    WH>
    WH>a.resize(a.size()+100);
    WH>

    WH>отдельной функции нет ибо нужно очень редко.

    WH>А теперь представь это в разных сочетаниях в 1000 мест...


    СГ>>А я то думал, что проблема, это, например, придумать хорошую эвристику для NP-задачи...

    WH>А зачем ее придумывать? С вероятность 99% она уже придумана надо только потрясти гугль. А если и нет то раз в несколько лет можно и попридумывать...
    WH>Просто у современных программистов другие проблемы... и ты похоже это никане не можешь/не хочешь понять.


    В точности также все это можно писать на обероноподобных языках:
      a.PushBack(123);
      a.Resize(a.length + 100);

    так что хватит Вам выдумывать никогда не существовавших проблем.
    Re[15]: Оберон vs все остальное
    От: WolfHound  
    Дата: 19.01.05 07:16
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>В точности также все это можно писать на обероноподобных языках:

    СГ>
    СГ>  a.PushBack(123);
    СГ>  a.Resize(a.length + 100);
    СГ>

    СГ>так что хватит Вам выдумывать никогда не существовавших проблем.
    Типизировано? Или как всегда полиморфно?
    ... << RSDN@Home 1.1.4 beta 3 rev. 185>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[16]: Оберон vs все остальное
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 19.01.05 07:59
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Типизировано? Или как всегда полиморфно?


    Как пожелаете.
    Re[26]: Системность
    От: Cyberax Марс  
    Дата: 19.01.05 12:37
    Оценка:
    AVC пишет:

    > Результат: разница была даже не в процентах. XDS "покрыл" Visual в

    > *три раза*. Возможно, надо было поизощреннее выставлять ключи
    > оптимизации для Visual C++, но ему это все равно было бы что мертвому
    > припарки.

    ROTFL...

    Тестовый пример и ключи компиляторов — *В СТУДИЮ!*

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[27]: Системность
    От: AVC Россия  
    Дата: 19.01.05 12:57
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    >> Результат: разница была даже не в процентах. XDS "покрыл" Visual в

    >> *три раза*. Возможно, надо было поизощреннее выставлять ключи
    >> оптимизации для Visual C++, но ему это все равно было бы что мертвому
    >> припарки.

    C>ROTFL...

    C>Тестовый пример и ключи компиляторов — *В СТУДИЮ!*

    Ой, какие мы смелые!
    Впрочем, это правильный подход.

    Для проверки, наверное, лучше всего поступить так.
    1) Скачать бесплатную версию XDS 1999 года с сайта
    http://www.excelsior-usa.com/xdsdlpers.html
    2) В подкаталоге SAMPLES\BENCH найти файлы Dry.c и Dry.mod
    3) Откомпилировать их. Ключи компиляции для Dry.mod указаны в самом файле.
    Запуск компилятора:
    xc =m Dry.mod
    Для исходника на Си можете сами выбрать ключи компиляции.
    Как говорится, enjoy!

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[26]: СИСТЕМНОСТЬ
    От: Cyberax Марс  
    Дата: 19.01.05 13:25
    Оценка:
    Сергей Губанов пишет:

    > WH>ЗЫ Я не верю что в 4000 строк мог поместится *оптимизирующий*

    > компилятор.
    > О-о-о... Значит *ЗАЦЕПИЛО* наконец-то!!!!!!!!!!!

    Я его посмотрел. По сравнению с GCC — десткий лепет. Где в нем
    планирование регистров, распараллеливание кода, учет фишек разных
    архитектур, оптимизация выражений? Правильно, нету. Так как в 50Кб кода
    это не вместится, даже если написать на Перле.

    А простой неоптимизирующий компилятор в нейтив на С++ пишется где-то
    килобайт в 20 кода (сам видел).

    > Компилятор Oberon for Aos (в Aos BlueBottle, та самая в которой

    > минимальный системный вызов в 30 раз быстрее чем в Linux), так вот тот
    > компилятор занимает 8'667 строчек.

    В _30_ раз быстрее Линукса? А защита памяти там есть? Ну вот...

    ЗЫ: все это не тянет даже на серьезный продукт, и уж точно не тянет на
    "систему, которая должна заменить С".

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[26]: СИСТЕМНОСТЬ
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 19.01.05 13:26
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    <skipped>

    И что дают эти цифры? Ну толку от того, что какую-то операционку запихают в 10 кило? Если всё равно её юзать реально никто не будет, в отличие от тех же линуха и виндовза, ну уж про поддержку разного железа в аосе твоём молчу...
    Re[27]: СИСТЕМНОСТЬ
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 19.01.05 13:32
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C> В _30_ раз быстрее Линукса? А защита памяти там есть?


    Именно там она, в отличие от систем написанных на Си, как раз-то и есть!
    Re[29]: СИСТЕМНОСТЬ
    От: AVC Россия  
    Дата: 19.01.05 15:34
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Нет, нету там защиты памяти. Если "внешняя библиотека", которые из-за

    C>убогости языка нужны очень часто, запишет что-то "не туда" — *все* упадет.

    Интересно, как это внешняя библиотека получит доступ к объектам ядра?

    C>Кстати, посмотрел XDS:


    <...>

    C>3. Тестируем C-версию (*релизный* режим, максимальные оптимизации,

    C>компилятор MSVC 8 Beta 1):
    C>|D:\XDS\SAMPLES\BENCH\BENCH\BENCH\Release>BENCH.exe Please, wait about
    C>60 seconds Dhrystone time for 4000000 passes = 0 |
    C>И в этом месте программа падает с ошибкой деления на 0. После правки
    C>теста получаем результат 12000000 попугайчиков.
    C>Так что это XDS проигрывает в *3 раза* по скорости. И это я еще не
    C>использовал Profile-Guided Optimization и не искал "узкие места" в
    C>тесте. Да, кстати, размер исполняемого файла XDS: 53760 байт, а
    C>скомпилированного Студией Сшника: 52463 байт.

    И где же это такие попугайчики у Вас летают?
    Я, чтобы избежать каких-либо накладок (скажем, с измерением времени), сразу задал и для Си, и для Модулы 40,000,000 циклов.

    Для Си результат с максимальной оптимизацией по скорости: 2,666,666.
    Без оптимизации: 2,222,222.
    Для Модулы: 8,000,000.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[30]: СИСТЕМНОСТЬ
    От: Cyberax Марс  
    Дата: 19.01.05 15:41
    Оценка:
    AVC пишет:

    > И где же это такие попугайчики у Вас летают?


    MSVC 8 Beta 1, я вроде написал.

    > Я, чтобы избежать каких-либо накладок (скажем, с измерением времени),

    > сразу задал и для Си, и для Модулы 40,000,000 циклов.

    *Какой* компилятор и *какие* ключи? Это важно.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[31]: СИСТЕМНОСТЬ
    От: AVC Россия  
    Дата: 19.01.05 15:55
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>*Какой* компилятор и *какие* ключи? Это важно.


    Много еще что важно...
    Компилятор: MSVC 6. (Т.е. примерно ровесник компилятора XDS, другой версии MSVC у меня сейчас под рукой нет.)
    Ключи, если Вы помните, я предложил выбрать Вам.
    Я использовал Project settings: maximize speed.

    Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.

    Хоар
    Re[26]: СИСТЕМНОСТЬ
    От: alexeiz  
    Дата: 21.01.05 10:38
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Компилятор Oberon for Aos (в Aos BlueBottle, та самая в которой минимальный системный вызов в 30 раз быстрее чем в Linux), ...


    Кстати, в это не так уж и трудно поверить. Системный вызов достаточно накладен. Параметры на валидность нужно проверить, данные из user mode в kernel mode скопировать, режим переключить. Так как в BlueBottle ничего подобного нет, то не стоит удивляться, что данная фича в нём быстрее.
    Re: Оберон vs С#
    От: Silver_s Ниоткуда  
    Дата: 21.01.05 16:43
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:


    СГ>Загадка. Слабо на Си или Си++ написать тип функции принимающей в качестве аргумента и возвращающей переменную ее собственного типа?


    СГ>На Component Pascal это элементарно:

    СГ>
    СГ>TYPE
    СГ>  Action = PROCEDURE (a: Action): Action;
    СГ>


    Дык вот же, то же самое на C#

    delegate void Action(Action md);
    Re[2]: Оберон vs С#
    От: Павел Кузнецов  
    Дата: 21.01.05 16:48
    Оценка:
    Silver_s,

    > СГ>
    > СГ>TYPE
    > СГ>  Action = PROCEDURE (a: Action): Action;
    > СГ>

    >
    > Дык вот же, то же самое на C#
    >
    >
    > delegate void Action(Action md);
    >


    Не то же самое: второй вариант возвращает void, в то время как первый — значение своего же типа.
    Posted via RSDN NNTP Server 1.9
    Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
    Re[2]: Оберон vs С#
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 21.01.05 16:54
    Оценка:
    Здравствуйте, Silver_s, Вы писали:

    S_>Здравствуйте, Сергей Губанов, Вы писали:



    СГ>>Загадка. Слабо на Си или Си++ написать тип функции принимающей в качестве аргумента и возвращающей переменную ее собственного типа?


    СГ>>На Component Pascal это элементарно:

    СГ>>
    СГ>>TYPE
    СГ>>  Action = PROCEDURE (a: Action): Action; // Это функция !!!! 
    СГ>>


    S_> Дык вот же, то же самое на C#


    S_>
    S_>delegate void Action(Action md);
    S_>
    и солнце б утром не вставало, когда бы не было меня
    Re: Оберон vs все остальное
    От: Borisman2 Киргизия  
    Дата: 27.01.05 05:22
    Оценка:
    Господа! Дискуссия по многозадачности и убиваемости процессов, мне кажется, начинает сводиться к следующему вопросу:

    1) Что будет, если я попытаюсь выстрелить себе в ногу при помощи кода вида:

    while(True) {
    list.append(1)
    }
    (ну или как это будет выглядеть на Оберон-2)


    Однако, странная постановка вопроса! Правильный ответ — конечно, отстрелите себе ногу!!! И результат мало зависит от конкретной ОС или там от сборщика мусора.

    Тем не менее. Когда апологеты Оберона отвечают, что надо УДАЛИТЬ АКТИВНЫЙ ОБЪЕКТ, который выполняет данный код, противники (иногда) начинают измываться — "эта мол что, оберон мой объект прибил??? Ай, нехорошо...." Вы уж определитесь, что вам нужно. И замените термин "процесс" на термин "активный объект"


    Я лично считаю, что софтварная защита vs хардварная защита — вопрос также немного странный, ибо то, что для одного программиста — software, для другого может оказаться самым что ни на есть hardware!!! Вспомним ,хотя бы, про микрокод в процессорах. Поэтому возможность софтварной защиты имеет право на жизнь, хотя, конечно, накладывает очень жесткие ограничения на используемые инструментальные средства (все пишем на Оберон-2), что может оказаться совсем неприемлемо в ряде случаев (например, операционные системы общего назначения).
    Re[2]: Оберон vs все остальное
    От: Трурль  
    Дата: 27.01.05 06:01
    Оценка:
    Здравствуйте, Borisman2, Вы писали:

    B>Господа! Дискуссия по многозадачности и убиваемости процессов, мне кажется, начинает сводиться к следующему вопросу:


    B>1) Что будет, если я попытаюсь выстрелить себе в ногу при помощи кода вида:


    B>while(True) {

    B> list.append(1)
    B>}
    B>(ну или как это будет выглядеть на Оберон-2)

    А что будет, если пальнуть вот таким кодом?
    crazy.bat:
    loop:
    start crazy.bat
    goto loop
    Re[3]: Оберон vs все остальное
    От: Borisman2 Киргизия  
    Дата: 27.01.05 11:51
    Оценка:
    Здравствуйте, Трурль, Вы писали:
    Т>А что будет, если пальнуть вот таким кодом?
    Т>crazy.bat:
    Т>
    Т>loop:
    Т>start crazy.bat
    Т>goto loop
    Т>

    хехехе отстрелите себе....ну...сами знаете
    Re[4]: Оберон vs все остальное
    От: Cyberax Марс  
    Дата: 28.01.05 14:29
    Оценка:
    Сергей Губанов пишет:

    > C>Вроде который раз пытаемся уже сказать, что НЕ ПОЛУЧИТСЯ просто так

    > удалить "активный объект". Это приведет к куче проблем, так как на
    > удаленный объект могут ссылаться другие активные объекты, или если
    > активный объект использует дефецитные ресурсы. Чтобы таких ситуаций не
    > возникало — нужна определенная изоляция, хотя бы такая как AppDomain'ы
    > в dotNET, а это тянет за собой длиныый список вопросов о маршаллинге,
    > сериализации и т.д.
    > Среда .NET запускается отдельно для каждого процесса (именно поэтому
    > каждая запущенная .NET программа захватывает очень много памяти).

    Ничуть. Большая часть DLL-ок и заJITенного кода разделяется между
    процессами.

    > Таким образом внутри каждой .NET системы процессов вообще нет (процесс

    > — это она сама) там есть только потоки. Вот если бы .NET была одна
    > единственная на все процессы — вот другое дело.

    В .NET есть AppDomain'ы — это аналоги процессов, по сути. Объекты между
    AppDomain'ами НЕЛЬЗЯ передавать напрямую.

    > Вы сами возьмите и попробуйте в .NET программе удалить поток. Далее

    > цитирую Вас же: Это приведет к куче проблем, так как на этот поток
    > могут ссылаться другие потоки, или если поток использует дефецитные
    > ресурсы....

    Поток нельзя удалять. Зато можно прибить AppDomain — при этом корректно
    будут освобождены все занятые им ресурсы, а на других доменах это не
    скажется — так как объекты разных доменов не могут ссылаться друг на
    друга напрямую.

    > C>И в итоге получится аналог .NET

    > Наоборот, это .NET есть аналог Оберон систем, разрабатываемых с 1985 года.

    Какое самомнение Оберон тоже натащил концепций из кучи разных языков.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[4]: Оберон vs все остальное
    От: Cyberax Марс  
    Дата: 28.01.05 14:34
    Оценка:
    Трурль пишет:

    > C>И в итоге получится аналог .NET, только *с гораздо более уродливым **

    > C>языком, чем C#* и кучей других недостатков (отсутствием стандарта
    > C>интероперабельности и т.п.).
    > Трудно проидумать что-либо более уродливое, чем C#.

    Фанат VB? Понимаю...

    > Мы еще посмотрим, кто из нас убогий.


    Рынок уже давно решил — это выражается в количестве паскалевидного софта
    по отношению ко всему остальному.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    MS, Windows и стратегический внедрёж ;-)
    От: SilverCloud Россия http://rodonist.wordpress.com
    Дата: 28.01.05 18:51
    Оценка:
    Здравствуйте, Кодёнок, Вы писали:

    Кё>Microsoft не суется с Windows во встроенные системы с повышенными требованиями к надежности


    Поправка: с Windows NT. А вот с Windows CE очень даже сунулась, и не просто в индустрию (это не рынок, так, мелочь . Здесь пусть всякие Texas Instruments-ы, Siemens-ы, WindRiver-ы и прочие QNX-сы балуются ), а сразу в автопром . Короче, Билли в очередной раз показал, где лежит стратегия
    Who needs information?
    Re[6]: Оберон vs все остальное
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 28.01.05 21:59
    Оценка:
    Здравствуйте, _Obelisk_, Вы писали:

    _O_>При реализации автомата нет необходимости в функции, принимающей указатель на саму себя. Там нужен указатель на функцию возвращающию указатель на саму себя. А это достаточно легко моделируется.


    Согласен.

    Еще можно добавить, что с точки зрения эффективности использовать в реализациях КА указатели на функции довольно глупо. Уж лучше свитчи и генерация кода.
    ... << RSDN@Home 1.1.4 beta 3 rev. 279>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re: MS, Windows и стратегический внедрёж ;-)
    От: Cyberax Марс  
    Дата: 29.01.05 09:44
    Оценка:
    SilverCloud пишет:

    > Кё>Microsoft не суется с Windows во встроенные системы с повышенными

    > требованиями к надежности
    > Поправка: с *Windows NT*. А вот с Windows CE очень даже сунулась, и не
    > просто в индустрию (это не рынок, так, мелочь . Здесь пусть всякие
    > Texas Instruments-ы, Siemens-ы, WindRiver-ы и прочие QNX-сы балуются
    > ), а сразу в автопром . Короче, Билли в очередной раз показал, где
    > лежит стратегия

    Истории про зависшие компы с WinCE в hi-end автомобилях все слышали?

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[5]: Оберон vs все остальное
    От: Сергей Губанов Россия http://sergey-gubanov.livejournal.com/
    Дата: 01.02.05 10:26
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Поток нельзя удалять. Зато можно прибить AppDomain — при этом корректно

    C>будут освобождены все занятые им ресурсы, а на других доменах это не
    C>скажется — так как объекты разных доменов не могут ссылаться друг на
    C>друга напрямую.

    Ну и как же Вы после этого бочку на Обероны катить можете?

    Там таких ограничений нет —
    любой объект может ссылаться на любой другой объект. Активность объекта остановить — какие проблемы?

    А что до корректного освобождения всех ресурсов, так этого на автомате быть не может нигде.
    Вот память можно почистить и все, что еще-то? Только не надо про закрытие файлов и т. п. так как в объектно ориентированных ОС, файлы — это тоже объекты, только персистентные.
    Re[6]: Оберон vs все остальное
    От: Cyberax Марс  
    Дата: 01.02.05 11:02
    Оценка:
    Сергей Губанов пишет:

    > C>Поток нельзя удалять. Зато можно прибить AppDomain — при этом корректно

    > C>будут освобождены все занятые им ресурсы, а на других доменах это не
    > C>скажется — так как объекты разных доменов не могут ссылаться друг на
    > C>друга напрямую.
    > Ну и как же Вы после этого бочку на Обероны катить можете?
    > Там таких ограничений нет —
    > любой объект может ссылаться на любой другой объект. Активность
    > объекта остановить — какие проблемы?

    Я уже много раз говорил: дефецитные ресурсы...

    > А что до корректного освобождения *всех* ресурсов, так этого на

    > автомате быть не может нигде.

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

    > Вот память можно почистить и все, что еще-то? Только не надо про

    > закрытие файлов и т. п. так как в объектно ориентированных ОС, файлы —
    > это тоже объекты, только персистентные.

    У нас в Обероне, значит, уже и файловой системы нормальной нет? И
    сетевых соединений тоже?

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[4]: MS, Windows и стратегический внедрёж ;-)
    От: alexeiz  
    Дата: 14.02.05 07:42
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>SilverCloud пишет:


    >> C>Истории про зависшие компы с WinCE в hi-end автомобилях все слышали?

    >> Слышали. Вот только подробностей не было. Непонятно, что там у них
    >> зависло. Вы уверены, что это косяки Майкрософт?

    C>Нет, но сам факт того, что МС притягивает к себе такие проблемы (типа

    C>японского премьера, которого компьютер наглухо закрыл в автомобиле) —
    C>весьма интересен.

    Вроде же объяснили, что там проблема с железом была?
    Re[15]: Системность
    От: serg_mo  
    Дата: 14.02.05 16:18
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    СГ>Короче говоря, в языках Java и C# просто нету возможности создавать системно необходимые типы данных.


    А что это за типы данных такие?
    ... << RSDN@Home 1.1.3 stable >>
    Re[27]: СИСТЕМНОСТЬ
    От: serg_mo  
    Дата: 14.02.05 16:45
    Оценка:
    Здравствуйте, Курилка, Вы писали:

    К>Здравствуйте, Сергей Губанов, Вы писали:


    К><skipped>


    К>И что дают эти цифры? Ну толку от того, что какую-то операционку запихают в 10 кило? Если всё равно её юзать реально никто не будет, в отличие от тех же линуха и виндовза, ну уж про поддержку разного железа в аосе твоём молчу...


    А вот тут ты не прав. Операционки такого плана очень даже полезны при разработки частных систем управления, например. Тут и железо будет ну уж очччень специфическое. Я помню, в институте с мной вместе диплом защищал один человек как раз по этой теме. Реализована была система управления какой-то энергетической установкой, на QNX. Выглядело все очень элегантно.

    А иметь ОС, которая содержит всякие вкусности типа сборки мусора, довольно заманчиво...
    ... << RSDN@Home 1.1.3 stable >>
    Re[4]: MS, Windows и стратегический внедрёж ;-)
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 15.02.05 14:18
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Нет, но сам факт того, что МС притягивает к себе такие проблемы (типа

    C>японского премьера, которого компьютер наглухо закрыл в автомобиле) —
    C>весьма интересен.

    Я тут недавно случайно наблюдал... Один орел приехал на иномарке, закрыл машину и ушел. Машина на сингнализации... отперается с блелка. Так вот прошло пол часа-час. Ему понадобилась машина. Он к ней... А черт — сказал он — а машина то не открывается. Компьютера думаю там нет в помине. Но сам факт забавен. Причем не ясно, то ли у брелка батарейка села, то ли что-то глючит. Если последнее, то 150 баксов за эвакуатор и в ремонт. В общем, кайф сплошной от электроники.
    ... << RSDN@Home 1.1.4 beta 3 rev. 279>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[16]: Системность
    От: VladD2 Российская Империя www.nemerle.org
    Дата: 15.02.05 14:18
    Оценка:
    Здравствуйте, serg_mo, Вы писали:

    СГ>>Короче говоря, в языках Java и C# просто нету возможности создавать системно необходимые типы данных.


    _>А что это за типы данных такие?


    Например, есть такие native int — число равное машинному слову. В принципе может поднять эффективность на платформах где оно не вписывается в один из целочисленных типов.
    ... << RSDN@Home 1.1.4 beta 3 rev. 279>>
    Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
    Re[17]: Системность
    От: serg_mo  
    Дата: 15.02.05 17:15
    Оценка:
    Здравствуйте, VladD2, Вы писали:

    VD>Например, есть такие native int — число равное машинному слову. В принципе может поднять эффективность на платформах где оно не вписывается в один из целочисленных типов.


    Ага, т. е. системные типы данных — это типы данных, которые имеют поддержку со стороны аппаратуры.

    Сергей в своем посте привел примеры размещения переменных на стеке и в динамической области памяти. Честно говоря, я не совсем понимаю, почему явная возможность указания того, как распределять объект — на стеке или в динамической области — должно давать преимущество Оберону в embedded systems. В чем проигрыш, например, Java, которая позволяет размещать объекты _только_ в динамической области?
    ... << RSDN@Home 1.1.3 stable >>
    Re[18]: Системность
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 15.02.05 17:42
    Оценка:
    Здравствуйте, serg_mo, Вы писали:


    _>Сергей в своем посте привел примеры размещения переменных на стеке и в динамической области памяти. Честно говоря, я не совсем понимаю, почему явная возможность указания того, как распределять объект — на стеке или в динамической области — должно давать преимущество Оберону в embedded systems. В чем проигрыш, например, Java, которая позволяет размещать объекты _только_ в динамической области?

    В скорости и нагрузке на GC. При использовании стека GC просто не подключается (правда нужно учитывать финнализаторы, но если их нет то и проблем нет)
    Отсутствие вяве структу плохо влияет на скорость массивов в том числе хэш таблиц сортированных списков итд.
    http://gzip.rsdn.ru/Forum/?mid=592884
    Автор: Serginio1
    Дата: 02.04.04

    http://gzip.rsdn.ru/Forum/?mid=592884
    Автор: Serginio1
    Дата: 02.04.04
    ... << RSDN@Home 1.1.4 beta 4 rev. 303>>
    и солнце б утром не вставало, когда бы не было меня
    Re[19]: Системность
    От: serg_mo  
    Дата: 16.02.05 11:41
    Оценка:
    Здравствуйте, Serginio1, Вы писали:

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


    S> В скорости и нагрузке на GC. При использовании стека GC просто не подключается (правда нужно учитывать финнализаторы, но если их нет то и проблем нет)

    S> Отсутствие вяве структу плохо влияет на скорость массивов в том числе хэш таблиц сортированных списков итд.
    S> http://gzip.rsdn.ru/Forum/?mid=592884
    Автор: Serginio1
    Дата: 02.04.04

    S> http://gzip.rsdn.ru/Forum/?mid=592884
    Автор: Serginio1
    Дата: 02.04.04


    И все? Хм... Как-то несолидно. С тем же успехом можно сказать, что язык, компилируемый в байт-код, нельзя назвать системным, т. к. он проигрывает в скорости скомпилированным в машинный код программам.

    ИМХО, должны быть какие-то более весомые аргументы.
    ... << RSDN@Home 1.1.3 stable >>
    Re[20]: Системность
    От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
    Дата: 16.02.05 11:49
    Оценка:
    Здравствуйте, serg_mo, Вы писали:

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


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


    S>> В скорости и нагрузке на GC. При использовании стека GC просто не подключается (правда нужно учитывать финнализаторы, но если их нет то и проблем нет)

    S>> Отсутствие вяве структу плохо влияет на скорость массивов в том числе хэш таблиц сортированных списков итд.
    S>> http://gzip.rsdn.ru/Forum/?mid=592884
    Автор: Serginio1
    Дата: 02.04.04

    S>> http://gzip.rsdn.ru/Forum/?mid=592884
    Автор: Serginio1
    Дата: 02.04.04


    _>И все? Хм... Как-то несолидно. С тем же успехом можно сказать, что язык, компилируемый в байт-код, нельзя назвать системным, т. к. он проигрывает в скорости скомпилированным в машинный код программам.


    _>ИМХО, должны быть какие-то более весомые аргументы.


    Не совсем. Сейчас у Явы уже давно свой JIT в Net он изначально существует. И основная причина нападок нативных программистов как раз касается скорости. Введение в Net валуе типов резко сократило разность по скорости. Кроме всего прочего при применении больших модифицирующихся массивов (списков ) вступает райт бариер который начинает существенно торморзить как в Net так и Java (в десятки раз сильно напрягая GC)
    ... << RSDN@Home 1.1.4 beta 4 rev. 303>>
    и солнце б утром не вставало, когда бы не было меня
    Re[5]: Оберон vs все остальное
    От: mister-AK Россия  
    Дата: 16.02.05 13:53
    Оценка:
    Здравствуйте, Сантехник, Вы писали:

    С>Здравствуйте, Трурль, Вы писали:


    Т>>Трудно проидумать что-либо более уродливое, чем C#.


    С>Объясни, если не трудно, что именно тебе в нем кажется уродливым.


    навскидку:
    1. приведение типов по колличеству написания скобочек проигрывает делфям в 1,5 раза
    2. количество атрибутов private/protected/public стремиться к колличеству полей в классе
    3. определен тип или переменная в классе сходу заметно?
    Re[6]: Оберон vs все остальное
    От: Cyberax Марс  
    Дата: 16.02.05 13:57
    Оценка:
    mister-AK пишет:

    > Т>>Трудно проидумать что-либо более уродливое, чем C#.

    > С>Объясни, если не трудно, что именно тебе в нем кажется уродливым.
    > навскидку:
    > 1. приведение типов по колличеству написания скобочек проигрывает
    > делфям в 1,5 раза

    Фигня...

    > 2. количество атрибутов private/protected/public стремиться к

    > колличеству полей в классе

    Ага, "настоящие парни" делают все поля public...

    > 3. определен тип или переменная в классе сходу заметно?


    Да.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[5]: Оберон vs С#
    От: mister-AK Россия  
    Дата: 16.02.05 14:01
    Оценка:
    Здравствуйте, Silver_s, Вы писали:

    S_>А может лучше так? C# такое на ура проглотит, главное не окосеть самому.



    S_>
    S_>public delegate Action Action(Action Action);
    S_>class Insane
    S_>{
    S_>    Action Action(Action Action)
    S_>    {
    S_>        Action(Action);
    S_>        return Action;
    S_>    }
    S_>    public void Call()
    S_>    {
    S_>        Action(new Action(Action));
    S_>    }
    S_>}
    S_>


    44:12 в пользу паскалеобразности
    Re[7]: Оберон vs все остальное
    От: mister-AK Россия  
    Дата: 16.02.05 15:13
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    я писал:
    >> 1. приведение типов по колличеству написания скобочек проигрывает
    >> делфям в 1,5 раза

    C>Фигня...


    шарп-фанат?

    >> 2. количество атрибутов private/protected/public стремиться к

    >> колличеству полей в классе

    C>Ага, "настоящие парни" делают все поля public...


    угу, смешно

    >> 3. определен тип или переменная в классе сходу заметно?


    C>Да.


    субъектив
    Re[8]: Оберон vs все остальное
    От: Cyberax Марс  
    Дата: 16.02.05 15:23
    Оценка:
    mister-AK пишет:

    > я писал:

    >>> 1. приведение типов по колличеству написания скобочек проигрывает
    >>> делфям в 1,5 раза
    > C>Фигня...
    > шарп-фанат?

    С++-фанат, но вполне осознаю, что Java/C# — замечательные инструменты
    для многих задач.

    >>> 2. количество атрибутов private/protected/public стремиться к

    >>> колличеству полей в классе
    > C>Ага, "настоящие парни" делают все поля public...
    > угу, смешно

    Какой вопрос — такой ответ.

    >>> 3. определен тип или переменная в классе сходу заметно?

    > C>Да.
    > субъектив

    Какой вопрос — такой ответ.

    --
    С уважением,
    Alex Besogonov (alexy@izh.com)
    Posted via RSDN NNTP Server 1.9
    Sapienti sat!
    Re[9]: Оберон vs все остальное
    От: mister-AK Россия  
    Дата: 16.02.05 15:28
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>mister-AK пишет:


    >> я писал:

    >>>> 1. приведение типов по колличеству написания скобочек проигрывает
    >>>> делфям в 1,5 раза
    >> C>Фигня...
    >> шарп-фанат?

    C>С++-фанат, но вполне осознаю, что Java/C# — замечательные инструменты

    C>для многих задач.

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

    >>>> 2. количество атрибутов private/protected/public стремиться к

    >>>> колличеству полей в классе
    >> C>Ага, "настоящие парни" делают все поля public...
    >> угу, смешно

    C>Какой вопрос — такой ответ.

    вопрос задавал не я, попутал ты малёк
    Re[6]: Оберон vs все остальное
    От: Sinclair Россия https://github.com/evilguest/
    Дата: 17.02.05 06:00
    Оценка:
    Здравствуйте, mister-AK, Вы писали:

    MA>навскидку:

    MA>1. приведение типов по колличеству написания скобочек проигрывает делфям в 1,5 раза
    Оччень интересно.
    (int)i

    супротив
    int(i)

    Может, у меня проблемы с устным счетом?
    MA>2. количество атрибутов private/protected/public стремиться к колличеству полей в классе
    Это верно. Тут уж выбирать — либо размечать атрибуты зонами (как в Delphi), либо приписывать к каждому мемберу. Предпочли второе, т.к. с учетом присутствия тел методов отслеживать текущую область видимости становится крайне неудобно.
    MA>3. определен тип или переменная в классе сходу заметно?
    Вот этого я не понял. Это про трудности отличения
    private int _someIdentifier=0;

    от
    public class SomeIdentifier
    {
    }

    ? Странно. Ни разу с такой проблемой не сталкивался.
    ... << RSDN@Home 1.1.4 beta 4 rev. 303>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    Re[9]: Оберон vs все остальное
    От: Кодт Россия  
    Дата: 18.02.05 00:25
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    C>>Кстати, а как твоим функциям передавать КОНТЕКСТ вычислений? Или как обычно, через глобальные переменные?


    СГ>Да.


    СГ>Только глобальные переменные в модульных языках — это вовсе не тоже самое что глобальные переменные в не модульных языках. В модульных языках все переменные находятся внутри модулей, а модули загружаются в память и выгружаются из нее динамически во время работы программы — то есть никакие они (переменные) вовсе не "глобальные" в строгом смысле этого слова.


    Значит, реентерабельность, а тем более параллелизм идут лесом.

    СГ>Впрочем, если возникает необходимость в нескольких контекстах вычисления одновременно, то Вы правы, тут уже надо использовать ООП, и смысл в именно такой функции какую просил я значительно снижается — ведь можно использовать для того же самого другие средства уже свойственные только ООП.


    Старое доброе процедурное программирование никто не отменял. Контекст передаётся как параметр. Если уж так хочется без ООП.
    Перекуём баги на фичи!
    Re[11]: Оберон vs все остальное
    От: Кодт Россия  
    Дата: 18.02.05 00:26
    Оценка:
    Здравствуйте, Сергей Губанов, Вы писали:

    C>>Плевать, два потока, исполняющие один код я запустить уже не смогу.

    C>>А контекст нужно передавать ВСЕГДА (в 99.99% случаев), иногда только
    C>>можно для целей оптимизации использовать глобальные переменные.

    СГ>А если система встроенная и там потоков нет?


    Достаточно прерываний.
    Перекуём баги на фичи!
    Re[12]: Оберон vs все остальное
    От: Кодт Россия  
    Дата: 18.02.05 00:30
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

    C>Кстати, на С такая функция будет выглядеть так:

    C>void* func(void* someFunc)
    C>{
    C>    return someFunc;
    C>}
    
    C>...
    C>void funcPtr=func(&func);
    C>assert(funcPtr==&func);

    C>Хотя нетипобезопасно получается, но во встроенных системах (если уж о них разговор) это обычно не так важно.

    Поправочка. В общем случае void* и void(*)() неприводимы друг к другу.
    typedef void(*voidfunc)();
    
    typedef voidfunc(*automate)(voidfunc);
    
    voidfunc foo(voidfunc f) { return rand()%2 ? f : bar; }
    voidfunc bar(voidfunc f) { return rand()%2 ? f : foo; }
    
    int main()
    {
      automate f = foo, g = bar;
      for(int i=0; i<10; ++i) f=(automate)(g(f)), g=f;
    }
    Перекуём баги на фичи!
    Re[6]: Оберон vs все остальное
    От: Сантехник Беларусь  
    Дата: 21.02.05 07:15
    Оценка:
    Здравствуйте, mister-AK, Вы писали:

    Т>>>Трудно проидумать что-либо более уродливое, чем C#.


    С>>Объясни, если не трудно, что именно тебе в нем кажется уродливым.


    MA>навскидку:

    MA>1. приведение типов по колличеству написания скобочек проигрывает делфям в 1,5 раза



    MA>2. количество атрибутов private/protected/public стремиться к колличеству полей в классе


    Ага, намного удобнее лазить по простыням C++ кода, выискивая, в каком visibility scope объявлено поле.

    MA>3. определен тип или переменная в классе сходу заметно?


    Никаких проблем. Особенно учитывая способности современных IDE подсвечивать и "интеллисенсить" всю необходимую
    инфу на лету.

    Резюмируя: Не кажется, что этих аргументов, тем более сугубо "имховых", недостаточно, чтобы называть язык "уродливым"?
    ... << RSDN@Home 1.1.4 beta 3 rev. 264>>
    Re[6]: Оберон vs все остальное
    От: Andrew.Kroupa  
    Дата: 06.03.05 11:31
    Оценка:
    Кё>>>Загадка 3. Как часто мне приходилось решать твою загадку на пракике?

    СГ>>Наверное Вы ее встретили в первый раз здесь. Ранее она просто в голову не могла придти. Язык ограничивает мышление.


    Кё>В конечном автомате Action наверняка будет объектом. Не только выполняемым, но и наверняка со свойствами/данными.


    Или так:


    class Action
    {
       ...
       public:
       Action& operator()(Action& param);
    } IAction;
    
    
    IAction=IAction(IAction);



    Наслаждайтесь
     
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.