О фатальных программных ошибках и т.п.

Да нет, в ООП как таковом ничего особо страшного. А вот в его классических реализациях... Неявные операции на каждом шагу. Кстати, твой вид записи add(b,c) - это и ООП-запись. Но ООП, например, по определению использует полиморфизм. Что уже большой подводный камень. Наследования могут тащить тоже кучу мути. И т.д.

Balancer, 28.01.2004 23:04:59:

Да нет, в ООП как таковом ничего особо страшного. А вот в его классических реализациях... Неявные операции на каждом шагу. Кстати, твой вид записи add(b,c) - это и ООП-запись. Но ООП, например, по определению использует полиморфизм. Что уже большой подводный камень. Наследования могут тащить тоже кучу мути. И т.д.

 

Не к ночи будь помянуто, но в твоем любимом Форте, слова можно переопределять внутри слов. Так что слово add вообще неизвестно, что значит. В том же С без полиморфизма, но с различными скопами действия - тоже не знаешь, что вызовывается. А, если принять во внимание препроцессор, то задница полная. Пример не в тему явно. А полиморфизм это хорошо. У С тоже он есть, у Паскаля, Перла, Фортрана и т.д. Только он часто не расширяемый. А, если хочеться операций полиморфных - посмотри на Алгол 68 - С++ оттуда взял это дело, только не в полной мере.

Rada, 28.01.2004 19:22:42 :

2 Centuriones:
 

А вот в ООП многие камни подводные.

 

Приведите примеры.

 

Когда я это писал, то вспомнились публикации первой половины 1990-х годов, когда ООП только-только начало широко входить в нашу жизнь, и достоинства и недостатки ООП достаточно широко обсуждались в печати. Помнится основная критика шла о возможных побочных эффектах при наследовании. В Паскале, припоминаю, есть понятие предопределенных объектов, на базе которых лепятся все остальные (простите, если путаюсь в терминологии, но надеюсь смысл понятен). Если ошибка, или не вполне корректная реализация именно на этом уровне (лопухнулись разработчики компилятора), то программист, использующий данный программный продукт и представить не сможет, что его может ожидать при неком стечении обстоятельств. Тем более ассемблирование далеко не всегда может помочь. (Погоня за скоростью компиляции. Раньше, помнится, компиляторы языка высокого уровня на PDP/LSI-11 не создавали исполнимого кода, а только ассемблерный. А уж потом, компилируя ассемблерный код, создавали библиотеки, загрузочные модули. С одной стороны - долго, но зато какой простор для оптимизации!) ...Если бы я тогда стал бы писать программы не на MS BASIC PDS 7.1 а на TURBO PASCAL 7.0, то думаю мог бы привести и конкретные примеры. Однако думаю на форуме есть достаточно людей, владеющие ООП-языками и трезво смотрящими на вещи. В настоящее время пишу исключительно на фортране 90/95. Изучить С/С++ пока нет времени, но какие-то основы, скорее всего придется, хотя бы "на обезьяннем уровне", чтобы иметь доступ к некоторым возможностям Windows, которые не поддерживаются фортраном (например - печать графики).
Правда, если взглянуть на игры... К сожалению, разработчики игр не пишут о платформе, на которой они пишут свои творения, но основа, как мне кажется - С/С++ (можно судить по информации об ошибках во время выполнения, сообщения о которых иногда вылетают в первых версиях игр).

Rada, 28.01.2004 19:22:42 :

Ха, вы пробовали писать многопотоковые приложения?

 

Сам не писал, но интересовался. Необходимости не было. Изучал некоторые примеры и из литературы по фортрану, и из комплекта поставки... но они все были, мягко говоря, глюкавые. Почему-то у нас в книгах по программированию иногда модно код писать не "курьером" (Я имею в виду некоторые книжки от "Диалог" МИФИ). Наверно, чтобы учиться, правя чужие ошибки . В Microsoft, похоже, думают аналогично.

Mishka, 28.01.2004 23:30:01:

Не к ночи будь помянуто, но в твоем любимом Форте, слова можно переопределять внутри слов.

 

Не к ночи будет помянуто, но локальные переменные в Форте и то совсем недавно только в стандарт ввели

<font size="-2" color="#808080"><b></b>>А полиморфизм это хорошо.</font>

Для программиста, но не для надёжности
В Хаскелл, например, его оставили, хотя и не объектный язык, а вот в O'Caml - выкинули нафиг, хотя он как раз с ООП

Ром, и в Хаскеле он есть - плюс то по разному отрабатывается для разных типов данных. Это чистой воды полиморфизм.

Rada, 28.01.2004 19:22:42:

2 TEvg:

Мне кажется что программы в КА не должны быть многопоточными т.к. это неистощимый источник глюков.

 

На КА имеем кучу асинхронно работающих приборов и систем в реальном времени. Что будем делать?

 

Думать головой. Можно например реализовать как набор конечных автоматов внутри однопоточной программы.

Guest, 29.01.2004 08:28:20:

Pazke, 29.01.2004 08:21:23 :

На КА имеем кучу асинхронно работающих приборов и систем в реальном времени. Что будем делать?

 

Думать головой. Можно например реализовать как набор конечных автоматов внутри однопоточной программы.

 

Гы, а как в этой однопоточной программе будет с реальным временем?

 

С каких пор многопоточность непосредственно связана с реальным временем ?

Guest, 29.01.2004 10:39:05:

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

 

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

Таки асинхронность и реалтаймовость напрямую с многопоточностью не связаны. В 99% задач достаточно будет только организовать обработку прерываний

Balancer насчет ООП ты не прав . Приведенный тобой пример с переопределением опрераторов к ООП не имеет отношения. Такие вещи есть и не в ООП языках, например в Прологе. IMHO это не очень хорошая идея. У того же Братко в книге по Прологу вначале идет все примеры узнаваемы, а в конце ну просто кошмар . Но BTW в Прологе переопределение операций имеет одно преимущество перед С++ — там указывается приоритет операции.

Fakas, 29.01.2004 13:20:24:

Приведенный тобой пример с переопределением опрераторов к ООП не имеет отношения.

 

Просто это один из китов ООП. Напомню:

- Инкапсуляция
- Наследование
- Полиморфизм

Если чего-то из этого нет, то это уже не ООП

>Но BTW в Прологе переопределение операций имеет одно преимущество перед С++ — там указывается приоритет операции.

А в Хаскелле (который мало того, что не ООП, так ещё и на сегодня считается языком с минимальным процентом ошибок, пропускаемых на этапе компиляции) не только переопределять операторы можно, но и свои вводить Хоть пять звёздочек для, например, возведения в супер-пупер-степень

c = a ***** b;

Fakas, 29.01.2004 13:20:24 :

Приведенный тобой пример с переопределением опрераторов к ООП не имеет отношения.

 

Просто это один из китов ООП. Напомню:

- Инкапсуляция
- Наследование
- Полиморфизм

 

И гдие здеся операторы ? Ты с полиморфизмом тоих не путай . Переопределение операторов и без него делается.
Мне кажется что претензии к полиморфизму появляются из-за множественного наследлования . Поэтому мне больше нравится ООП-модель раедизованная в Object Pascal — никакого множественного наследования и переопределения операторов, виртуальный конструкторы и переменные типа класс, строгая типизация. Это все плюсы с точки зрения надежности.
Сама по себе парадигма ООП тоже во многом повышает надежность программ. Прежед всего проще спроецировать реальные объекты в их программную модель. ООП также стимулирует нормальное проектирование программы а не нахлобучивание функциональности .
Грамотно спроектированная ОП модель позволяет минимизировать влияние подсистем друг на друга и зачастую позволяет модифицировать отдельные части программы без необходимости полнообъемного тестинга всего и вся.

Fakas, 29.01.2004 17:00:55:

И гдие здеся операторы

 

Вот не надо "тупизма"
Речь шла о подмене функции. А то, что ещё и в виде оператора - это уже не важно. Я же потом привёл пример. Не нравится перезагрузка - что делает
a=add(b,c);
?

Вот поэтому-то ИМХО самый оптимальный язык для любой автономной техники - Форт, так как он позволяет создать для решения каждой задачи свой проблемно-оринтированный язык, на котором эта задача будет решена элегантно и прозрачно. Кстати, ООП-модель на Форте можно сделать любую без потерь в красоте и лаконичности.

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

Зато мало что лучше Форта подходит для "ручной" работы с железом, отладки "вживую" и т.п.

>Зато мало что лучше Форта подходит для "ручной" работы с железом, отладки "вживую" и т.п.
Что в космической технике в первую очередь и требуется.
О дуракоустойчивости: Форт честен в этом отношении и приучает программиста не слишком распускать руки. К тому же все средства защиты от "дурости" на верхнем уровне можно написать на Форте же, сделать частью проекта, да еще и усиливать эти средства на ходу при необходимости.

Balancer, 29.01.2004 17:06:55:

Fakas, 29.01.2004 17:00:55 :

И гдие здеся операторы

 

Вот не надо "тупизма"
Речь шла о подмене функции. А то, что ещё и в виде оператора - это уже не важно. Я же потом привёл пример. Не нравится перезагрузка - что делает
a=add(b,c);
?

 

Это просто вызов какой то функции add и все .
Если ты хотел сказать про виртуальный метод, то в Паскале сие будет выглядеть вот так

a:=SomeObj.add(b,c);

В С++ тоже должен присуствовать имя экземпляра класс, просто не помню нотацию.
И это совсем другая песня. Могу спросить у SomeObj а вы кто, собственно :

SomeObj.ClassName

Я могу его проверить на совместимость с нужным мне классом :

If SomeObj is TCoolWorkClass then
   
А обычные пеерменные так не допросишь .
Вот так вот .

Fakas, 29.01.2004 19:08:20:

Это просто вызов какой то функции add и все .
Если ты хотел сказать про виртуальный метод

 

Ну да, так и есть. Отвлекают меня тут ужасно. Войну с начальством сегодня провёл умеренной агрессивности

>Я могу его проверить на совместимость с нужным мне классом :
>If SomeObj is TCoolWorkClass then

А ресурсы на это какие уйдут?

Balancer, 29.01.2004 19:12:57:

>Я могу его проверить на совместимость с нужным мне классом :
>If SomeObj is TCoolWorkClass then

А ресурсы на это какие уйдут?

 

В каком смысле ресурсы ? Всего навсего прочитать VMT, кот-я в единственном экземпляре. Да и вообще — или шашечки или ехать .

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

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

Но у нас тут изъян в самом начале есть. Мы строим однопроцессорную систему, а это ущербный подход. Особенно для таких систем. Даже ПК давно движется к распределению задач (многие ли из нас на MFM-винтах и VGA-видеокартах сидят?). Для нормального КА каждый исполнительный орган должен быть снабжён своим микроконтроллером, отвечающим за работу с ним и отчитывающимся и управляемым центральным (возможно - несколькими) процессором. Эдакая аппаратная многопроцессность (не многопоточность)

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

>Мы строим однопроцессорную систему, а это ущербный подход.

Ром ты про что? Реальные КА, поверь мне в основном далеко не однопроцессорные, кроме самых простых

CaRRibeaN, 29.01.2004 23:14:28:

>Мы строим однопроцессорную систему, а это ущербный подход.
Ром ты про что? Реальные КА, поверь мне в основном далеко не однопроцессорные, кроме самых простых

 

Я не про реальные КА, а про то, что мы тут строим

Про реальные я как бы немного в курсе