Здравствуйте, Oleg A. Bachin, Вы писали:

OAB>куда еще шортее чара! )
OAB>или это желание выпендриться? типа это у вас вайды всякие, а у нас просто чары, а выши чары у нас шорт?

Это Component Pascal.

CHAR — 2 байта, SHORTCHAR — 1 байт.

(Идентификаторы можно писать хоть на русском, хоть на китайском языке.)

OAB>и еще, я так понял char->byte преобразование невозможно? а как же битовые операции? а как же совместимость на уровне АПИ!?

Да, совершенно верно. Мухи и котлеты отдельно. Буквы это буквы, числа это числа, а множества это множества.

Впрочем, буквы упорядочены, так что их можно сравнивать >, <, <=, >=, =, #. Можно узнать порядковый номер буквы int := ORD(char), и наоборот, по порядковому номеру получить букву char := CHR(int). ORD и CHR — это стандартные предопределенные инструкции.

Про битовые операции отдельная история.

В математике есть объект — множество. Множества можно объединять, строить пересечение множеств, дополнение и т.д. Так вот в Обероне есть специальный тип SET, он представляет собой математическую абстракцию множества (из элементов: 0, 1, 2,..., MAX(SET)).
http://www.inr.ac.ru/~info21/cpascal/cp_report_1.4_rus.htm

8.2.3 Операции над множествами
+ объединение
— разность (x — y = x * (-y))
* пересечение
/ симметричная разность (x / y = (x-y) + (y-x))

Операции над множествами применимы к операндам типа SET и дают результат типа SET. Одноместный минус обозначает дополнение множества x, т.е. -x обозначает множество целых от 0 до MAX(SET), которые не являются элементами множества x. Операции над множествами не являются ассоциативными ((a+b)-c # a+(b-c)).

Конструктор множества определяет значение множества перечислением его элементов между фигурными скобками. Элементы должны быть целыми в диапазоне 0..MAX(SET). Диапазон a..b обозначает все целые i такие, что i >= a и i <= b.

Кстати, симметричная разность множеств c := a / b; — это то, что в других, менее математизированных, языках называется по простому — xor.

Все множества перенумерованы, так что можно превращать множества в числа просто по их номеру int := ORD(set); существует обратное преобразование: set := BITS(int); Причем, 0 соответствует пустому множеству {},



{} = BITS(0)
{0} = BITS(1)
{1} = BITS(2)
{0, 1} = BITS(3)
{2} = BITS(4)
{0, 2} = BITS(5)
{1, 2} = BITS(6)
{0..2} = BITS(7)
{3} = BITS(8)
{0, 3} = BITS(9)
{1, 3} = BITS(10)
{0, 1, 3} = BITS(11)
{2, 3} = BITS(12)
{0, 2, 3} = BITS(13)
{1..3} = BITS(14)
{0..3} = BITS(15)
{4} = BITS(16)
...

и т.д. не зависимо от платформы (little- или big- endian), что делает "битовые операции" не зависимыми от платформы.

Добавление i-того элемента во множество s записывается так: INCL(s, i)
Исключение i-того элемента из множества s записывается так: EXCL(s, i)
Проверить существование элемента i во множестве s можно так: IF i IN s THEN ... END

Например инструкция: if(i & 0x00ff0000 == 0){...}, записывается так: IF BITS(i) * BITS(00FF0000H) = {} THEN ... END.

Вобщем так, в Обероне буквы, числа, булевы значения, множества - это 4 совершенно разных типа.

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

OAB>>и еще, я так понял char->byte преобразование невозможно? а как же битовые операции? а как же совместимость на уровне АПИ!?
СГ>Да, совершенно верно. Мухи и котлеты отдельно. Буквы это буквы, числа это числа, а множества это множества.
...

СГ>Впрочем, буквы упорядочены, так что их можно сравнивать >, <, <=, >=, =, #. Можно узнать порядковый номер буквы int := ORD(char), и наоборот, по порядковому номеру получить букву char := CHR(int). ORD и CHR — это стандартные предопределенные инструкции.
и давно у нас chr(1), например, это буква?

СГ>Про битовые операции отдельная история.
отдельных историй много выходит — общей кртинки чет не видно...

СГ>В математике есть объект — множество. Множества можно объединять, строить пересечение множеств, дополнение и т.д. Так вот в Обероне есть специальный тип SET, он представляет собой математическую абстракцию множества (из элементов: 0, 1, 2,..., MAX(SET)).
мы только что говорили о битовых операциях! я разве спрашивал что-то про множества?
или это типа "у рыб есть чешуя, в чешуе не водятся блохи! строение блохи ... и поехали"!

СГ>Конструктор множества определяет значение множества перечислением его элементов между фигурными скобками. Элементы должны быть целыми в диапазоне 0..MAX(SET). Диапазон a..b обозначает все целые i такие, что i >= a и i <= b.

ой как гениально! ну стандартный паскалевкий сет. и назвать его чем-то полезным довольно таки трудно из-за тех же ограничений на инт, из-за невозможности дублирования значений, из-за... короче, реальное применение это фигни одно:

type
    option = (opt1, opt2 ... optn);
    options = set of option;

но по правде сказать довольно таки распространенное...

одна просьба, паскаль и делфи я знаю великолепно, хотелось бы услышать, чем так уникален Оберон, кроме как глупейшие ограничения?
меня например в делфи больше всего напрягает отсутствие темплейтов. потому как часто стандартные задачи приходится решать через опасные преобразования Pointer -> PMyType.
если запретить рассматривать блок памяти так как требует того моя задача — мне каждый раз ручками новый класс писать!?

СГ>Кстати, симметричная разность множеств c := a / b; — это то, что в других, менее математизированных, языках называется по простому — xor.
Оберон! где Оберон!!!??? это все сперто!!! а то мне нравится сравнение "в Джава все как в Обероне", а то что это все уперли из Object Pascal — молчек.

СГ>Добавление i-того элемента во множество s записывается так: INCL(s, i)
да, сперли...
СГ>Исключение i-того элемента из множества s записывается так: EXCL(s, i)
да, сперли...
СГ>Проверить существование элемента i во множестве s можно так: IF i IN s THEN ... END
да, сперли...

СГ>Вобщем так, в Обероне буквы, числа, булевы значения, множества - это 4 совершенно разных типа.
вобщем понятно... советую ознакомиться и осмыслить http://russian.joelonsoftware.com/Articles/BacktoBasics.html .

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

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

R>Зато можно очень резко поменять его отношение к некоторым конструкциям.

Как бы то ни было, прагма — это директива, а не условие.

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

CX>>Причем здесь лисп? Да ни причем. Ежу понятно, что C++ с функциональными языками в сфере метапрограммирования конкурировать не может. Ну так и не нужно. Разве ж этого кто добивался?

AVC>Дмитрий, мне кажется эта ветка флейма началась с твоего утверждения:
AVC>

AVC>Согласен. Сильно. Скажу тогда чуток послабже: "Из всех известных мне языков шаблонное, compile-time программирование присуще только C++". Но если я неправ и есть язык, поддерживающий эту концепцию столь же хорошо, как C++, покажите мне его. Я таких не нашел.

AVC>Народ понял тебя буквально.

Ага, я уже понял. Вообще-то я говорил не о специализированных языках. Так что моя недоработка.

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

CX>Ага, я уже понял. Вообще-то я говорил не о специализированных языках. Так что моя недоработка.

Common LISP, Nemerle, Java Syntactic Extender — языки общего назначения. Хотя последние два, конечно, не мейнстрим (но генерируют код для .NET CLR и JVM соответственно).

Здравствуйте, Oleg A. Bachin, Вы писали:

OAB>мы только что говорили о битовых операциях! я разве спрашивал что-то про множества?

Извините, забыл явно упомянуть, что битовые операции осуществляются над множествами битов.
SET — множество битов 0, 1, 2, ..., MAX(SET). Я думал это очевидно.

OAB>Оберон! где Оберон!!!??? это все сперто!!! а то мне нравится сравнение "в Джава все как в Обероне", а то что это все уперли из Object Pascal — молчек.

Это не правда потому, что Object Pascal появился в девяностых годах, но Модула 2 уже была в 1979 году.
Оберон появившийся в 1987 году "упер" всё из Модулы 2.

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

WF>Common LISP, Nemerle, Java Syntactic Extender — языки общего назначения. Хотя последние два, конечно, не мейнстрим (но генерируют код для .NET CLR и JVM соответственно).

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

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

Т>Подумаешь, бином Ньютона. Вот, пожалуйста:
Т>

Метапрограммирование- написание программ, которые используют программы в качестве данных.

Из этого определения следует, что огромная масса вирусов, заражающих исполняемые файлы, тоже являются метапрограммами.

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

E>>>А так же из-за невообразимо большого количество унаследованного кода и огромного количества активных проектов, выполняющихся на C++.
VD>>Эта проблема решаема.
E>Как?

1. По возможности заменять библиотечный код на управлеемый.
2. То что заменить нельзя обертывать или использовать через интероп.

В том же Янусе куча неуправляемогокода кода используемого через интероп.

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

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

E>>>>А так же из-за невообразимо большого количество унаследованного кода и огромного количества активных проектов, выполняющихся на C++.
VD>>>Эта проблема решаема.
E>>Как?

VD>1. По возможности заменять библиотечный код на управлеемый.
VD>2. То что заменить нельзя обертывать или использовать через интероп.

Фактически "ползучее" переписывание. И на какой язык ориентироваться? Вероятно, на Java, ведь аналогичную кроссплатформенную поддержку C# и .Net вряд ли получит (я подразумеваю не только сам язык, но и основные framework-и).

VD>В том же Янусе куча неуправляемогокода кода используемого через интероп.

Боюсь, что Янус слишком мелкий проект, чтобы быть показателем.

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

CX>>Все примеры, что ты приводил, относятся к той самой части языка, которая не type-safety и досталась в наследие от C. И конечно же, ты можешь неявно привести массив к указателю, обратиться за границы массива и т.д. и т.п. Компилятор тебе этого не запретит. Но кто тебя заставляет это делать? Никто.

VD>О, какя логика замечательная. Дык меня и на ассемблере никто не заставляет память портить. Пиши себе окуратно. Соблюдай паттерны и будет тебе счастье.

В отличие от C++ на ассемблере нет способа сделать так, чтоб компилятор ловил ошибки типизации. В C++ такие способы есть, так что аналогия некорректна.

VD> Скорости это не дает. <...>

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

Автор: Павел Кузнецов
Дата: 07.07.05

... Только не надо про R#: он совершенно не контролирует характер изменений AST

Автор: Павел Кузнецов
Дата: 16.06.05

, так что в случае его использования о какой-либо безопасности говорить (пока?) сложно...

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

ГВ>>Нет ничего удивительного в том, что для иллюстрации использования IS Вирт пользуется таким приёмом, в конце концов, иллюстрация есть иллюстрация. Никто же не заставляет, например, "в лоб" переносить объектные модели из книг Буча/Шлеера/и т.д. в реальные проекты (хотя некоторые горячие головы могут)!

AVC>Я использовал на практике метод Шлеер (мне кажется, это дама) и Меллора практически "в лоб".
Э! Я не о методе самом по себе, о конкретных моделях, приводимых как иллюстрации.

ГВ>>Так что, хотя такой "способ проектирования" и есть, но я бы не стал заявлять о нём, как о чём-то, имеющем ценность большую, чем сугубо иллюстративную.

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

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

AVC>(В этом огромное отличие от того кода, что привели Вы.)
+/-1

AVC>ИМХО, рассуждения о принципе подстановки Барбары Лисков в данном случае выглядят наивными.
Не согласен. В данном случае при проектировании функции диспетчеризации мы используем знание о наборе поступающих сообщений. Если источник сообщений добавит ещё одно-два, то придётся модифицировать клиентский код, который придётся разыскивать через search и т.п. Не есть бест солюшн на мой взгляд. Вариант с группировкой обработчиков по интерфейсам я полагаю более надёжным.

AVC>Здесь мы имеем дело с задачей двойной диспетчеризации, и это — ее самое простое (и универсальное) решение.
Ну... можно обобщить до ДД. Разумеется, если объекты сообщений сами содержат реализацию некоторой функциональности. Я же говорю, что дальнейший анализ нужно делать на основании конкретной задачи.

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

ГВ>>Однако, если сугубо формально, то анализ типа сообщения всё равно остаётся. Тем-то, кстати, и хорош LSP, что его нарушение можно определить по сугубо формальным признакам.
Т>Как раз по сугубо формальным признакам нарушений не видно.

Ну, здравствуйте! А цепочка IS — это что?

ГВ>>А такая техника обработки сообщений в общем-то, противоречит объектному стилю. Здесь причина зарыта достаточно глубоко и, ИМХО, начинается с того, что методы объектов сами по себе являются сообщениями, а внесение дублирующей структуры типа "сообщение" становится э... чем-то вроде тавтологии. Соответственно, нарушение фундаментального принципа тащит за собой нарушения и кучи других: архитектура смешивается, зависимости становятся неявными и т.п.

Т>Я бы не стал отождествлять методы объектов и сообщения. Методы — реакции на сообщения. А в крайнем случае реакция на любое сообщение может быть одной и той же (ignore, например.
Это верно только для случая, когда есть диспетчер сообщений, который сопоставляет структурам данных-сообщениям конкретные методы целевого объекта. Но само наличие диспетчера не всегда оправдано, ИМХО, за исключением таких случаев, как согласование с message-based-API типа Windows-API.

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

R>Реально будет использовано меньше. Длинные произведения делаются
R>inline-функциями. Поэтому небольшая автоматизация изврата — и
R>генерируются только используемые размерности. Хотя, конечно, получится
R>многовато, но искусство требует жертв. Благо, не человеческих, и даже не
R>усилий.

Ну-ксь, поверим гармонию алгеброй. Для 10^9 комбинаций, даже если на генерацию уходит 1 ms (оптимистично), то получим... 10^6 секунд на один проход генерации... Это... что-то около 11 дней на заход. Объём выходного файла при 50 символах на экземпляр ~50 ГБ.

Даже если срезать три порядка — всё равно невесело. А если ещё тестирование...

"Эх, не хило быть духовным!" (c)

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

AVC>>Дмитрий, мне кажется эта ветка флейма началась с твоего утверждения:
AVC>>

AVC>>Согласен. Сильно. Скажу тогда чуток послабже: "Из всех известных мне языков шаблонное, compile-time программирование присуще только C++". Но если я неправ и есть язык, поддерживающий эту концепцию столь же хорошо, как C++, покажите мне его. Я таких не нашел.

AVC>>Народ понял тебя буквально.

CX>Ага, я уже понял. Вообще-то я говорил не о специализированных языках. Так что моя недоработка.

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

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

ГВ>>>Нет ничего удивительного в том, что для иллюстрации использования IS Вирт пользуется таким приёмом, в конце концов, иллюстрация есть иллюстрация. Никто же не заставляет, например, "в лоб" переносить объектные модели из книг Буча/Шлеера/и т.д. в реальные проекты (хотя некоторые горячие головы могут)!
AVC>>Я использовал на практике метод Шлеер (мне кажется, это дама) и Меллора практически "в лоб".
ГВ>Э! Я не о методе самом по себе, о конкретных моделях, приводимых как иллюстрации.

А я сразу и не понял.
Действительно, было бы странно, если бы я использовал "в лоб" модель завода по производству соков.

ГВ>>>Так что, хотя такой "способ проектирования" и есть, но я бы не стал заявлять о нём, как о чём-то, имеющем ценность большую, чем сугубо иллюстративную.

AVC>>В некоторых случаях этому методу нет альтернативы.
AVC>>Он используется независимо от языка, как на Обероне, так и на Си.

ГВ>Не надо путать C и С++. Аналогичное решение на C++ выглядело бы как класс с чисто виртуальными методами. В общем-то, это надёжнее, поскольку была бы возможна группировка методов по целевому назначению и была бы гарантия того, что реализующий объект реализует _все_ методы некоторой группы. По крайней мере — он о них знает.

Предположим, Вам предложили переписать Windows заново на Си++.
Сколько чисто виртуальных методов Вы поместите в абстрактный класс "Окно"?
Примите во внимание, что, решив впоследствии добавить еще один виртуальный метод, Вы можете столкнуться с неразрешимой проблемой.

AVC>>Как например, Вы предложили бы реализовать рассылку сообщений в Windows?
AVC>>Приведенный Сергеем пример из книги Вирта просто демонстрирует, что в Обероне это делается безопасным путем.
ГВ>В смысле опасности некорректности приведения типов — да. В смысле опасности пропуска необходимых сообщений — нет.

Совершенно правильно.
Возможность игнорировать сообщение — достоинство такого подхода.
Опасность пропуска нужного сообщения тоже есть.
Равно как и опасность пропустить нужную ветку if в алгоритме.

AVC>>ИМХО, рассуждения о принципе подстановки Барбары Лисков в данном случае выглядят наивными.
ГВ>Не согласен. В данном случае при проектировании функции диспетчеризации мы используем знание о наборе поступающих сообщений. Если источник сообщений добавит ещё одно-два, то придётся модифицировать клиентский код, который придётся разыскивать через search и т.п. Не есть бест солюшн на мой взгляд. Вариант с группировкой обработчиков по интерфейсам я полагаю более надёжным.

Интересно, как именно будет выглядеть этот вариант?
И опять же, сколько интерфейсов Вы намерены заложить в систему?

AVC>>Здесь мы имеем дело с задачей двойной диспетчеризации, и это — ее самое простое (и универсальное) решение.
ГВ>Ну... можно обобщить до ДД. Разумеется, если объекты сообщений сами содержат реализацию некоторой функциональности. Я же говорю, что дальнейший анализ нужно делать на основании конкретной задачи.

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

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

R>>Реально будет использовано меньше. Длинные произведения делаются
R>>inline-функциями. Поэтому небольшая автоматизация изврата — и
R>>генерируются только используемые размерности. Хотя, конечно, получится
R>>многовато, но искусство требует жертв. Благо, не человеческих, и даже не
R>>усилий.

Искусство требует нечеловеческих жертв!
((с) Ленин после прослушивания Лунной Сонаты)

ГВ>Ну-ксь, поверим гармонию алгеброй. Для 10^9 комбинаций, даже если на генерацию уходит 1 ms (оптимистично), то получим... 10^6 секунд на один проход генерации... Это... что-то около 11 дней на заход. Объём выходного файла при 50 символах на экземпляр ~50 ГБ.

ГВ>Даже если срезать три порядка — всё равно невесело. А если ещё тестирование...

Причём самое обидное, что из всего этого многообразия потребуются ну сто, ну двести разных сочетаний. Правда, забодаешься вручную их выявлять...

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

CX>Стоп-стоп-стоп. Изначально речь шла о безопасных и небезопасных традиционных языках. Зашла речь о метапрограммировании, которое доступно в C++ и недоступно в других языках, которые приводились как его главные противники.
CX>Причем здесь лисп? Да ни причем. Ежу понятно, что C++ с функциональными языками в сфере метапрограммирования конкурировать не может. Ну так и не нужно. Разве ж этого кто добивался?

А что Вы скажете насчет PL/1? Вполне себе традиционный язык.

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


ПК>В отличие от C++ на ассемблере нет способа сделать так, чтоб компилятор ловил ошибки типизации.
Это, смотря какой ассемблер.

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

AVC>Прости меня, но со стороны было несколько забавно наблюдать, как тебе за это "досталось".

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

AVC>Насколько я понимаю, ты видишь достоинство Си++ не в отдельных его "фичах" (которые могут уступать аналогичным "фичам" других языков), а в их сочетании.
AVC>Не знаю, с кем я согласен больше — с тобой или Трурлем.
AVC>Скорее, с Трурлем.