Нужна ли Оберон-ОС защита памяти? - Философия программирования

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

AVC>Обсуждение языка и ОС Оберон у нас постоянно пересекаются.
AVC>Ведь ОС Оберон основывается именно на свойствах одноименного языка.

И это приводит к неслабой путанице. Особенно если учесть, что в руководстве по Оберону сказано: среда не является частью языка, однако до некоторой степени подразумевается при определении языка.

AVC>Полную историю книги не знаю.
AVC>Знаю только, что предыдущее издание книги содержало программы на Паскале.
AVC>Отсюда, видимо, и некоторое разочарование авторов в Си++.

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

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

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

Здравствуйте, Кодт, Вы писали:

К> Пусть некий активный объект владеет стеком своего потока

Э-э-э, бывает либо одно либо другое:

1) Обычная (не объектно ориентированная) ОСь с процессами/потоками.
2) Активные объекты как основа построения полностью объектно ориентированной ОСи.

Там где есть процессы/потоки — там нет активных объектов, и наоборот.

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

AVC,

> Вообще, интересное поведение компилятора: он не контролирует запрещенную конструкцию.

Конструкция не запрещена. У нее есть вполне законные варианты использования. Запрещено подмножество сценариев использования, включающих запись в один член, а чтение из другого. Компилятор эти варианты в общем случае отследить не может. Систему исполнения этим нагружать стандарт не требует, но и не запрещает: исключение в результате неверного использования — одно из возможных последствий, если так решат разработчики конкретного компилятора.

Posted via RSDN NNTP Server 1.9

AVC,

> C> Кстати, MSVC на такой код выдает предупреждение.

> Еще раз проверил на MSVC. Опять без warningов.

/Wall ?

Posted via RSDN NNTP Server 1.9

Здравствуйте, Павел Кузнецов, Вы писали:

>> Еще раз проверил на MSVC. Опять без warningов.

ПК>/Wall ?

командная строка:

cl /W4 /WX bool2float.cpp

Ни warningа, ни ошибки компиляции.
Наверное, версия компилятора устарела (MSVC 6.0)?

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

К>> Пусть некий активный объект владеет стеком своего потока

СГ>Э-э-э, бывает либо одно либо другое:

СГ>1) Обычная (не объектно ориентированная) ОСь с процессами/потоками.
СГ>2) Активные объекты как основа построения полностью объектно ориентированной ОСи.

СГ>Там где есть процессы/потоки — там нет активных объектов, и наоборот.

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

Развей моё невежество, пожалуйста.
Мне кажется, что понятие "стек" и "поток" — более широки, чем поддержанные аппаратно простейшие реализации того и другого.
Если рассматривать активный объект как сущность, чьё текущее состояние описывается LIFO-цепочкой (т.е. стеком) фреймов, а поведение тактируется неким произвольным источником (внутренним или внешним, event-driven) — то принципиально ничего не поменялось.

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

AVC>>Обсуждение языка и ОС Оберон у нас постоянно пересекаются.
AVC>>Ведь ОС Оберон основывается именно на свойствах одноименного языка.
P>И это приводит к неслабой путанице. Особенно если учесть, что в руководстве по Оберону сказано: среда не является частью языка, однако до некоторой степени подразумевается при определении языка.

Возможно.
Я и сам задавал себе вопрос, почему используется одно и то же имя.
(Не как с Модулой-2: там были Modula-2 и Lilith соответственно.)
Единственное, что пришло в голову: система очень "завязана" на язык.
Обратное не верно. Язык может использоваться и в другой среде.

P>К сожалению, на сайте издательства сказано, что книга больше не продается. Все равно спасибо за ссылку.

Увы...

Поискал через
http://www.booksearch.ru
Никто не отозвался.
Может, переиздадут?

P>Действительно, язык мог быть и Паскаль, там упоминается о локальных процедурах. Меня смутило заявление о многомерных массивах, которые, кроме Фортрана, нигде не существуют, а организованы с помощью массивов меньших размерностей.

Это место я пока не понял.
В Обероне (а после него — в Java и C#) гибкие многомерные массивы вроде бы присутствуют...

P>А вообще-то дискуссия перерастает в треп, скоро кулаки рисовать будут (или еще что-нибудь). Неприятно, когда отсутствие аргументов заменяется разбрасыванием минусов или, что хуже, личными нападками или репликами типа "сам такой".

И это очень жаль...

AVC пишет:

>>> *Сильная* типизация — это такая типизация, которую *нельзя* обойти.
> C>Нет. Сильную типизацию нельзя обойти НЕЯВНО.
> C>А руками _заставить_ привести — очень даже и можно ...
> В том-то и проблема, что в Си++ нельзя отличить программы, в которых
> было использовано такое "приведение руками", от программ, в которых
> такого приведения не было.

Да, но есть средства (namspace'ы, например), позволяющие избежать многих
проблем со сторонним кодом.

> C>Затем, что иногда бывают полезны для других целей. Классический пример:
> C>
>
>C>union BIGINT
>C>{
>C> struct Ints
>C> {
>C> int i1,i2;
>C> };
>C> struct Bytes
>C> {
>C> byte b1,b2,b3,b4,b5,b6,b7,b8;
>C> };
>C>}
>C>
>
>
> О чем я и говорил: сильной типизации в Си++ нет.

Есть. Типу BIGINT присвоить int не получится, просто у типа семантика
BIGINT несколько отличается от обычной структуры.

>>> Используемые в нем алгоритмы сначала были написаны на Си++

> C>Есть такая проблема — все дело в том, что bool был добавлен в язык
> очень
> C>поздно. Кстати, MSVC на такой код выдает предупреждение.
> Еще раз проверил на MSVC. Опять без *warning*ов.

Какой уровень предупреждений?

>>> Чудо, что за *сильно типизированный язык*!
> C>А он вполне сильно типизирован. И преобразование bool->float вполне
> себе
> C>валидно.
> Правда?!
> А вот мне, дурню, кажется, что между bool и float нет *ничего общего*.
> Поэтому и *неявное* преобразование *недопустимо*.

Это уже другой вопрос — неявное приведение типов. Тут как обычно: С++
дает достаточно веревки чтобы повеситься.

> C>Да, да, конечно же. Всякие uBlas, и т.п. — все полная фигня.
> C>И еще С++ неприспособлен для векторных вычислений, о чем наглядно
> C>свидетельствует http://www.pixelglow.com/macstl/
> C>И для параллельного программирования тоже не приспособлен, так как
> C>документа http://www.openmp.org/drupal/mp-documents/cspec20_bars.pdf
> нет
> C>в природе.
> Подождите.
> Ведь в приведенной мной цитате *все правда*.
> Многомерных массивов нет.

boost::multi_array.

> Модулей нет.

Есть. Например, в виде COM.

> Индексы — если и можно контролировать, то только в отдельных случаях.

Для каждого отдельного случая — есть.

> А существование где-то там пары навороченных библиотек не имеет к
> данному вопросу никакого отношения.

Отношение имеет то, что ЯЗЫК позволяет их организовать — этим С++ и
уникален, он позволяет делать практически все. А вот в Обероне как ни
старайся, но типизированные коллекции в общем виде не сделать. И не надо
говорить, что они не нужны.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

> Там где есть процессы/потоки — там нет активных объектов, и наоборот.

Ваш "активный объект" — это и есть поток.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Posted via RSDN NNTP Server 1.9

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

AVC>Увы... :(
AVC>Поискал через
AVC>http://www.booksearch.ru
AVC>Никто не отозвался.
AVC>Может, переиздадут?

Хорошо бы. Ладно, потерпим...

AVC>Это место я пока не понял.
AVC>В Обероне (а после него — в Java и C#) гибкие многомерные массивы вроде бы присутствуют...

  ARRAY L0, L1, ..., Ln OF T

понимается как сокращение:

   ARRAY L0 OF
     ARRAY L1 OF
     ...
        ARRAY Ln OF T

(из руководства по языку Оберон).
T — это "настоящий" многомерный массив или он определен так же, как в C++, через одномерные?

До C# еще не дошел, не всегда волен выбирать себе инструмент для работы.

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

C>AVC пишет:

>> В том-то и проблема, что в Си++ нельзя отличить программы, в которых
>> было использовано такое "приведение руками", от программ, в которых
>> такого приведения не было.
C>Да, но есть средства (namspace'ы, например), позволяющие избежать многих
C>проблем со сторонним кодом.

Каким образом?

>> C>поздно. Кстати, MSVC на такой код выдает предупреждение.
>> Еще раз проверил на MSVC. Опять без *warning*ов.
C>Какой уровень предупреждений?

Максимальный для моего компилятора (MSVC 6.0).
Командная строка:

cl /W4 /WX bool2float.cpp

>> А вот мне, дурню, кажется, что между bool и float нет *ничего общего*.
>> Поэтому и *неявное* преобразование *недопустимо*.
C>Это уже другой вопрос — неявное приведение типов. Тут как обычно: С++
C>дает достаточно веревки чтобы повеситься.

Я не "ругаю" Си++ "вообще". (Самому на нем приходится писать.)
Я только утверждаю, что он не является сильно типизированным, простым и надежным.
Скажу прямо, я считаю эти свои утверждения очевидными, и не могу понять несогласия в данных пунктах.

>> Многомерных массивов нет.
C>boost::multi_array.

Гибких (что я забыл упомянуть в первый раз

) многомерных массивов в языке Си++ нет.
А библиотечная поддержка и в Visual Basic может быть.

>> Модулей нет.
C>Есть. Например, в виде COM.

Опять же, COM — не часть языка Си++.

>> Индексы — если и можно контролировать, то только в отдельных случаях.
C>Для каждого отдельного случая — есть.

Вот это и есть путь PL/1 — "для каждого отдельного случая".

>> А существование где-то там пары навороченных библиотек не имеет к
>> данному вопросу никакого отношения.
C>Отношение имеет то, что ЯЗЫК позволяет их организовать — этим С++ и
C>уникален, он позволяет делать практически все. А вот в Обероне как ни
C>старайся, но типизированные коллекции в общем виде не сделать. И не надо
C>говорить, что они не нужны.

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

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

Как мне кажется, обсуждение типизации в Си++ потихоньку перерастает во флейм.
Сторонники Си++ предпочитают вообще не видеть проблем своего любимого (и ради Бога!) языка. Главная же проблема — что Си++ сам становится проблемой. Такое чувство, что его уже никто (кроме Страуструпа и Павла Кузнецова

) полностью и не знает.

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

AVC>>Это место я пока не понял.
AVC>>В Обероне (а после него — в Java и C#) гибкие многомерные массивы вроде бы присутствуют...

P>

P>  ARRAY L0, L1, ..., Ln OF T
P>

P>понимается как сокращение:
P>

P>   ARRAY L0 OF
P>     ARRAY L1 OF
P>     ...
P>        ARRAY Ln OF T
P>

P>(из руководства по языку Оберон).
P>T — это "настоящий" многомерный массив или он определен так же, как в C++, через одномерные?

Гм.

Честно говоря, и сейчас не понял.
Память подсказывает, что в Фортране линеаризация была по столбцам, а не по строкам, как в других языках. Других особенностей что-то не припомню.

На всякий случай, расскажу еще раз, что когда-то был приятно удивлен, узнав, что матрицы в Обероне могут иметь произвольное число столбцов, в отличие от Си, Си++ и Паскаля.
Например:

TYPE Matrix = ARRAY OF ARRAY OF REAL;

Здравствуйте, Кодт, Вы писали:

КЕ>>>

ну вы блин даете...
КЕ>>>А если бы потребовалось возвращать знак числа, то добавили бы приведение к int?
AVC>>Видно, возмущение было столь сильным, что на критику уже слов не хватило?

К>На самом деле, возмущение справедливое.

Прошу прощения, что задерживаюсь с ответом.
Не успеваю...

У Вас именно аргументация, хочется вникнуть.

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

AVC>На всякий случай, расскажу еще раз, что когда-то был приятно удивлен, узнав, что матрицы в Обероне могут иметь произвольное число столбцов, в отличие от Си, Си++ и Паскаля.
AVC>Например:
AVC>

AVC>TYPE Matrix = ARRAY OF ARRAY OF REAL;
AVC>

В Quick/Visual Basic тоже

Кстати, а это именно прямоугольник, или массив с рваным краем (jagged array) ?
Потому что рваный край — в С++ делается просто: vector<vector<T> >
Впрочем, написать класс матрицы и вообще гипер-кирпича с переменными размерами — тоже как два пальца об асфальт.

Кстати. То, что в С++ это делается не на уровне языка, а с помощью библиотек (в Фортране, кстати, тоже; без библиотек Фортран был бы нищ, как полковник Кудасов), — содержит большое достоинство.

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

К>4) Наконец, компилятор VC даёт предупреждение о приведении к bool и из bool в число. (Про другие компиляторы — врать не буду). Кому хочется развлечений — включайте опцию "treat warnings as errors" и наслаждайтесь.

Здесь я погнал. bool в число перевести — как нефиг делать.

false==0, true==1.
Здесь он от enum Bool {False,True} не отличается.

И, в ряде случаев, это фича.

Здравствуйте, Кодт, Вы писали:

КЕ>>>

К>На самом деле, возмущение справедливое.

Подумал я и... в чем-то согласился.

Действительно, возмущение (отчасти) справедливое.

Сейчас попробую восстановить по шагам, как все случилось.
(Опускаю малосущественные детали.)

К>2) Практика показывает, что приведение к bool носит двоякий характер:
К>* по смыслу — проверка валидности, непустоты и т.п.
К>* по форме — сравнение с нулём.
К>В случае числовых типов сравнение с нулём обычно определено; поэтому вводить дополнительно operator bool(), несущий иной смысл — это рассогласовывать форму и содержание.

1) В тот момент, когда выяснилось, что происходит неявное преобразование bool к float, мы все находились в состоянии большой спешки. (В 21.00 нас с позором изгоняет охрана.

) Поэтому, когда выяснилось, что все дело в закомментированном операторе float(), я его самолично раскомментировал, и мы с помпой получили требуемый тестовый набор. После чего поспешили к VHDL-симулятору.
2) Удаляя "//", я успел краем глаза заметить, что в операторе bool() происходит выделение экспоненты из битового представления "флота" с помощью

& 0x7f800000

. Если кто помнит битовое представление float, тот сразу "смекнет", что здесь анализируется экспонента. Я (на свою беду) помнил, т.к. в свое время была у нас маленькая проблема с "ужатием" float без потери действительно значимых цифр. (Требовалось передавать данные измерений в очень коротком пакете.)
3) Вижу я, значит, выделение экспоненты и машинально про себя думаю: "Зачем это может быть в операторе bool()?"
Не иначе, для проверки валидности "флота". (Если все биты экспоненты выставлены в единицу, то у нас или INFINITY, или NaN.) Так у меня и отложилось в сознании, и так я и написал в комментарии к bool(), когда излагал схему "происшествия" в своем посте.
4) Сейчас заглянул в код повторно и вижу: экспонента-то сравнивается с нулем.
Т.е. в действительности происходит рядовая проверка на 0, а не на "валидность" (не INFINITY и не NaN).
Если экспонента равна 0, то число всегда 0 (возможно, со знаком: +0 или -0).
Что тут скажешь? Опять старый лопух дезинформировал общественность!

По сути дела, я осознал, что был не вполне прав, когда внушал Cyberax'у, что между bool и float нет ничего общего.
Это общее есть, и это общее — (дурацкая, все-таки, прости Господи! не могу больше молчать!

) манера писать на Си выражения вида if (x) для произвольного типа.
В нормальных языках пишут что-то вроде

if (x != 0.0)

или

if (p != NULL)

и т.п.

К>В случае с Float — нужен ли был этот оператор, или просто руки шаловливые оказались?

Все зависит от реализованных алгоритмов.
Если при нулевой экспоненте возможна ненулевая мантисса, то оператор нужен.
Т.к. обычное сравнение

if (x)

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

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

КЕ>>

ну вы блин даете...
КЕ>>А если бы потребовалось возвращать знак числа, то добавили бы приведение к int?

AVC>Видно, возмущение было столь сильным, что на критику уже слов не хватило?

Скорее удивление, сорри что не пояснил. Ты только что говорил о неявных приведениях в cpp как о зле (и я согласен), но приводишь пример, увеличивающий это самое зло.

Приведение float к bool возвращает false для 0.0 и true для остальных значений. А класс Float неявно приводится к float, и в то же время неявно приводится к bool, но по каким-то своим законам, отличным от float. Это никак не добавляет понятности в программу. Лучше ввести функцию is_valid() или типа того.

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, Костя Ещенко, Вы писали:
К>

AVC>>>    // в реальной программе bool() проверяет валидность Float
AVC>>>    operator bool() { return true; }
КЕ>>

КЕ>>

ну вы блин даете...
КЕ>>А если бы потребовалось возвращать знак числа, то добавили бы приведение к int?

К>Оказывается, специально для этого в С++ придуман workaround — возвращать тип, приводимый к bool, но ни к чему другому. Что-то вроде
К>

К>class Foo
К>{
К>public:
К>  typedef void (Foo::*some_bool)();
К>private:
К>  void some_true() {}

К>public:
К>  operator some_bool() const { if(...) return &Foo::some_true : 0; }

К>  ...
К>};
К>

К>(Недавно было в форуме C++, да и в boost видел — но не помню точно, как он там называется).

Это мне известно. Но даже если сделать так, тип Float из примера AVC будет приводиться к bool совсем по иным правилам, нежели float, что не есть хорошо.

К>Вообще же, в ряде случаев имеет смысл делать внешние функции либо хотя бы по-человечески названные методы
К>

К>bool is_valid(double v); // проверка на NaN и Inf - встроенными средствами
К>bool is_valid(float v);
К>bool is_valid(const Float& v) { return v.is_valid(); }
К>

Полностью согласен.

	От:	Privalov
	Дата:	08.02.05 14:27
	Оценка:

От:	Сергей Губанов	http://sergey-gubanov.livejournal.com/
Дата:	08.02.05 14:32
Оценка:

	От:	Павел Кузнецов
	Дата:	08.02.05 14:36
	Оценка:	+1

	От:	Павел Кузнецов
	Дата:	08.02.05 14:38
	Оценка:

	От:	AVC
	Дата:	08.02.05 14:47
	Оценка:

	От:	Костя Ещенко
	Дата:	08.02.05 23:10
	Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	09.02.05 05:09
Оценка: