GCC - поясните.

Kirill, ты ещё здесь сидишь?

Понедельник Март 06 2006 11:29, Kirill Frolov wrote to George Shepelev:

Дополнительно усложняя анализ! И ради чего, наверное ради мифической "идеологической правильности"?

KF> Потому как хоть и можно всё описывать исключительно одним состоянием, KF> это ненаглядно и число их (они перемножаются) очень велико. В данном KF> случае целесообразно для каждой двери иметь своё состояние.

А это и значит - использовать флаги! ;)))

KF> Hо где-то наоборот.

Верю. Hо неоправданно обобщать-то те случаи, которые "наоборот", не надо, да?

Глупости.

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

Георгий

Нет. Практически проще и менее багоопасно.

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

-- всё весмь в неявном виде.

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

Я имею ввиду fopen, fclose().

Сам себе мешаю.

Kirill, ты ещё здесь сидишь?

Понедельник Март 13 2006 13:03, Kirill Frolov wrote to George Shepelev:

Менее багоопасны как раз вменяемые флаги, а не полный список состояний. Контролировать правильность легче. Кстати, "разбивка на несколько автоматов" легко может привести к тому, что появятся флаги, описывающие состояния некоторых автоматов ;)

В данном случае значит.

KF> Состояний может быть более двух.

Могут. Hо если состояний два, почему бы не применять флаги? При этом не нужно снова искусственно выдумывать "полный список состояний" каждого отдельного модуля, это только увеличит вероятность ошибок и усложнит отладку и сопровождение.

KF> А флаги -- это искусственное дробление системы на множество автоматов KF> с двумя состояниями каждый.

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

KF> При этом как оно между собой будет взаимодействовать -- всё весмь в KF> неявном виде.

Автономная отладка каждого модуля а затем описание их взаимодействия с использованием _их_ состояний гораздо проще и надёжнее, чем попытка выделить абсолютно все возможные состояния всей системы. И подумай ещё, как ты собираешься модифицировать программу, если состав модулей или их взаимодействие будут меняться в ходе совершенствования системы?

Используй грамотное программирование и не будешь ходить по граблям!

KF> Вроде того, что не нужно хранить одну величину в 10 переменных или KF> одно состояние в десятке флагов.

А кто-то заставлял это делать? ;)

Hе зацикливайся на инструменте. Первичны алгоритмы, а не реализация.

Георгий

Kirill, ты ещё здесь сидишь?

Понедельник Март 13 2006 13:04, Kirill Frolov wrote to George Shepelev:

"Плохому танцору..." (c)

Георгий

астоящие хацкеры используют фортран.

Флаги -- это состояние закодированное массивом двоичных "флагов", вместо одной переменной. Не зна что в них вменяемого.

Один автомат -- одно состояние -- одна переменная.

Его не выдумывать. Он просто есть. Можно им пользоваться, можно изобретать какие-то флаги.

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

Все возможные состояния системы -- комбинация всех допустимых состоянийх отдельных модулей.

Модуль в твоей системе пон ятий чч автомату в моей., Так проще?

И что ест грамотное программирование?

Вот я и говорю -- флаг редко имеет смысл.

Kirill, ты ещё здесь сидишь?

Среда Март 15 2006 23:15, Kirill Frolov wrote to George Shepelev:

Фортран для эхотага? Стильно! ;-)

Георгий

Kirill, ты ещё здесь сидишь?

Среда Март 15 2006 23:28, Kirill Frolov wrote to George Shepelev:

Флаги места мало занимают, легко инициализируются и анализируются. Удобно.

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

Это характеризует лишь твой плохой стиль программирования.

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

Hа практике при этом гораздо больше вероятность допустить ошибку. Которую потом будет довольно трудно обнаружить.

KF> Клчевое слово -- явно.

Может и явно, но не всегда адекватно. Оно нам надо?

Hу и чем тебе в таком случае флаги мешают? Они как раз описывают такие вот допустимые состояния ;)

Модули в моей системе могут иметь высокую вложенность. Вся система собирается из "кубиков", каждый "кубик" может в свою очередь состоять из отдельнх модулей. И при любом изменении структуры не придётся менять всё описание, потому что описание состояний полностью адекватно структуре системы и менять придётся только те элементы, которые соответствуют внесенным изменениям.

То, при котором ты сам себе мешать перестанешь ;-)

При грамотном программировании - всегда имеет смысл. Лажануться при составлении "списка состояний" куда проще. Учисть работать грамотно!

Георгий

В чем проблема? Мы в былые времена ускорителями и системами противоракетной обороны управляли на Фортране. Нормальные встроенные системы, реального времени.

Hi George !

Совсем недавно 16 Mar 06 11:30, George Shepelev писал к Kirill Frolov:

KF>> Hастоящие хацкеры используют фортран.

GS> Фортран для эхотага? Стильно! ;-)

Если вспомнить параметры тех больших ЭВМ, на которых собственно и крутили фортраны4 с пиэлями1, то они как раз попадают под определение простых вариантов современных эхотажных устройств. :-)

WBRgrds Ruslan

Dmitry, ты ещё здесь сидишь?

Четверг Март 16 2006 08:53, Dmitry Orlov wrote to George Shepelev:

Флаг - это и есть двоичное состояние ;)

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

DO> Дверь может быть открыта, закрыта и при этом заперта или не заперта. DO> Открыта и заперта она быть уже не может.

Лампочки в салоне не горят независимо от того, заперта закрытая дверь или нет.

DO> И с добавлением замка в дверь гораздо удобней добавить еще одно DO> состояние в список состояний, чем еще один флаг и все комбинации его с DO> другими флагами, в том числе и бессмысленные.

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

KF>> Это уменьшит ошибок. В разы. В силу того, что все состояние KF>> будут явно выделены и для каждого состояния будут, опять же явно, KF>> определены все возможжные условия перехода в другие состояния и KF>> сопутствующие им действия. Клчевое слово -- явно. DO> Уже очень давно пишу программы, состоящие преимущественно из конечных DO> автоматов в виде switch () case и правил перехода из одного состояния DO> в другое. Флажки тоже бывают, но для всяких асинхорнных автомату DO> событий.

Милиционера попросили выглянуть из машины и проверить, работает ли мигалка на крыше. Он смотрит и говорит: "Работает. Hе работает. Работает. Hе работает..." ;)

Вот тебе ещё один пример, когда "состояния" удобно реализовывать при помощи флагов. Отдельный флаг - включение мигалки. А уж как она сама будет мигать лампочкой - её личное дело.

KF>> Вот я и говорю -- флаг редко имеет смысл. DO> Как асинхронное событие - вполне имеет.

Уже хорошо.

DO> Как хранение состояние конечного автомата - нет.

Даже когда в системе есть множество конечных автоматов с двумя состояниями? Попробуй _обосновать_.

Георгий

Kirill, ты ещё здесь сидишь?

Четверг Март 16 2006 11:30, George Shepelev wrote to Kirill Frolov:

KF>> В силу того, что все состояние будут явно выделены и для каждого KF>> состояния будут, опять же явно, определены все возможжные условия KF>> перехода в другие состояния и сопутствующие им действия. GS> Hа практике при этом гораздо больше вероятность допустить ошибку. GS> Которую потом будет довольно трудно обнаружить.

Кстати, вспомнился довольно наглядный пример того, к чему может приводить концепция работы "по минимуму состояний системы". Hекоторые буржуйские видеомагнитофоны "не понимали" советских видеокассет и не выбрасывали их наружу. Приходилось разбирать механику, чтобы извлечь их из буржуйского "чуда техники". Видимо какой-то "умник" решил, что "неопознанный тип кассеты" соответствует состоянию системы "нет кассеты". При работе "по состояниям" исправлять эту ошибку довольно противно, придётся добавить ещё одно состояние и изменить связи между имеющимися состояниями системы. Если же не зацикливаться на этой порочной концепции, что потребуется всего лишь в одном месте слегка изменить проверки, выполняемые при нажатии кнопки Eject...

Георгий

Arcady, ты ещё здесь сидишь?

Пятница Март 17 2006 05:27, Arcady Schekochikhin wrote to George Shepelev:

Сдаётся мне, всё же это несколько специфические встраиваемые системы. Почему то мне кажется, что большинство участников эхи не ваяют ускорители и системы ПРО. А программирование на фортране для какого-нибудь PIC-контроллера действительно выглядит стильно ;-)

Георгий

Hello, George Shepelev! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Fri, 17 Mar 2006 12:21:28

GS> Флаг - это и есть двоичное состояние ;)

Но состояние - не есть флаг.

GS> Вполне удачный пример. Скажем, флаги состояния могут GS> выставляться в обработчике прерываний, опрашивающем состояние

Причем тут обработчики прерываний?

GS> датчиков, а по их совокупности включаются/выключаются лампочки GS> в салоне и звуковая индикация.

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

DO>> Дверь может быть открыта, закрыта и при этом заперта или не DO>> заперта. Открыта и заперта она быть уже не может.

GS> Лампочки в салоне не горят независимо от того, заперта GS> закрытая дверь или нет.

Это у кого как. Кроме лампочекЮ есть еще сигнализация, поведение которой радикально отличается для всех трех состояний двери. {drOpen, drClose, drLock}

DO>> И с добавлением замка в дверь гораздо удобней добавить еще DO>> одно состояние в список состояний, чем еще один флаг и все DO>> комбинации его с другими флагами, в том числе и DO>> бессмысленные.

GS> Замок - отдельная сущность, он может быть разных конструкций

Что не влияет на то, что он может быть заперт и отперт.

GS> и при его переделке крайне неудобно переделывать всю остальную GS> логику системы...

И не надо.

KF>>> Вот я и говорю -- флаг редко имеет смысл. DO>> Как асинхронное событие - вполне имеет.

GS> Уже хорошо.

DO>> Как хранение состояние конечного автомата - нет.

GS> Даже когда в системе есть множество конечных автоматов с GS> двумя состояниями? Попробуй _обосновать_.

В реальных системах есть множество состояний с числом более 2х.

dima

Пpивет, Ruslan.

Вот что Ruslan Mohniuc wrote to George Shepelev:

KF>>> Hастоящие хацкеpы использyют фоpтpан.

GS>> Фоpтpан для эхотага? Стильно! ;-)

RM> Если вспомнить паpаметpы тех больших ЭВМ, на котоpых собственно и RM> кpyтили фоpтpаны4 с пиэлями1, то они как pаз попадают под опpеделение RM> пpостых ваpиантов совpеменных эхотажных yстpойств. :-)

Hапpимеp, там на боpтy непpеменно были входы АЦП, выходы ЦАП или ШИМ, имелась масса входов пpеpываний, а в конypе скyлил и тявкал WDT. ;-)

Michael G. Belousoff mickbell(dog)r66(dot)ru

На эту тему всем читать AGC - Apollo Guidance Computer.

Dmitry, ты ещё здесь сидишь?

Суббота Март 18 2006 14:57, Dmitry Orlov wrote to George Shepelev:

DO>>> Это "по-академически". Состояния действительно на много DO>>> удобней. GS>> Флаг - это и есть двоичное состояние ;) DO> Hо состояние - не есть флаг.

Повторяю, двоичное состояние может храниться в виде флага. Это очень удобное представление данных.

DO>>> С той же дверью пример применения флагов крайне неудачный. GS>> Вполне удачный пример. Скажем, флаги состояния могут GS>> выставляться в обработчике прерываний, опрашивающем состояние DO> Причем тут обработчики прерываний?

При том, что сами по себе "академические" флаги или состояния не нужны. Их вводят для конкретной работы конкретных программ.

GS>> датчиков, а по их совокупности включаются/выключаются лампочки GS>> в салоне и звуковая индикация. DO> Все немного иначе, чем ты себе представляешь...

Интересно, как я могу "не представлять" то, что несколько раз делал? ;)

DO>>> Дверь может быть открыта, закрыта и при этом заперта или не DO>>> заперта. Открыта и заперта она быть уже не может. GS>> Лампочки в салоне не горят независимо от того, заперта GS>> закрытая дверь или нет. DO> Это у кого как.

У большинства так. Опять же, если надо будет сделать "не так", гораздо проще менять в одном месте реакцию на состояния, чем всю структуру состояний системы...

GS>> и при его переделке крайне неудобно переделывать всю остальную GS>> логику системы... DO> И не надо.

Басня Крылова о зелёном винограде. "Вам это не надо, потому что мы так сделали систему, что не можем её изменить".

DO>>> Как хранение состояние конечного автомата - нет. GS>> Даже когда в системе есть множество конечных автоматов с GS>> двумя состояниями? Попробуй _обосновать_. DO> В реальных системах есть множество состояний с числом более 2х.

Это не отменяет удобства пользования флагами в значительном числе конкретных случаев.

Георгий

Hello, George Shepelev! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Wed, 22 Mar 2006 11:29:39

DO>>>> Это "по-академически". Состояния действительно на много DO>>>> удобней. GS>>> Флаг - это и есть двоичное состояние ;) DO>> Hо состояние - не есть флаг.

GS> Повторяю, двоичное состояние может храниться в виде флага.

Двоичное - оно и есть флаг.

DO>>>> С той же дверью пример применения флагов крайне неудачный. GS>>> Вполне удачный пример. Скажем, флаги состояния могут GS>>> выставляться в обработчике прерываний, опрашивающем GS>>> состояние

DO>> Причем тут обработчики прерываний?

GS> При том, что сами по себе "академические" флаги или состояния GS> не нужны.

А обработчики-то причем?

GS>>> датчиков, а по их совокупности включаются/выключаются GS>>> лампочки в салоне и звуковая индикация. DO>> Все немного иначе, чем ты себе представляешь...

GS> Интересно, как я могу "не представлять" то, что несколько раз GS> делал? ;)

Как всегда и все, что ты делаешь, понятия не имея как оно собственно должно делаться и делается.

DO>>>> Дверь может быть открыта, закрыта и при этом заперта или не DO>>>> заперта. Открыта и заперта она быть уже не может. GS>>> Лампочки в салоне не горят независимо от того, заперта GS>>> закрытая дверь или нет. DO>> Это у кого как.

GS> У большинства так.

У большинства того, что ты сделал разве что, только это вообще машинами рядли можно назвать. Потому что у всех, что можно, это все уже сделано и сделано несколько иначе.

GS> Опять же, если надо будет сделать "не так", гораздо проще менять в одном месте GS> реакцию на состояния, чем всю структуру состояний системы...

Зачем всю менять? Добавил состояние и правила перехода в него и все. Как раз это и удобнее, чем флаги добавлять и всю логику перетряхивать.

GS>>> и при его переделке крайне неудобно переделывать всю GS>>> остальную логику системы... DO>> И не надо.

GS> Басня Крылова о зелёном винограде. "Вам это не надо, потому GS> что мы так сделали систему, что не можем её изменить".

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

DO>>>> Как хранение состояние конечного автомата - нет. GS>>> Даже когда в системе есть множество конечных автоматов с GS>>> двумя состояниями? Попробуй _обосновать_. DO>> В реальных системах есть множество состояний с числом более DO>> 2х.

GS> Это не отменяет удобства пользования флагами в значительном GS> числе конкретных случаев.

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

dima