Ответ на »сообщение 1805« (Сергей Перовский)
___________________________
Оно понятно. Но если раньше экономия дорогих рессурсов была необходимой частью ЛЮБОЙ задачи, то сегодня это именно узкие ниши. Вы же пытаетесь втиснуть язык общего назначения в свою нишу. Зачем ради одного вас ломать инструмент тысячам программистов ? И уж тем более язык основным предназначением которого является обучение.
Сделайте себе свой собственный инструмент.

Ответ на »сообщение 1804« (Jack Of Shadows)
___________________________
Не далее как вчера беседовал со специалистами по гидро-аэродинамике.
Я убеждал их, что в их численном методе возможно накопление погрешности и предлагал вместо стандартных чисел, для пробы использовать арифметику, учитывающую погрешность. Что стоит написать такой тип: "физическая величина", имеющий значение и погрешность?
Они говорят - мы вылизываем и оптимизируем алгоритм под конкретный процессор чтобы за рабочий день успеть произвести хотя бы один расчет. А тут потеря на порядок. Мы так не играем.
Всегда есть задачи, решаемые на пределе возможностей компьютера.
И всегда будут.
Если они Вам не попадаются - Ваше счастье.

Ответ на »сообщение 1803« (Сергей Перовский)
___________________________
Если в Object Pascale целое число не является объектом, то и слава богу, накладные расходы очень велики,
Накладные расходы моего хозяина, моего бога Машины, слишком велики. Я как ревностный слуга и раб его, не могу позволить себе таких расходов. Костьми лягу ради экономии пары лишних байтов кремниего мозга моего повелителя.
Высунув язык буду бегать по циклам, используя каждую переменную как можно чаще, дабы не перегрелся от чрезмерного усилия мой железный господин. Я прах и пыль под его системой охлаждения. Мое время и мои умственные усилия не стоят ни одного такта его божественной частоты...

Сергей, вставайте, вставайте с колен :)) Время пришло.

Ответ на »сообщение 1800« (Илья Ермаков)
___________________________
>>>ООП как ООП существует в красивом и цельном виде лишь в чистых объектных языкам - том же Smalltalk. В других языках оно в той или иной мере суррогатно.
Есть языки "фанатичные", в которых все подчинено единственной парадигме программирования. Такие, как Smalltalk.
Есть языки "космополитичные", в которых реализованы все возможные парадигмы программирования без разбора. Такие, как С++.
Первые не пользуются спросом в силу того, что даже если задача в целом хорошо подходит под данную парадигму, в процессе ее реализации обязательно всплывут фрагменты, плохо соответствующие.
Вторые, как мы знаем, могут пользоваться популярностью в силу "универсальности", но порождают ситуацию хаоса, когда в рамках одного проекта программисты мыслят в разных парадигмах - язык один, но понять друг друга невозможно.
Я предпочитаю "золотую середину". Если в Object Pascale целое число не является объектом, то и слава богу, накладные расходы очень велики, а выигрыш только в осознании "красивой и цельной реализации ООП".
Оберон - язык красивый, вот только не слишком ли "фанатичный"?

>>>П.1 был отброшен по причине наличия понятия "тип данных", в плане абстрагирования ПрО полностью эквивалентного понятию "класс".
Вот только "о кораблях, о башмаках, о сургучных печатях, о королях и о капусте" проще рассуждать, как об объектах, чем как о типах данных.

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

Если рассматривать Оберон, как язык для обучения, то надо иметь в виду, что "неявная" реализация в нем ООП приведет к серьезным трудностям с пониманием объектного подхода.

Ответ на »сообщение 1801« (pepper)
___________________________
В этом примере в функциях нет локальных объектов с деструкторами, следовательно, дополнительный код генерировать не к чему. Таким топорным тестированием трудно что-то выявить. Нужно либо подбирать хороший тест с активным размещением объектов с деструкторами на стеке и затем дизассемблировать код, либо верить на слово аффтарам книжек типа Рихтера и Робинса...

Ответ на »сообщение 1797« (Илья Ермаков)
___________________________


Синхронная обработка исключений по умолчанию применена в Visual С++ 6. Компилятор ожидает, что исключения будут генерироваться только при помощи явного вызова оператора throw."

Во-первых, асинхронная/синхронная обработка - это термины из Win32-specific. Соответсвенно они имеют смысл только в платформенно-зависимом коде. Во-вторых, просто проверь:

#include <iostream>
using namespace std;

void f1(int i)
{
    if ( i < 100 )
        f1(i + 1);
    else
        if (i == 101 )
            throw "test";
}

void f2(int i)
{
    if ( i < 100 )
        f2(i + 1);
    else
        if (i == 101 )
            abort();
}

int main()
    {
    cout << "Function with exception test" << endl;
    for(int i = 0; i < 10000000000; i++)
        f1(0);

    cout << "Function without exception test" << endl;
    for(int i = 0; i < 10000000000; i++)
        f2(0);
   
}

Я на своем доступном компиляторе (VC7.1 /O2 /EHsc) никакой временной разницы не заметил.

P.S. Рекурсия применена, чтобы запудрить мозги оптимизатору и сэмулировать эффект вызова множества функций с возможным throw. В асмовском листинге f1/f2 и throw и abort присутствуют.

Ответ на »сообщение 1798« (Сергей Перовский)
___________________________
ООП как ООП существует в красивом и цельном виде лишь в чистых объектных языкам - том же Smalltalk. В других языках оно в той или иной мере суррогатно.
Поэтому вместо простого переноса class и object стоило провести декомпозицию ООП на независимые составляющие и посмотреть, что нужно брать, а что уже есть в другой форме.
Что Виртом и было сделано...
На что декомпонируется ООП?
1) Методы асбтракции проблемной области и ее моделирования в языке - и соответственно ключевые слова class и object.
2) Интеграция данных и кода.
3) Расширение типа и основанная на этом виртуализация.
4) Инкапсуляция.
5) Повторное использование кода - наследование реализации.

П.1 был отброшен по причине наличия понятия "тип данных", в плане абстрагирования ПрО полностью эквивалентного понятию "класс".
П.2 был воспроизведен в других терминах.
П.3 был реализован в полной мере, он имеет особую важность  - т.к. дает возможность написания расширяемого кода, работающего с данными, неизвестными в момент его написания. Вот это, по моему мнению, и есть ключевая особенность ООП. Если язык поддерживает эту возможность, то он может считаться объектно-ориентированным независимо от наличия в нем слов class и object. Oberon, Ada, языки функционального программирования поддерживают этот пункт и являются ОО-языками.
П.4 возлагается на модули.
П.5 также возлагается на модули. Избежать переписывания кода можно и без наследования реализации, если правильно декомпонировать один большой класс на несколько мелких типов, взаимодействующих через абстрактные интерфейсы. Я, например, уже давно отвык мыслить в терминах наследования реализации и ощущаю от этого только одни преимущества - решения получаются гораздо изящнее, а традиционный подход кажется неуклюжим и косным, негибким.

Ответ на »сообщение 1769« (AVC)
___________________________
>>>Первоисточник, кажется, -- какая-то старая шутка про физиков.
Ссылку не нашел, придется передать по значению :)

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

Ответ на »сообщение 1741« (Снегурочка)
___________________________
>>>Попробую резюмировать Ваши аргументы
Не надо так резюмировать :)
Это тезисы в пользу разных утверждений.

Дело в том, что попыток сформулировать, что же такое Оберон-технология (прошу заметить не язык и не система, а именно вынесенная в заголовок технология) было тут не мало. Но я уловил единственное реальное отличие от других систем: базовое понятие модуля, как единицы языка, единицы компиляции и единицы загрузки в одном лице. Да еще и с автоматическим динамическим контролем корректности вызовов.
По поводу этой технологии я и высказался, что она плохо совместима с ООП и программист должен выбирать либо наследование либо динамическая модульность.
Это не упрек Оберону, это попытка определить область применимости.

Остальные рассуждения уже не имеют прямого отношения к Оберон-технологии и собственно тут офтопик :)
Я просто заранее отвечал на много раз слышанные возражения: Язык Оберон и многие его реализации позволяют реализовать ООП, не нужны динамические модули - не пользуйтесь. Вот сюда и относятся мои рассуждения о синтаксисе - если не использовать базовые принципы языка, зачем использовать язык? Если мне без ООП зарез, то я буду пользовать язык у которого ООП основа, а не "так и быть можете и объект организовать".

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

>>>Динамическая загрузка-выгрузка модулей накладывает отпечаток на специфику реализации классов в модулях. Но это совсем не обязательная особенность Оберон-технологии
Готов выслушать Вашу формулировку Оберон-технологии.

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

Надеюсь, на этот раз я выразился точнее.

Ответ на »сообщение 1795« (pepper)
___________________________

Дж. Роббинс "Поиск и устранение ошибок в программах под Win32".
"Обработка исключений в С++ требует затрат. Компилятору нужно выполнить большой объем работы по установке и удалению блоков try-catch, даже если вы не генерируете никаких исключений. Поэтому при работе над кодом, производительность которого критична, накладные расходы могут быть непозволительно высокими.
...
Чтобы использовать обработку исключений в С++, необходимо понимать разницу между синхронной и асинхронной обработкой исключений. Разница между ними состоит в способе генерации исключений, определяющем код их обработки, который будет создавать компилятор
При асинхронной обработке исключений С++ компилятор "считает", что любая команда может сгенерировать исключение. Поэтому код должен быть всегда готов к перехвату исключения. По умолчанию в MS Visual C++ 5 использовалась асинхронная обработка исключений. Ее проблема в том, что компилятор обязан следить за временем жизни объекто и вовремя развертывать исключения в любой точке кода. Создаваемый для этого дополнительный код имеет значительный объем, и память в основном будет расходоваться напрасно, т.к. дополнительный код чаще всего не нужен.
Синхронная обработка исключений по умолчанию применена в Visual С++ 6. Компилятор ожидает, что исключения будут генерироваться только при помощи явного вызова оператора throw."