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

 
1 2 3 4
+
-
edit
 

Balancer

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

Mishka

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

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

RU Centuriones #29.01.2004 00:09
+
-
edit
 

Centuriones

опытный

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, похоже, думают аналогично.
Раньше были времена,
А теперь мгновения.
Раньше поднимался дух,
А теперь давление.
 
+
-
edit
 

Balancer

администратор
★★★★☆
Mishka, 28.01.2004 23:30:01:
Не к ночи будь помянуто, но в твоем любимом Форте, слова можно переопределять внутри слов.
 

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

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

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

Mishka

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

Pazke

втянувшийся

Rada, 28.01.2004 19:22:42:
2 TEvg:
Мне кажется что программы в КА не должны быть многопоточными т.к. это неистощимый источник глюков.
 
На КА имеем кучу асинхронно работающих приборов и систем в реальном времени. Что будем делать?
 

Думать головой. Можно например реализовать как набор конечных автоматов внутри однопоточной программы.
 
Pazke, 29.01.2004 08:21:23:
На КА имеем кучу асинхронно работающих приборов и систем в реальном времени. Что будем делать?
 


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

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

Pazke

втянувшийся

Guest, 29.01.2004 08:28:20:
Pazke, 29.01.2004 08:21:23 :
На КА имеем кучу асинхронно работающих приборов и систем в реальном времени. Что будем делать?
 


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


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

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

Pazke

втянувшийся

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

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

Balancer

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

Fakas

опытный

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

Balancer

администратор
★★★★☆
Fakas, 29.01.2004 13:20:24:
Приведенный тобой пример с переопределением опрераторов к ООП не имеет отношения.
 

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

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

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

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

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

c = a ***** b;

 

Fakas

опытный

Fakas, 29.01.2004 13:20:24 :
Приведенный тобой пример с переопределением опрераторов к ООП не имеет отношения.
 


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

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

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

Balancer

администратор
★★★★☆
Fakas, 29.01.2004 17:00:55:
И гдие здеся операторы
 

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

Кирилл

втянувшийся

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

Balancer

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

Зато мало что лучше Форта подходит для "ручной" работы с железом, отладки "вживую" и т.п.
 
RU Кирилл #29.01.2004 19:05
+
-
edit
 

Кирилл

втянувшийся

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

Fakas

опытный

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
   
А обычные пеерменные так не допросишь .
Вот так вот .
Sapienti sat !  
+
-
edit
 

Balancer

администратор
★★★★☆
Fakas, 29.01.2004 19:08:20:
Это просто вызов какой то функции add и все .
Если ты хотел сказать про виртуальный метод
 

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

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

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

Fakas

опытный

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

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

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

Rada

опытный

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

Balancer

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

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

А уж тут и время реакции совсем маловажно, и с отложенными прерываниями никаких проблем, и загруженность управляющего процессора невысока, и отлаживать систему намного проще (аппаратная декомпозиция на независимые задачи).
 
RU CaRRibeaN #29.01.2004 23:14
+
-
edit
 

CaRRibeaN

координатор

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

Ром ты про что? Реальные КА, поверь мне в основном далеко не однопроцессорные, кроме самых простых
Shadows of Invasion.  
+
-
edit
 

Balancer

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

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

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

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru