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

AF> А вы как думаете — какой код можно назвать "серъёзным" или "сложным"?

Наверное,

серъёзный код — это код, за который дают серьезные деньги. Весь остальной код — несерьезен, за него дают или мало, или вообще ничего.

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

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

Vi2>серъёзный код — это код, за который дают серьезные деньги. Весь остальной код — несерьезен, за него дают или мало, или вообще ничего.
Супер!

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

Мне кажется, что как-раз новичек горазд сложный код писать. А вот умудренных ж/опытом седой девелопер напишет как можно проще (в разумных пределах). Сложность — она диктуется обстоятельствами, но вообще не приветствуется.
Программист серъезного уровня — это такой программист, который напишет простой код там, где вьюноша как-раз обязательно нагромоздит вавилон с висячими садами камней.

ИМХО, серъезный код — это код докучи удовлетворяющий требованиям собственно к коду (эффективность, читаемость и т.п.). Сложность — не показатель.

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

SW>О, ничего грандиозного, всё очень просто. И не для эмуляции действия FINALLY это делается. Сама мысль о эмуляции того-чего-не-нужно в С++ странна. Master Pointers это идиома и уповать на то, что такие идиомы не встроены в язык странно. Поскольку С++ в некотором роде является языком для описания идиом и писания идиомами. В этом гибкость и красота. Я могу воспользоваться другой идиомой. А Delphi — ссылки на объекты и только.

Ну и чего вот Вы этим самым сказали? Кто Вас за язык-то тянул? Вы самолично только что расписались в том, что используя язык С++ для решения какой-либо (быть может очень сложной) задачи предметной области, Вы обрекаете самого себя еще и на решение (быть может не менее сложных) задач присущих самому языку С++ без относительно к задаче предметной области. То есть вынуждены будете напрягаться больше чем необходимо. И все это в топике "Серьезный код", в котором уже не раз подразумевалось, что серьезный код должен быть на столько простым на сколько это вообще возможно.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Никакая ошибка нигде не генерится. Можно пойти дальше и, например, узнать почему последняя операция провалилась. Например, так:
SYG>

SYG>TYPE
SYG>  User = POINTER TO ABSTRACT RECORD 
SYG>    done- : BOOLEAN;
SYG>    Error-: Error;
SYG>    ...
SYG>

SYG>Error — полиморфная переменная типа список "абстрактных ошибок".
SYG>

SYG>TYPE
SYG>  Error = POINTER TO ABSTRACT RECORD 
SYG>    ...информация об ошибке
SYG>    Next-: Error; предыдущая ошибка
SYG>  END;
SYG>

SYG>это лишь один из бесчисленного количества возможных вариантов.

И чем ЭТО страшилище лучше механизма исключений? Он и есть, только ты сам должен поддерживать всю инфраструктуру, а так за тебя это делает компилятор. ИМХО так.

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

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

Можно поконкретнее? Что конкретно обозначают слова "забыли" и "помнит это за меня"? А то просто нету предмета для обсуждения.

WH>А что мне делать если пользователь ввел не верные данные?

Это вопрос по программированию или по какой теме? Наверное, в таких случаях надо:
1) Уж точно даже не пытаться работать с неверными данными.
2) Как можно скорее сообщить об этом пользователю, если это возможно.
3) Если пользователь не в состоянии быстро ответить, то перейти к выполнению какой-нибудь другой задачи, чтобы время не терять.

SYG>>Странный Вы. Component Pascal-ю более 10 лет между прочим.
WH>Если он такой крутой и ему уже 10 лет то почему на нем никто не пишет?
Я сам на работе на нем не пишу, но слышал, что есть такие конторы где пишут на оберонах (в основном для космоса, для беспилотных летательных аппаратов, электростанций и тому подобных вещей).

WH>А если еще учесть что исключения это классы, а их можно наследовать то допустим мы можем сделать file_exception и отнаследовать от него open_file_exception, read_file_exception... теперь нам фиолетово какое именно из этих исключений вылетело мы их все можем поймать при помощи catch(file_exception const& ex). А теперь сделай тоже самое на кодах возврата.

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

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

Вы можете возразить, что существуют некоторые потенциально опасные операции, перед выполнением которых невозможно точно знать смогут ли они быть выполнены или нет. Никакая проверка данных не может дать ответа на вопрос о том возможно ли выполнение этой операции. И вот именно в этих случаях без механизма исключительных ситуаций обойтись нельзя. Я принимаю такое возражение, соглашаюсь с ним. Однако давайте попробуем перечислить примеры таких операций:
1) Разыменование указателя не равного NIL.
2) "Насильное" приведение типов.

Подробно:
1) Никогда нельзя знать "повис" указатель или нет. Никакая проверка не может ответить на этот вопрос. Разыменование указателя — это рискованная операция. Нам остается только помолится и попробовать это сделать, в случае неудачи будет возбуждена исключительная ситуация, мы ее обработаем и все будет чики-пуки! Однако есть альтернатива — Сборщик мусора. Если в языке есть сборщик мусора, то в программе никогда не будет повисших указателей. Проблема решена. Разыменование указателя не равного NIL — абсолютно безопасна.

2) Надо всего лишь запретить "насильное" приведение типов. Точно так же как в свое время запретили инструкцию goto. Проблема решена. Разрешенные динамические преобразования типов абсолютно безопасны.

Если Вам известны еще примеры потенциально опасных операций правильный исход которых заранее проверить невозможно, то пишите, обсудим.

Здравствуйте, DarkGray.

Вы просто напросто используете термин "исключительная ситуация" для все чего ни попадя:

DG>для модуля "граф. редактор" — все эти ситуации исключительны, потому что граф. редактор хотел сохранить файл, а его обломали.

Тем не менее, ни в одном из приведенных Вами примеров не было по настоящему "исключительной ситуации", то есть такой когда программа выполняет некоторое действие другими словами называемое "недопустимая операция". Нельзя вычислить квадратный корень из отрицательного числа, нельзя разделить на ноль, нельзя работать с чужой памятью, но при этом, сколько угодно раз можно отказать в сохранении или открытии файла — это не является "недопустимой операцией". Разницу понимаете?


P.S.
К делу вообще-то не относится, но, видимо Вы еще и слово "модуль" используете для всего чего ни попадя. Нет такого модуля "граф. редактор". Программа "граф. редактор" — состоит из нескольких десятков модулей (а может и сотен). Модуль — это довольно мелкая единица, она меньше чем программа, но больше чем класс.

Программа >> Модуль >> Класс

Если Вы программируете на С++, то первым грубым приближением к понятию модуль будет просто один файл с исходным кодом, но этот файл компилируется в одну DLL-ку. Вот сколько файлов Вам понадобилось для написания программы "граф. редактор" — вот из стольки модулей она и состоит, причем каждый из них динамически загружается/выгружается во время работы программы. Язык С++ разумеется этого не поддерживает (так чтоб автоматом каждый файл в отдельную DLL-ку компилить), но в общем и целом модулем называется именно это.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Ну и чего вот Вы этим самым сказали?
Нет, позвольте. У меня длиннее!

AF> А вы как думаете — какой код можно назвать "серъёзным" или "сложным"?

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

AF>для меня "серъёзный" код — это код со сложной архитектурой и множеством взаимосвязей и взаимозависимостей.

А вот это бы я назвал именно сложным кодом.

AF> Наверняка у каждого из нас своя точка зрения по этому поводу.

Я придерживался не только "точкой зрения", но и значением слов "серьезный" и "сложный" в литературном русском языке.

Но есть и еще одно определение:

Серьезный код — код, который не вызывает приступов истерического смеха у серьезного программиста. (Желающие дать определение термину "серьезный программист" — welcome во флейм или юмор).

Пример не серьезного кода:

PROCEDURE TMainForm.Save;
VAR f: TIniFile;
BEGIN
  DeleteFile(PAnsiChar(FStoreFileName));
  f := TIniFile.Create(FStoreFileName);
  f.WriteInteger('Form', 'Left',   Left);
  f.WriteInteger('Form', 'Top',    Top);
  f.WriteInteger('Form', 'Width',  Width);
  f.WriteInteger('Form', 'Height', Height);
  f.Free;
END;

//------------------------------------------------------------------------------

PROCEDURE TMainForm.Load;
VAR f: TIniFile;
BEGIN
  f      := TIniFile.Create(FStoreFileName);
  Left   := f.ReadInteger('Form', 'Left',   Left);
  Top    := f.ReadInteger('Form', 'Top',    Top);
  Width  := f.ReadInteger('Form', 'Width',  Width);
  Height := f.ReadInteger('Form', 'Height', Height);
  f.Free;
END;

А теперь, почувствуйте разницу, пример серьезного кода:

RESOURCESTRING
   STORE_FILE_NAME_IS_EMPTY = 'Не задано имя инициализационного файла (StoreFileName = "")';

//------------------------------------------------------------------------------

CONST
  IDENT_Form    = 'Form';
  IDENT_Left    = 'Left';
  IDENT_Top     = 'Top';
  IDENT_Width   = 'Width';
  IDENT_Height  = 'Height';

//------------------------------------------------------------------------------

PROCEDURE TMainForm.Save;
VAR f: IniFiles.TIniFile;
BEGIN
  f := NIL;
  TRY
    IF Self.FStoreFileName = '' THEN RAISE SysUtils.Exception.Create(STORE_FILE_NAME_IS_EMPTY);
    IF SysUtils.FileExists(Self.FStoreFileName) THEN Windows.DeleteFile(PAnsiChar(Self.FStoreFileName));
    TRY
      f := IniFiles.TIniFile.Create(Self.FStoreFileName);
      f.WriteInteger(IDENT_Form, IDENT_Left,   Self.Left);
      f.WriteInteger(IDENT_Form, IDENT_Top,    Self.Top);
      f.WriteInteger(IDENT_Form, IDENT_Width,  Self.Width);
      f.WriteInteger(IDENT_Form, IDENT_Height, Self.Height);
    FINALLY
      f.Free;
    END;
  EXCEPT ON e: SysUtils.Exception DO Error(e, 'TMainForm.Save') END
END;

//------------------------------------------------------------------------------

PROCEDURE TMainForm.Load;
VAR f: IniFiles.TIniFile;
BEGIN
  f := NIL;
  TRY
    IF NOT SysUtils.FileExists(Self.FStoreFileName) THEN EXIT;
    TRY
      f := IniFiles.TIniFile.Create(Self.FStoreFileName);
      Self.Left   := f.ReadInteger(IDENT_Form, IDENT_Left,   Self.Left);
      Self.Top    := f.ReadInteger(IDENT_Form, IDENT_Top,    Self.Top);
      Self.Width  := f.ReadInteger(IDENT_Form, IDENT_Width,  Self.Width);
      Self.Height := f.ReadInteger(IDENT_Form, IDENT_Height, Self.Height);
    FINALLY
      f.Free;
    END;
  EXCEPT ON e: SysUtils.Exception DO Error(e, 'TMainForm.Load') END
END;

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

IP>О! настальгия... между прочим асм там был ничего. даже недокументированные команды были! И какие!
Ты случаем ностальгически не слушаешь программы Z80 через магнитофон? А то у меня где-то завалялись чудные записи.

С уважением, Gleb.

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

AF> Мы тут чудненько пофлеймили на тему "о применимости С++ в серьёзном коде" , но как то за кадром остался вопрос о том, что же такое "серьёзный код". Были правда некоторые попытки определить это понятие, но они быстро иссякли.
AF> А вы как думаете — какой код можно назвать "серъёзным" или "сложным"? Как Вы вообще — разделяете ли код по каким-либо критериям и на какие то категории? И если да, то по каким?

Я склоняюсь к мысли, что "серьезность" кода больше определяется его назначением, областью применения и т.п., нежели непосредственно его содержанием, например:
Делаем форму, кидаем не нее кучу контролов разных навороченных и делаем какую-нить процедуру отображения даных из БД на эту форму.

"Серьезный" код — если это используется в программе управления космическим кораблем или в программе управления биржевыми торгами.

Не "серьезный" код — все это написано для сдачи зачета в институте.

Другими словами, можно сказать, что чем больше отвественность лежит на коде, тем "серьезнее" код.

"Сложность" кода — это исходя их каких параметров оценки смотреть: сложность понимания, кодирования, поддержки, модификации и т.п.

З.Ы. Сложнее всего написать простой код -> "сложный" код — это есть простой код

Мы тут чудненько пофлеймили на тему "о применимости С++ в серьёзном коде" , но как то за кадром остался вопрос о том, что же такое "серьёзный код". Были правда некоторые попытки определить это понятие, но они быстро иссякли.
А вы как думаете — какой код можно назвать "серъёзным" или "сложным"? Как Вы вообще — разделяете ли код по каким-либо критериям и на какие то категории? И если да, то по каким?
Некоторые уже упоминались. Например "лохокод"
Подумав над данным вопросом сам, пришёл к выводу, что для меня "серъёзный" код — это код со сложной архитектурой и множеством взаимосвязей и взаимозависимостей. Какой нибудь навороченый алгоритм, с кучей условий (какая нибудь сложная сортировка или шифрование) — код сложный (алгоритмически), но тем не менее к серьёзному я его не отношу. По тем же причинам к серъёзному коду не отношу большинство модулей ОС, так как на мой взгляд — это код специфический — который должен быть написан крайне аккуратно и хорошо продуман, но чего-либо принципиально сложного в нем нет.
Наверняка у каждого из нас своя точка зрения по этому поводу. Предлагаю поделиться...

SYG>Теперь по пунктам.
DG>> 1. Выделение памяти
SYG>Выделение памяти для пользователей языка программирования является абсолютно безопасной операцией
SYG>NEW(p);
SYG>IF p # NIL THEN ... END;
SYG>Если памяти недостаточно, то процедура NEW() всего лишь навсего вернет пустой (NIL) указатель. Никаких исключительных ситуаций при этом не возникнет.

Чуть философски отвлечемся.
Есть старое изречение "Счастливы все одиннаковы, несчастливы — каждый по своему".
Это изречение можно применить и к программам, в том смысле, что работа без ошибок всегда одиннакова — работа программы всегда выполняется идет по одной трасе, но каждая ошибка уникальна, т.к. сразу меняется трасса работы программы.

Если каждую ошибку обрабатывать отдельно, то сразу возникает проблема комбинаторного взрыва, т.к. на каждую трассу "хорошего" выполнения у нас может быть 10, 100, миллион трасс выполнения с обработкой ошибок.

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

Для уменьшения этого комбинаторного взрыва применяется паттерн "транзакция" — если не выполнилась часть операции, то не выполняется вся операция с корректным откатом выполненных подопераций.
Для поддержки этого паттерна в языки были введены try/finally, деструкторы, исключения, using, декларируются такие под паттерны, как захват/освобождение ресурса должно оформляться в виде конструктор/деструктор.

Этот паттерн резко упрощает обработку ошибок, Т.к. теперь есть только один вид ошибки — нарушение нормального хода выполение программы. И уже не так важно, как именно этот ход нарушился.
Причем это нарушение может быть обработано на любом уровне, соответственно откатывая или не откатывая вышестоящие транзакции.

DG>> 2. Любые операции с внешним миром: операции с диском, сетью, интернетом, пользователем, другими программами и т.д.
DG>> 3. Для случая распределенной программы, вообще, любой вызов функции может закончится неудачей, т.к. может быть именно в этот момент пропала связь с удаленным модулем.

SYG>Все эти операции абсолютно безопасны. Не читается дискета? — Великолепно, так и сообщим пользоваелю что не читается дискета, при чем здесь исключительная ситуация? Буфер порта TCP/IP протокола пустой — так и скажем пользователю что интернет упал. Где здесь исключение? Другая программа не отвечает — великолепно, не больно то и хотелось. Здесь нигде нет ни одной исключительной ситуации. Все ситуации — штатные, обычные, заранее известные.

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

1. Во-первых, как подоперация, которая обращается к дискете узнает, кто такой "пользователь"? И значит, как она ему выдаст ошибку? Может быть программа, вообще, работает в автоматическом режиме и никакого пользователя нет.
2. Во-вторых, кто будет все эти варианты разбирать и описывать? И сколько вариантов по Вашему надо обработать вариантов, у того простого действия, как запись файла на диск?


SYG>Вам не удалось привести ни одного примера потенциально опасной операции чей фатальный исход невозможно предугадать заранее путем проверки входных данных. Примеры, которые Вы привели, абсолютно безопасны просто в случае неудачи, например, возвращают FALSE вместо TRUE, но исключительных ситуаций они при этом не создают. Вы перепутали операции которые не могут быть выполнены — то есть завершаются фатально (например возвращая FALSE), с операциями которые во время выполнения приводят к возникновению исключительных ситуаций. К потенциально опасным операциям относятся: деление на ноль и другие арифметические переполнения, неправильный индекс массива, разыменование повисшего указателя, и, быть может, что-то еще. Но вот что?

Вы противоречите сами себе.
Что же опасного в делении на ноль? ЭТу операцию тоже можно заранее избежать:

if (y == 0)
  return error;
else
  z = x/y;

И с массивом ничего страшного не происходит

if (index < 0 || index >= array.length)
  return error;
else
  item = array[index];

даже с разименованием повисшего указателя нет ничего страшного:

if (!isAlive(pointer))
  return error;
else
  value = *pointer;

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

Вот Вы в соседнем топике вспоминали про модули, про инкапсуляцию, про уменьшение комбинаторики.
Но почему в рамках этого обсуждения сразу об этом забываете.
А ведь в данном случае программа тоже состоит из модулей, и отдельным модулям как можно меньше хочется знать об ошибках друг друга, чтобы не увеличивать комбинаторное число вариантов.
Рассмотрим, например, модуль графический редактор. Модуль граф. редактор попросил модуль "хранилище" сохранить данные, и при этом модулю "граф. редактор" не важно, почему модуль "Хранилище" на смогло сохранить файл: память кончилась, дискету вытащили, прав не хватило, программист при написании модуля "хранилище" накосячил — для модуля "граф. редактор" — все эти ситуации исключительны, потому что граф. редактор хотел сохранить файл, а его обломали. И необходимо менять "нормальную" трассу выполнения программы.

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

AF> Мы тут чудненько пофлеймили на тему "о применимости С++ в серьёзном коде" , но как то за кадром остался вопрос о том, что же такое "серьёзный код". Были правда некоторые попытки определить это понятие, но они быстро иссякли.
AF> А вы как думаете — какой код можно назвать "серъёзным" или "сложным"? Как Вы вообще — разделяете ли код по каким-либо критериям и на какие то категории? И если да, то по каким?

Судя по теме "о применимости С++ в серьёзном коде" единственный серьёзный код — это машинный код, набранный переключателями на панели управления.
Никаких толстенных стандартов на язык программирования, так как описание команд процессора умещается в тонкой книжке.
BTW, интеловский процессор не может исполнять серьёзный код, т.к. описание самого процессора занимает 3 тома.


Если серьёзно (сорри за каламбур), то серьёзный код — это миф, призванный удовлетворить самомнение пишушего его программиста.
Программа — это способ решить те или иные задачи. Если она написана в соответствии с требованиями, с заданным качеством и в срок, то IMHO без разницы, на каком языке написан код и как он выглядит (даже если это будет write-only код).

А _сложным_ может быть алгоритм, но не реализующий его код.

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

AF> Мы тут чудненько пофлеймили на тему "о применимости С++ в серьёзном коде" , но как то за кадром остался вопрос о том, что же такое "серьёзный код". Были правда некоторые попытки определить это понятие, но они быстро иссякли.
AF> А вы как думаете — какой код можно назвать "серъёзным" или "сложным"? Как Вы вообще — разделяете ли код по каким-либо критериям и на какие то категории? И если да, то по каким?
AF> Наверняка у каждого из нас своя точка зрения по этому поводу. Предлагаю поделиться...
Серьезный код — это код, который делается не дял себя. Например, диплом. Это уже серьезно, так как диплом надо защищать и демонстрировать работоспособность системы. Если вы мне скажете, что диплом никто не читает, так вы ошибетесь — я читаю.
В общем, серьезный код — это код, оттогаемый от разработчика и используемый другими людьми.

Здравствуйте,
Может серьезный код — код где можно сделать серьезные ошибки.

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

A>типа вот . Супер простой код без взаимосвязей. Ну уж очень большой .
A>http://kernelmapper.osdn.com/map.php

Ага, захотел нас напугать фракталами?

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

S>А еще при отладке плагинов под Адобы заметно, что там есть собранный в дебаге код

наверно, он у них в релизе не заработал, вот и решили не напрягаться

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

IT>Не знаю какой код можно назвать "серьёзным", но вот "пальцастым" называется код, который пишут только настоящие пацаны

Пальцаны?

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

WH>Практика показывает что очень часто от ГЦ поблем больше чем пользы. Тк время уничтожения объекта недетерминировано то возникает проблема с освобожедением внешних ресурсов.

Какие проблемы?

WH>А отсутствие исключений это гемор тот еще... Попробуй вернуть ошибку на 10 уровней наверх без исключений...

Зачем возвращать ошибку?

WH>Короче мертворожденный продукт. Он не сможет конкурировать ни С++ на полу С++ ни с .НЕТ на полу .НЕТ. Ибо и тому и другому проигрывает по возможностям. Накой это язык вобще нужен не понятно.

Странный Вы. Component Pascal-ю более 10 лет между прочим.

Просто когда есть Сборщик мусора, проектировать все надо совершенно по другому, а это как-то непривычно.


Мысли на счет исключений:
Исключения бывают "вредные" — то есть те которые и быть-то не должны — они сигнализируют о сбое работы программы, если они возникают, значит программа написана криво; а бывают "полезные" — это те исключения, которых ожидают и обрабатывают согласно логике работы программы, они заранее были запланированы. Так вот в Component Pascal так сказать "вредные" исключения (выход индекса за пределы массива, неправильное приведение типа, не предусмотренный вариант выбора в инструкции CASE и т.п.) — просто автоматически немедленно останавливают работу программы и все — программиста на мыло! А все "полезные" исключения всегда можно реализовать вовсе каким-нибудь другим способом, а не через собственно механизм исключений, если подумать конечно. Так что механизм исключений излишен.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Все это совершенно обычно. А вот разделить на ноль нельзя никогда, даже после дождичка в четверг и то нельзя разделить на ноль, даже если долго упрашивать компьтер и танцевать с бубном, все равно нельзя — это недопустимая операция была есть и будет вечно.
Вот пример:

#pragma warning( disable : 4756; disable : 4723)
    const double oo = 1 / inline_fabs( 0);      // positive infinity
#pragma warning( default : 4723; default : 4756)

oo — это "+бесконечность", очень удобная константа. я её использовал в качстве границы для свой функции вычиления пределов.
Очень лаконичный и прозрачный код при этом получался

SYG> По чужому адресу нельзя писать и читать ни сегодня ни завтра ни через сто лет — это недопустимая операция.
В досе можно. Кстати, что считать "чужим" адресом. Для ОС и её расширений вся память — своя. И во всяком случае, попытка записи в чужой адрес ещё не повод останавливать процесс. всякое бывает...

SYG> Нелья вычислить значение квадратного корня из отрицательного числа ни сегодня ни завтра ни через сто лет — это недопустимая операция.
Хм, уж вам, как кандидату физико-математических наук, говорить это должно быть стыдно А мнимые числа?

SYG>А если мы сделаем DLL-ку размером 1 гигабайт, то это все равно будет DLL-ка или это уже будет что-то другое? Утрированное понятие модуля — это самая обычная DLL-ка, динамически загружаемая единица исполнения.
SYG>Word — это приложение работающее под OS Windows. Виндос не является модульной ОС и не обладает единым сборщиком мусора. Под Виндос нельзя писать полноценные многомодульные программы. Виндозные DLL-ки не обслуживаются никаким единым Виндозным сборщиком мусора. Я упоминал про BlackBox — это эмуляция ОС Оберон под Виндос. Микрософт сейчас ляпает платформу .NET — для того чтобы можно было писать многомодульные программы.
Ну правильно, сначала за уши притягиваем аналогию между модулями Оберона и DLL-ками виндов, а потом мастерски доказываем, что виндовые модули, по сравнению с обероновскими ни на что не годятся

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

AR>>(можно вспомнить Саттера с его 23 вариантами выполнения четырех строк внешне "несерьезного" кода).

A>Кого вспомнить?

Такие имена нужно знать, как Маркса/Энгельса

A>Можно линк?

На главной странице сайта есть ссылка "Поиск".
Пользуйся! (Рекомендация лучших поисководов!)

Автор: http://www.gotw.ca/
Упомянутая книга: http://www.informit.com/title/0201615622
Русский перевод: http://books.dore.ru/bs/f1bid197.html
Пиратский вариант оригинала: http://anatolix.naumen.ru/cppbooks.htm
Интересные комментарии: http://ders.angen.net/cpp3/xcppcomm/xcppcomm.html

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

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

AF>> А вы как думаете — какой код можно назвать "серъёзным" или "сложным"?

Vi2>Наверное,

Vi2>серъёзный код — это код, за который дают серьезные деньги. Весь остальной код — несерьезен, за него дают или мало, или вообще ничего.



Vi2>сложный код — это код, который не может быть написан программистом ниже определенного
уровня.

Сложность кода это его характеристика, которая вполне измерима математически и выражает простоту(сложность) его понимания, модификации, поддержки, вероятность наличия в нем ошибок, возможность и затраты на его тестирование и т.д.
Например http://www.sei.cmu.edu/str/descriptions/cyclomatic_body.html

Vi2>Весь остальной код — несложен, его пишет или любой новичок, или никто не пишет.

Как раз наоборот — программист выше определенного (и достаточно высокого) уровня будет писать максимально простой код

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


AF> Подумав над данным вопросом сам, пришёл к выводу, что для меня "серъёзный" код — это код со сложной архитектурой и множеством взаимосвязей и взаимозависимостей.

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

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Ну и чего вот Вы этим самым сказали? Кто Вас за язык-то тянул? Вы самолично только что расписались в том, что используя язык С++ для решения какой-либо (быть может очень сложной) задачи предметной области, Вы обрекаете самого себя еще и на решение (быть может не менее сложных) задач присущих самому языку С++ без относительно к задаче предметной области.
Хм!? Разве масте-поинтеры это сложно? Я один раз потратил пол часа на реализацию мастер-поинтеров и теперь спокойно их использую.
SYG>То есть вынуждены будете напрягаться больше чем необходимо. И все это в топике "Серьезный код", в котором уже не раз подразумевалось, что серьезный код должен быть на столько простым на сколько это вообще возможно.
Вот именно. В базовой реализации просто не возможно предусмотреть все что может понадобится и код получится больше и сложнее.
Я пару раз расширял интерфейс своих мастер-поинтеров для того чтобы упростить их использование. Короче написав десяток строк я съекономил десятки тысячь строк.
Слабо сделать такое с тем что реализовано в языке?

Я на счет finally это не в C++ при помощи автоматических деструкторов эмулируют finally, а в других языках при помощи finally эмулируют автоматические деструкторы.
Надеюсь не надо обьяснять почему код написаный однажды лучше кода написаного тысячи раз.

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


AF> А какой код пишут "настоящие пацаны"? Кстати на чём? С? С++? C#? Ещё что то более пацанское?

ASM процессора Z80.

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

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

A>>типа вот . Супер простой код без взаимосвязей. Ну уж очень большой .
A>>http://kernelmapper.osdn.com/map.php

AD>Ага, захотел нас напугать фракталами?

Ты имеешь в виду, что серъёзный код это тот, которым можно людей пугать?

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

IT>Тогда получается, что российские программисты пишут не серьёзный код. Зато американские всегда серьёзный, даже индусы и китайцы

Вчера наблюдал результат творчества программистов Адобы (ИндизайнЦС). Я бы этих уродов выгнал бы на улицу. Не, лучше отправить в китай или индию. Большего они не стоят.

Здравствуйте, S.Yu.Gubanov, Вы писали:


SYG>А теперь, почувствуйте разницу, пример серьезного кода:
SYG>[pascal]

SYG>PROCEDURE TMainForm.Save;
SYG>VAR f: IniFiles.TIniFile;
SYG>BEGIN
SYG> f := NIL;
SYG> TRY
SYG> IF Self.FStoreFileName = '' THEN RAISE SysUtils.Exception.Create(STORE_FILE_NAME_IS_EMPTY);
SYG> IF SysUtils.FileExists(Self.FStoreFileName) THEN Windows.DeleteFile(PAnsiChar(Self.FStoreFileName));
SYG> TRY
SYG> f := IniFiles.TIniFile.Create(Self.FStoreFileName);
SYG> f.WriteInteger(IDENT_Form, IDENT_Left, Self.Left);
SYG> f.WriteInteger(IDENT_Form, IDENT_Top, Self.Top);
SYG> f.WriteInteger(IDENT_Form, IDENT_Width, Self.Width);
SYG> f.WriteInteger(IDENT_Form, IDENT_Height, Self.Height);
SYG> FINALLY
SYG> f.Free;
SYG> END;
SYG> EXCEPT ON e: SysUtils.Exception DO Error(e, 'TMainForm.Save') END
SYG>END;

В данном серьезном коде допущена серьезная ошибка. Создание объекта TIniFile должно быть вынесено из блока try..finally


f := IniFiles.TIniFile.Create(Self.FStoreFileName);
TRY
f.WriteInteger(IDENT_Form, IDENT_Left, Self.Left);
f.WriteInteger(IDENT_Form, IDENT_Top, Self.Top);
f.WriteInteger(IDENT_Form, IDENT_Width, Self.Width);
f.WriteInteger(IDENT_Form, IDENT_Height, Self.Height);
FINALLY
f.Free;
END;

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Придется использовать классы обертки — "умные указатели", а это уже из другой оперы.
Ну почемуже из другой оперы? Очень даже из тойже самой... Автоматические деструкторы рулят

scoped_ptr<Taaa> a(make_Taaa());
scoped_ptr<Tbbb> b(make_Tbbb());
scoped_ptr<Tccc> c(make_Tccc());

Затараты памяти и производительность не изменятся.
Хотя я обычно использую объекты с интрузивным подсчетом ссылок.

SYG>Вот уж кто в таких случаях на самом деле по взрослому рулит, так это (компилируемый) язык со сборщиком мусора и без "исключительных ситуаций", например, Component Pascal (http://www.inr.ac.ru/~info21/cpascal/cp_report_1.4_rus.htm)
Практика показывает что очень часто от ГЦ поблем больше чем пользы. Тк время уничтожения объекта недетерминировано то возникает проблема с освобожедением внешних ресурсов.
А отсутствие исключений это гемор тот еще... Попробуй вернуть ошибку на 10 уровней наверх без исключений...
Короче мертворожденный продукт. Он не сможет конкурировать ни С++ на полу С++ ни с .НЕТ на полу .НЕТ. Ибо и тому и другому проигрывает по возможностям. Накой это язык вобще нужен не понятно.

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

WH>Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>>Можно поконкретнее? Что конкретно обозначают слова "забыли" и "помнит это за меня"? А то просто нету предмета для обсуждения.
WH>Пример на C#
WH>

WH>        static void Main(string[] args)
WH>        {
WH>            FileStream file=File.Create("some.file");

WH>            file.Close();
WH>        }
WH>

WH>если забыть сделать file.Close() то фаил не будет закрыт до сборки мусора.
WH>В С++
WH>

WH>    std::fstream file("some.file");
WH>    file.close();
WH>

WH>file.close() делать не обязательно ибо фиал будет закрыт в деструкторе fstream при выходе переменной file из области видимости.


Это, мягко говоря, немного устаревший способ работы с файлами. Всвязи с появлением ООП, люди уже более десятка лет с файлами работают на более высоком уровне абстракции. Могу вкратце описать как это делается в системе BlackBox от Oberon Microsystems. В этой системе для этой цели используется паттерн проектирования под названием "Carrier-Rider-Mapper". Carrier — это персистентный объект содержащий внутри себя какие-либо данные (можно думать о нем как об объектно-ориентированном аналоге устаревшего понятия — "файл"). Для простоты примера давайте предположим, что речь идет о файле с текстом. Carrier — это персистентный объект внутри которого инкапсулирован текст. Доступ к этому тексту одновременно можно предоставить сразу нескольким клиентам, например, открыть несколько окон с одним и тем же содержимым. Каждый клиент должен, как минимум, знать в каком месте текста он в данный момент имеет "текущую позицию". Так как количество клиентов произвольное, то информация о текущей позиции не может хранится в самом объекте Carrier, для этих целей объект Carrier умеет создавать так называемые Rider-объекты (паттерн — "итератор"). Так что клиенты обращаются не на прямую к объекту Carrier, а посредством Rider-ов. Между Carrier-ом и Rider-ами существует отношение один-ко-многим. Аналогично Rider-ам объект Carrier может создавать объекты Writer-ы, которые умеют "писать", в отличие от "читающих" Rider-ов. На этом приключения не заканчиваются. Кроме Carrier, Rider-ов и Writer-ов существуют еще так называемые Mapper-ы. Дело в том что Rider-ы и Writer-ы представляют низкоуровневый интерфейс (теоретически, вплоть до: записать один байт, прочитать один байт). Mapper-ы — это объекты-прослойки между Rider-ами, Writer-ами и клиентами. Они предоставляют более высокоуровневый уже проблемно-ориентированный набор операций для чтения и записи. Разные приложения могут использовать разные Mapper-ы работая с одним и тем же Carrier-ом.

Пример:
Client <-- Scanner <-- Reader <-- Carrier
Client --> Formatter --> Writer --> Carrier

Scanner и Formatter — это Mapper-ы.

Вобщем, клиенты общаются с Carrier-ом даже не через Reader/Writer, а через Mapper-ы. Сами Reader/Writer-ы нужны для того чтобы предотвратить комбинаторный взрыв количества реализаций разных мапперов под разные кариеры. Если есть n-штук Carrier-ов и m-штук Mapper-ов, то в этом случае надо написать реализацию только для n+m полиморфных переменных, а вовсе не для n*m как могло бы быть без Reader/Writer-ов.

Теперь вернемся к Вашему вопросу о "забыть сделать file.Close() то фаил не будет закрыт до сборки мусора". Понимаете в чем дело-то, клиент понятия не имеет о том сколько еще других клиентов приконнекчено к Carrier-у, а значит клиент в принципе не может выполнить операцию file.Close(), в интерфейсах форматтеров, райдеров, врайтеров и карьеров такой операции нет по принципиальным причинам. Подконнекчиваясь к кариеру клиенту совершенно безразлично был ли это кариер только что создан (только что открыли файл) или он уже существовал (файл уже был открыт кем-то другим). Клиент получает в свое пользование Carrier-скую полиморфную переменную и делает с ней что хочет, а потом забывает о ней. Так же поступают другие клиенты. Сам же Carrier являясь персистентным объектом, всегда существует в единственном экземпляре, то есть Ваши опасения по забывчивости открыть несколько раз один и тот же файл совершенно напрасны (работает некоторая модификация паттерна Singleton).

Теперь, собственно, при чем тут сборщик мусора. Рассмотрим более общую ситуацию. Пусть есть многомодульная система. Большинство модулей на момент написания не имели никакого представления друг о друге. Модули — единицы компиляции и исполнения программы, они могут динамически загружаться/выгружаться во время работы Программы. Под Программой, можно понимать всю операционную систему, а модули — ее расширения. Модули создают внутри себя объекты и в виде полиморфных переменных передают их для использования другим модулям, те модули, в свою очередь, могут передать эти полиморфные переменные третьим модулям и т.д.. Модуль создавший обьект и отдавший его другому модулю в принципе понятия не имеет кто еще пользуется этим объектом и как долго он это намерен делать. А значит модуль-создатель в принципе не может нести ответсвенность за уничтожение им созданного объекта. Но никакой другой модуль тоже в принципе не может нести ответсвенность за уничтожение чужого объекта. Подсчет ссылок на объект проблемы не решает поскольку, в общем случае, возможны замкнутые петли (циклические) ссылки объектов друг на друга. Утечка памяти в многомодульных системах неизбежна по принципиально неразрешимым причинам. Единственным выходом из этой ситуации является наличие единого на всю операционную систему полноценного сборщика мусора. Сборщик мусора — это не роскошь, и не фича придуманная для ленивых программистов. Сборщик мусора — это осознанная необходимость. Существование многомодульныех систем, модули которых обмениваются друг с другом объектами, невозможно без одного на всех полноценного сборщика мусора.

//----------------------------------------

Паттерн Carrier-Rider-Mapper был получен в результате исследовательского проекта "Insight ETHOS: On Object-Orientation in Operating Systems" Clementh Szyperski; Zьrich, 1992. (также этот паттерн сейчас известен как "Bridge pattern" — это по классификации "Банды четырех" Гамма, Хелм, Джонсон, Влиссидес). Клеменс Шиперский — один из со-основателей компании Oberon Microsystems. Также он является основоположником КОП — компонентно ориентированного программирования. Его статья о том что такое КОП и почему одно лишь "голое" ООП само по себе не состоятельно, датируется кажется то-ли 1994, то-ли 1995 годом (под рукой нет, я ее засунул куда-то). Сейчас он работает в Микрософте, платформа .NET позаимствовала от ОС Оберон кое-что.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SW>>Ответ на оба вопроса — Master Pointers ("ведушие указатели", Джеф Элджер, например). Нет никакой "другой оперы".

SYG>Это как раз и есть та самая "другая опера". "Другая опера" связа с тем как в С++ появляются эти самые умные, ведущие и прочие указатели. Они возможны в силу того что в С++ есть шаблоны. То что шаблоны — это точно "другая опера" Вы согласны? В свою очередь, шаблоны столь эффективны благодаря тому, что есть перегрузка операторов. То что перегрузка операторов — это точно "другая опера" Вы согласны? Вы вот, сможете без шаблонов и перегруженных операторов создать реализацию обертки указателя? Ответ — нет, не сможете.
Право, я вас уверяю, это не "другая опера", это язык С++. Это штатные средства языка С++. Что в этом плохого, как вы считаете?

SYG>Для того чтобы всего лишь навсего эмулировать действие FINALLY Вам понадобится использовать грандиознейший по своему размаху механизм под названием "шаблоны"+"перегрузка операторов"+"автоматический вызов деструкторов для стековых объектов". Безусловно это уже другая опера. А вот в Delphi для этого просто ввели одно дополнительное словечко — FINALLY и проблемы не стало.
О, ничего грандиозного, всё очень просто. И не для эмуляции действия FINALLY это делается. Сама мысль о эмуляции того-чего-не-нужно в С++ странна. Master Pointers это идиома и уповать на то, что такие идиомы не встроены в язык странно. Поскольку С++ в некотором роде является языком для описания идиом и писания идиомами. В этом гибкость и красота. Я могу воспользоваться другой идиомой. А Delphi — ссылки на объекты и только.

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

DG>Даже повторю Ваши слова "и для программы не должно быть сюрпризом, что иногда на данную переменную делить нельзя, а иногда можно."
DG>Могу даже довести ситуацию с файлами к ситуации с делением на ноль.
DG>Например, файл с именем ":" создать никогда нельзя, даже после дождика в четверг, но по Вашему получается, что это все равно не исключительная ситуация.

Мне что теперь, каждую свою фразу окружать сонмищем оговорок, в которых описывать все варианты ее истинности и толкования? Разумеется мы делим на переменную, и чтобы не совершить недопустимую операцию нам надо сначала проверять ее на неравенство нулю. А перед тем как создавать файл надо разумеется проверить его имя на допустимость. Но разница между этими двумя случаями состоит в том, даже не знаю как и объяснить-то, компьютер так что ли устроен, что делить на ноль он не может ну никак, а вот файл с недопустимым именем создает не компьютер, а программа, и она увидев недопустимое имя, просто не будет создавать такой файл и все, ничего страшного и исключительного не произойдет. Я не знаю как еще объяснить. Мне для этого компьютерной грамотности не хватает.

DG>Фиг с ними с Dll-ками, Вы так и не ответили, что такое модуль?
DG>хм, т.е. я, правильно, понял что "истинные модули" есть только в обероне, а во всех остальных языках — это так, одно название?

Да, Вы правильно поняли. Вот например Дельфийский UNIT — это не модуль. Он хоть и является единицей инкапсуляции и компиляции, но вот динамически загружаемой/выгружаемой единицей исполнения не является.

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

Модуль — это:
во-первых, абстракция языка программирования являющаяся единицей инкапсуляции и компиляции (весь исходный код программы находится в модулях)
во-вторых, являющаяся единицей исполнения. Во время выполнения программы модули динамически загружаются/выгружаются (позднее связывание).
в-третьих, на саму систему (в которой эти модули работают) налагается ограничение — обязательно должен быть единый сборщик мусора (это для того чтобы модули могли безбоязненно создавать внутри себя объекты и передавать их другим модулям, а те третьим и т.д.).

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

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

SYG>>Отсечка неправильных данных должна произойти на входе данных в систему. То есть, пользователь ввел неправильные данные, а они раз, и не ввелись, а выскочило диалоговое окно — "Введенные данные не правильные." Внутри системы неправильных данных быть не должно.

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

Вообще на этот вопрос я уже отвечал
http://www.rsdn.ru/Forum/Message.aspx?mid=723202&amp;only=1

Автор: S.Yu.Gubanov
Дата: 16.07.04

SYG>>>Во-первых, если Вам обязательно надо что-то возвращать, то ни кто не заставляет Вас возвращать именно номер_кода_ошибки. Возвращайте пожалуйста полиморфную переменную внутри которой инкапсулирована информация о причине отказа выполнить операцию — то есть все так же как и при механизме исключений — "фиолетово". Сборщик мусора поможет Вам не беспокоится о возможной растрате памяти на эти полиморфные переменные.
SYG>>>Во-вторых, Вы не обязаны что-то возвращать. Если Вам известно что какая-то операция потенциально опасна, то прежде чем ее выполнять, Вы "морально обязаны" проверить правильность параметров (проверить индекс массива на попадание в нужный диапазон, проверить указатель на неравенство NIL, проверить динамический тип полиморфной переменной, проверить не получится ли у Вас арифметическое переполнение, деление на ноль и т.д.) и только после того как Вы убедились в том, что данные правильные, вот только после этого приступать к выполнению потенциально опасной операции. Если в этом случае эта операция все-равно провалится, то поскольку согласно логике программы данные правильные и никакой ошибки быть не должно — это означает, что причина ошибки находится вне логики программы (кто-то отцепил жесткий диск, повредил молотком процессор и т.п.), следовательно дальнейшее выполнение программы не имеет смысла.

Если никакого пользователя нет, а данные поставляются из одной программы внутрь другой, то все очень просто. У программы принимающей данные есть задокументированный интерфейс по которому она должна работать. Если программа-поставщих-данных нарушает этот интерфейс поставляя некорректные данные, то она сама виновата. Реакция программы-приемника на некорректные данные будет такой как оговорено в ее интерфейсе. Если в интерфейсе ничего не оговорено, то есть вариант по умолчанию — модуль аварийно завершает свою работу. Именно такое поведение системы по умолчанию превращает "моральную обязанность" (вначале данные проверять прежде чем заставлять с ними кого-то работать) из простого пожелания в материальное жесткое требование, то есть это уже не моральная обязанность, а самая настоящая обычная обязанность. А это уже является главной основой построения сверхнадежных систем. Таким образом сам язык программирования заставляет писать надежный код.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Вот и слава богу, что для такого способа решения задач он не предназначен!
Таких задачь огромное колличество. Вот я писал OPC серверы. Я бы повесился если бы в С++ небыло исключений.

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

SYG>Опыт опыту — рознь, Я, благодаря интернету, знаю одного человека, который с Вами бы в этом вопросе сильно не согласился. В форуме на progz.ru он известен под ником ASU:
Ну давай его сюда. Пусть не соглашается.

SYG>А метода у него "простая": проектировать все сразу и, по возможности, без ошибок.
Он Бог? К томуже смотря на человечество я не уверен в том что Бог не совершает ошибок

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

А я вот разделяю подход, который ув.С.Ю.Губанов безуспешно пытается донести
до всех вас. Более того! (тсссс) я и сам такой использую
Честно, хороший подход. А вы ему минусы, минусы...

SYG>>Вот и слава богу, что для такого способа решения задач он не предназначен!
WH> Таких задачь огромное колличество. Вот я писал OPC серверы. Я бы повесился если бы в С++ небыло исключений.

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

SYG>>Думаю, что ПО для электростанции под эту категорию подходит в самый раз.
WH>А я писал софт для нефтяных заводов. Там надежность тоже должна быть мягко говоря на высоте.

(умалчивая)

SYG>>А метода у него "простая": проектировать все сразу и, по возможности, без ошибок.
WH>Он Бог? К томуже смотря на человечество я не уверен в том что Бог не совершает ошибок

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

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

AF> Мы тут чудненько пофлеймили на тему "о применимости С++ в серьёзном коде" , но как то за кадром остался вопрос о том, что же такое "серьёзный код". Были правда некоторые попытки определить это понятие, но они быстро иссякли.

Правильно сказали что есть разница между серьезным и сложным. Серьезность кода это серьезности задачи, а серьезность задачи вообще управленческая область.

Про сложность и классификации . Если не брать в расчет предметную область, то тогда получается 2 измерения: слабая/сильная детерминированность, слабая/сильная абстрактность. Хотя может показаться что это что-то близкое, я думаю что нет. Если же взять еще и предметную область (живем же в реальном мире), то тогда 3 измерение — специфичность этой области.

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

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

я лично думаю, что формулировка плохая. Нет понятия серьезный код или несерьезный, как мнекажется. Есть понятие "серьезная задача".

SYG> Если в интерфейсе ничего не оговорено, то есть вариант по умолчанию — модуль аварийно завершает свою работу. Именно такое поведение системы по умолчанию превращает "моральную обязанность" (вначале данные проверять прежде чем заставлять с ними кого-то работать) из простого пожелания в материальное жесткое требование, то есть это уже не моральная обязанность, а самая настоящая обычная обязанность. А это уже является главной основой построения сверхнадежных систем. Таким образом сам язык программирования заставляет писать надежный код.

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

Т.е. при тестовых должны караться любые, даже мелкие неточности, но при работе в реальных условиях — мелкие ошибки лучше "проглатывать", чтобы повысить общую надежность системы.

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

E>Запустил сейчас на RSDN поиск строки "Compоnent Pascal" — 13 ccылок. Из них наверное половина твоих.

Это просто говорит о том, что люди работающие с Оберонами не ходят на RSDN.

Oberon Microsystems: http://www.oberon.ch

Ресурсы на русском языке:
http://www.uni-vologda.ac.ru/oberon/
http://www.delphikingdom.com/asp/talktopic.asp?ID=285
http://www.inr.ac.ru/~info21/
http://progz.ru/forum/viewforum.php?f=49&amp;sid=56a9708aed3328e2ccca9d52b4c1a4d3

Здравствуйте, S.Yu.Gubanov, Вы писали:


SYG>Что значит упростить? Как Вы себе представляете работу динамической многомодульной системы? Как исключение передать из одного (бинарного) модуля внутрь другого (бинарного) модуля, а из того в третий и т.д. Вы себе можете представить? Все модули, разумеется, от разных производителей. Я и не говорил что без механизма исключений проще или удобнее, я говорю что без механизма исключений — ПОДРУГОМУ.
Ну в Windows'e же есть SEH! Вы скажете, что типа Windows — это не модульная ось, а потому там все подругому, или что-то в этом роде. Я не буду с вами спорить в этом вопросе, а только замечу, что любое поведение исключений всегда можно сэмулировать через коды возврата. Вы всем предлагаете делать это ВРУЧНУЮ. Да, действительно, это сделать можно, но это НЕУДОБНО. Мне, как программисту значительно удобней, когда это сделает компилятор
автоматически. В этом и заключается удобство. Я не вижу принципиальной разницы между исключениями и кодами возврата и я не понимаю, почему модули могут работать через коды возврата и не могут через исключения. В заключается неразрешимая проблема?

SYG>Вот сколько ни объясняй что сборщик мусора вовсе не является прихотью или роскошью придуманной для ленивых программистов, все равно найдется кто-то кто так и не поймет!
Это вы о ком? Случайно не обо мне? Что-то я не припоминаю за собой таких слов...
Я лишь говорил, что ТЕОРЕТИЧЕСКИ можно обойтись без сборщика мусора, точно так, как можно обойтись без исключений. Но в том и в другом случае это неудобно.

SYG>Что в этом такого сложного понять это??? Объясняю еще раз. Вот представьте себе что у Вас есть тысяча динамически загружаемых бинарных модулей все от разных производителей. Модули в процессе своей работы создают объекты (каждый модуль создает свои объекты). Для взаимодействия друг с другом эта тысяча модулей обмениваются друг с другом объектами (в виде полиморфных переменных). Объекты могут ссылаться друг на друга произвольным способом (то есть возможны циклические ссылки объектов из разных модулей друг на друга). КТО и КОГДА по Вашему должен вызывать delete для ненужных больше объектов? КАК узнать что объект больше никем не используется? Счетчик ссылок для этих целей не подходит так как возможны петлевые взаимоссылки. Учтите еще что на момент написания модуля НЕИЗВЕСТНО сколько и каких модулей еще будет в той ОС в которой он будет работать. Ну что? Дошло до Вас что задача вызова delete НЕРАЗРЕШИМА на момент написания модуля? Задача освобождения ресурсов может быть решена только ДИНАМИЧЕСКИ во время работы программы, а такая динамическая штуковина называется — СБОРЩИК МУСОРА.
Ой, сколько эмоций!
Вы понимаете, что в основе любого сборщика мусора лежит все тот же детерминированный вызов оператора delete? Вас это ни на какие мысли не наталкивает? Не кажется ли вам, что работа сборщика мусора может быть просто сэмулирована точно так, как вы предлагаете эмулировать обработку исключений через коды возврата? Выражаясь вашим языком, просто надо проектировать такую систему ПОДРУГОМУ. Да, это геморрой, да сборщик мусора — это хорошо, удобно и сладко, впрочем, так же как и исключения...

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

IT>>Не знаю какой код можно назвать "серьёзным", но вот "пальцастым" называется код, который пишут только настоящие пацаны

AF> А какой код пишут "настоящие пацаны"? Кстати на чём? С? С++? C#? Ещё что то более пацанское?
Настоящие пацаны пишут на С, С++, C#.
А настоящие профессионалы юзают ФОРТ!
Ибо так оно и есть.

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

Vi2>>серъёзный код — это код, за который дают серьезные деньги. Весь остальной код — несерьезен, за него дают или мало, или вообще ничего.
AF> Гениально! Мне очень понравилось.

Тогда получается, что российские программисты пишут не серьёзный код. Зато американские всегда серьёзный, даже индусы и китайцы

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

AF> Подумав над данным вопросом сам, пришёл к выводу, что для меня "серъёзный" код — это код со сложной архитектурой и множеством взаимосвязей и взаимозависимостей. Какой нибудь навороченый алгоритм, с кучей условий (какая нибудь сложная сортировка или шифрование) — код сложный (алгоритмически), но тем не менее к серьёзному я его не отношу. По тем же причинам к серъёзному коду не отношу большинство модулей ОС, так как на мой взгляд — это код специфический — который должен быть написан крайне аккуратно и хорошо продуман, но чего-либо принципиально сложного в нем нет.

типа вот . Супер простой код без взаимосвязей. Ну уж очень большой .

http://kernelmapper.osdn.com/map.php

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

IT>>Не знаю какой код можно назвать "серьёзным", но вот "пальцастым" называется код, который пишут только настоящие пацаны

AVK>Пальцаны?

Ну да. Иногда среди них встречаются "паскальцаны".

Здравствуйте, shev.

Я согласен с Вами в том, что код, который я привел

f := NIL;
TRY
  f := TMyObject.Create();
  //...
FINALLY
  f.Free;
END;

действительно может содержать грубейшую ошибку, но только в том случае если забыть написать инструкцию f := NIL. Постольку поскольку, я ее написать не забыл, то приведенный код не содержит ошибки. Что Вы накинулись -"Ошибка, Ошибка!!". Нет ошибки-то. О чем весь сыр бор? Может закончим на этом?


Я могу объяснить почему я использую именно такую конструкцию. Поначалу я тоже писал TRY после, а не до создания объекта, но потом перешел на этот стиль потому что, часто создаю несколько объектов (бывает даже по 10-15 штук):

a := NIL; b := NIL; c := NIL;
TRY
  a := TAaa.Create();
  b := TBbb.Create();
  c := TCcc.Create();
  //...совместное использование объектов a,b,c
FINALLY
  a.Free; b.Free; c.Free;
END;

Если бы я писал TRY после, то пришлось бы вкладывать блоки TRY FINALLY друг в друга:

a := TAaa.Create();
TRY
  b := TBbb.Create();
  TRY
    c := TCcc.Create();
    TRY
       //...совместное использование объектов a,b,c
    FINALLY
      c.Free;
    END;
  FINALLY
    b.Free;
  END;
FINALLY
  a.Free;
END;

код от этого раздувается, поэтому я так и не пишу, а пишу так как показал в самом начале.

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

WH>Здравствуйте, S.Yu.Gubanov, Вы писали:

WH>Кстати классный пример того почему С++ рулит...
WH>

WH>Taaa a;
WH>Tbbb b;
WH>Tccc c;
WH>...
WH>

WH>

Ну это быстренько можно "подпортить", и "рульность" С++ поубавится

1) Пусть a,b,c — это очень большие объекты, так что на стеке втроем им места не хватит...

2) Пусть a,b,c — это не объекты, а полиморфные переменные. В терминологии С++ статический тип a,b,c — пусть будет указатели на объекты "абстрактных классов". Так как в стандартном С++ есть только блок try catch, а FINALLY — нету, то жизнь сразу усложняется. Придется использовать классы обертки — "умные указатели", а это уже из другой оперы.



Вот уж кто в таких случаях на самом деле по взрослому рулит, так это (компилируемый) язык со сборщиком мусора и без "исключительных ситуаций", например, Component Pascal (http://www.inr.ac.ru/~info21/cpascal/cp_report_1.4_rus.htm)

Здравствуйте, S.Yu.Gubanov, Вы писали:

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

SYG>Зачем возвращать ошибку?
А что мне делать если пользователь ввел не верные данные?

SYG>Странный Вы. Component Pascal-ю более 10 лет между прочим.
Если он такой крутой и ему уже 10 лет то почему на нем никто не пишет?

SYG>Мысли на счет исключений:
Во первых о вредных исключениях надо расказать все что можно для того чтобы было легче устранить ошибку.
Во вторых на кой черт извращатся если можно кинуть исключение?
Мне влом выписывать и еще болие влом читать что-то типа:

error_code_t foo()
{
    error_code_t error_code;
    error_code=foo1();
    if(err_code!=error_none)
        return error_code;
    error_code=foo2();
    if(err_code!=error_none)
        return error_code;
    error_code=foo3();
    if(err_code!=error_none)
        return error_code;
    error_code=foo4();
    if(err_code!=error_none)
        return error_code;
    error_code=foo5();
    if(err_code!=error_none)
        return error_code;
    error_code=foo6();
    if(err_code!=error_none)
        return error_code;
    error_code=foo7();
    if(err_code!=error_none)
        return error_code;
}

когда я могу написать

void foo()
{
    foo1();
    foo2();
    foo3();
    foo4();
    foo5();
    foo6();
    foo7();
}

А если логика алгоритма сложная то за обработкой ошибок с которыми на этом уровне всеравно ни чего не сделать можно потерять сам алгоритм.
А если еще учесть что исключения это классы, а их можно наследовать то допустим мы можем сделать file_exception и отнаследовать от него open_file_exception, read_file_exception... теперь нам фиолетово какое именно из этих исключений вылетело мы их все можем поймать при помощи catch(file_exception const& ex). А теперь сделай тоже самое на кодах возврата.
И самое веселое если в некоторой подсистеме может происходить несколько типов ошибок (проблемы с файлами, сетью, пользователем...) что ты тогда будешь делать с кодами возврата?

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Мысли на счет исключений:
SYG>Исключения бывают "вредные" — то есть те которые и быть-то не должны — они сигнализируют о сбое работы программы, если они возникают, значит программа написана криво; а бывают "полезные" — это те исключения, которых ожидают и обрабатывают согласно логике работы программы, они заранее были запланированы. Так вот в Component Pascal так сказать "вредные" исключения (выход индекса за пределы массива, неправильное приведение типа, не предусмотренный вариант выбора в инструкции CASE и т.п.) — просто автоматически немедленно останавливают работу программы и все — программиста на мыло!

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

(шутка)

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

Вы почему-то априори считаете, что текущая выполняемая функция и вся программа — это одно и тоже, и из этого делаете вывод, что раз текущая функция не смогла выполниться, то значит надо закрывать всю программу.
Но для большинства задач — это не так.

Возьмем, например, браузер — коннект с сервером может быть в любой момент прерван, но весь браузер не должен закрываться.

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

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


SYG>Если Вам известны еще примеры потенциально опасных операций правильный исход которых заранее проверить невозможно, то пишите, обсудим.

1. Выделение памяти
2. Любые операции с внешним миром: операции с диском, сетью, интернетом, пользователем, другими программами и т.д.
3. Для случая распределенной программы, вообще, любой вызов функции может закончится неудачей, т.к. может быть именно в этот момент пропала связь с удаленным модулем.

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


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

DG>Вы почему-то априори считаете, что текущая выполняемая функция и вся программа — это одно и тоже, и из этого делаете вывод, что раз текущая функция не смогла выполниться, то значит надо закрывать всю программу.
DG>Но для большинства задач — это не так.

DG>Возьмем, например, браузер — коннект с сервером может быть в любой момент прерван, но весь браузер не должен закрываться.

DG>Или возьмем, например, текстовый редактор и операцию сохранения файла на дискету: дискета может быть битая и операция сохранения не выполнится, но это опять же не означает, что весь текстовый редактор необходимо при этом закрывать.

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


SYG>>Если Вам известны еще примеры потенциально опасных операций правильный исход которых заранее проверить невозможно, то пишите, обсудим.

DG>1. Выделение памяти
DG>2. Любые операции с внешним миром: операции с диском, сетью, интернетом, пользователем, другими программами и т.д.
DG>3. Для случая распределенной программы, вообще, любой вызов функции может закончится неудачей, т.к. может быть именно в этот момент пропала связь с удаленным модулем.


Видите ли, для начала надо просто понять одну простую вещь. Ничто внешнее по отношению к нашей программе ни при каких обстоятельствах никогда не может создать исключительную ситуацию здесь внутри нашей программы. Все что происходит внутри нашей программы делается только потому что программа так была написана. Ни что внешнее вообще понятия не имеет о внутренностях программы — в этом заключается принцип инкапсуляции. Вера в то что что-то внешнее способно само что-то сделать внутри программы сродни вере в целительную силу танцев с бубном. После того как мы поймем эту простую вещь наша дальнейшая жизнь будет значительно проще.
Теперь по пунктам.
DG> 1. Выделение памяти
Выделение памяти для пользователей языка программирования является абсолютно безопасной операцией
NEW(p);
IF p # NIL THEN ... END;
Если памяти недостаточно, то процедура NEW() всего лишь навсего вернет пустой (NIL) указатель. Никаких исключительных ситуаций при этом не возникнет.

DG> 2. Любые операции с внешним миром: операции с диском, сетью, интернетом, пользователем, другими программами и т.д.
DG> 3. Для случая распределенной программы, вообще, любой вызов функции может закончится неудачей, т.к. может быть именно в этот момент пропала связь с удаленным модулем.

Все эти операции абсолютно безопасны. Не читается дискета? — Великолепно, так и сообщим пользоваелю что не читается дискета, при чем здесь исключительная ситуация? Буфер порта TCP/IP протокола пустой — так и скажем пользователю что интернет упал. Где здесь исключение? Другая программа не отвечает — великолепно, не больно то и хотелось. Здесь нигде нет ни одной исключительной ситуации. Все ситуации — штатные, обычные, заранее известные.

Вам не удалось привести ни одного примера потенциально опасной операции чей фатальный исход невозможно предугадать заранее путем проверки входных данных. Примеры, которые Вы привели, абсолютно безопасны просто в случае неудачи, например, возвращают FALSE вместо TRUE, но исключительных ситуаций они при этом не создают. Вы перепутали операции которые не могут быть выполнены — то есть завершаются фатально (например возвращая FALSE), с операциями которые во время выполнения приводят к возникновению исключительных ситуаций. К потенциально опасным операциям относятся: деление на ноль и другие арифметические переполнения, неправильный индекс массива, разыменование повисшего указателя, и, быть может, что-то еще. Но вот что?

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

E>Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>>Мысли на счет исключений:
SYG>>Исключения бывают "вредные" — то есть те которые и быть-то не должны — они сигнализируют о сбое работы программы, если они возникают, значит программа написана криво; а бывают "полезные" — это те исключения, которых ожидают и обрабатывают согласно логике работы программы, они заранее были запланированы. Так вот в Component Pascal так сказать "вредные" исключения (выход индекса за пределы массива, неправильное приведение типа, не предусмотренный вариант выбора в инструкции CASE и т.п.) — просто автоматически немедленно останавливают работу программы и все — программиста на мыло!

E>Не, "автоматически немедленно" останавливать работу программы это полумера. Надо, чтобы она сама себя тут же и деинсталлировала и возвращала пользователю уплаченные за себя деньги, после чего "автоматически" коннектилась к сайту разработчиков и отправляла "на мыло" провинившегося программиста по имени "Component Pascal"

E> (шутка)


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

http://ders.angen.net/cpp3/xcppcomm/xcppcomm.html#149

Стр.149: Задача 2.14. Исключения в конструкторах. Часть 2
M: Item 18. Constructor Failures, Part 2: Absorption?

А теперь маленькое философское отступление. Те, кто писал действительно серьезный код знают, что исключений, возбуждаемых при ошибках программиста (напр. std::logic_error, который определяется стандартом как: для извещения об ошибках, которые, предположительно, могут быть обнаружены до выполнения программы) быть не должно. Самое лучшее, что мы можем сделать при обнаружении подобного рода ошибки -- это сразу же прервать выполнение программы, сгенерировав информацию, необходимую для определения сути происшедшего (напр. core dump). Дело в том, что "ошибка здесь" является, как правило, следствием "ошибки там" и продолжение исполнения некорректного кода в надежде на лучшее приведет к Ужасным Последствиям (напр. сумма, эквивалентная нескольким десяткам лет зарплаты программиста, будет зачислена на неизвестный счет где-нибудь в Буркина-Фасо. Но это, конечно, маловероятно, т.к. чаще всего обнаруженное несоответствие двойной бухгалтерии приводит к временной остановке всех операций до выяснения причин; а убыток от нескольких часов простоя серьезного банка приводит к гораздо более дорогостоящим последствиям...).

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

DG>Может все-таки стоило остановить только для данного самолета в данное время один единственный модуль, который рассчитывает расход горючего?

Что же Вы о создателях Оберон систем так плохо думаете? Разумеется будет остановлена работа только того модуля, который выполнил недопустимую операцию. Модуль будет динамически выгружен из системы. Когда другие модули запросят доступ к нему, он автоматически загрузится в память обратно. Так сказать — горячая перезагрузка — на лету. Вместо этого модуля, если угодно, может быть загружен модуль от другого производителя. Или, гипотетически, этот модуль будет "на лету" перекомпилирован заново, ошибка в нем исправлена, а его новый скомпилированный вариант динамически загружен в память. Что может быть устойчивее и надежнее? Вы бы, извините конечно, прежде чем глупые фантазии излагать вспомнили бы в каких областях Обероны используются: для случаев требующих особой безопасности — космос, электростанции, беспилотные летательные (военные) аппараты.


Ну как, можно считать вопрос на этом исчерпанным?

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>А теперь маленькое философское отступление. Те, кто писал действительно серьезный код знают, что исключений, возбуждаемых при ошибках программиста (напр. std::logic_error, который определяется стандартом как: для извещения об ошибках, которые, предположительно, могут быть обнаружены до выполнения программы) быть не должно. Самое лучшее, что мы можем сделать при обнаружении подобного рода ошибки -- это сразу же прервать выполнение программы, сгенерировав информацию, необходимую для определения сути происшедшего (напр. core dump). Дело в том, что "ошибка здесь" является, как правило, следствием "ошибки там" и продолжение исполнения некорректного кода в надежде на лучшее приведет к Ужасным Последствиям (напр. сумма, эквивалентная нескольким десяткам лет зарплаты программиста, будет зачислена на неизвестный счет где-нибудь в Буркина-Фасо. Но это, конечно, маловероятно, т.к. чаще всего обнаруженное несоответствие двойной бухгалтерии приводит к временной остановке всех операций до выяснения причин; а убыток от нескольких часов простоя серьезного банка приводит к гораздо более дорогостоящим последствиям...).

1. Core dump во многих случаях мало полезен (или вообще бесполезен).
Часто нужно более информативное, краткое и точное описание проблемы.
Вот некоторые (очевидные) аргументы:

— его неудобно читать (по сравнение с текстовым описание ошибки) и/или траспортировать (файл в 512мб по почте в службу поддержки уже не пошлешь)

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

- не стоит пугать пользователей бессмысленными сообщениями типа "Внутренняя ошибка приложения. Подробнее смотрите дамп памяти (512мб нулей и единиц), а лучше обратитесь в службу поддержки. В дельнейшем не рекомендуем Вам выполнять тот набор действий, который привел к ошибке (вы ведь наверняка должны точно помнить две сотни кнопок, которые нажали за последние три часа?)

Кстати, а хотя бы core dump твой ComponentPascal делать умеет?

2. Не всякие программы оперируют "суммами эквивалентными нескольким десяткам годовых зарплат программиста" . Говорят, что бываю такие, которые вообще никак с деньгами не связаны

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

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

- было возможность немедленно отправить разработчикам по почте багрепорт

- если это был текстовый редактор, то нужно предложить пользователю сохранить текст, который он набирал в последние несколько часов.

- были закрыты все файлы/коннекты-к-бд/сессии-работы-со-внешними-устройствами (например приводами чтения кредитных карт)

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

4. Напоминаю, что есть такая технология, называется "plug in".
Я так понимаю, ты предлагаешь разработчику основного приложения смириться с тем, что оно может быть в любой момент закрыто, если в одном из плагинов (даже не им написанных) произошла ошибка?
Как по мне, так лучше просто отключить проблемный плагин.

SYG>Вы просто напросто используете термин "исключительная ситуация" для все чего ни попадя:

DG>>для модуля "граф. редактор" — все эти ситуации исключительны, потому что граф. редактор хотел сохранить файл, а его обломали.

SYG>Тем не менее, ни в одном из приведенных Вами примеров не было по настоящему "исключительной ситуации", то есть такой когда программа выполняет некоторое действие другими словами называемое "недопустимая операция". Нельзя вычислить квадратный корень из отрицательного числа, нельзя разделить на ноль, нельзя работать с чужой памятью, но при этом, сколько угодно раз можно отказать в сохранении или открытии файла — это не является "недопустимой операцией". Разницу понимаете?

Нет, не понимаю.
Я не вижу разницу между операциями "Деление на ноль", "Взять неберущийся интеграл", "Открыть файл, которого нет на диске", "Открыть файл, который не доступен".

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


SYG>P.S.
SYG>К делу вообще-то не относится, но, видимо Вы еще и слово "модуль" используете для всего чего ни попадя. Нет такого модуля "граф. редактор". Программа "граф. редактор" — состоит из нескольких десятков модулей (а может и сотен). Модуль — это довольно мелкая единица, она меньше чем программа, но больше чем класс.

Вопрос на засыпку:
если мы несколько модулей объединили вместе, то какой "элемент" мы получили в итоге? сразу программу?


SYG>Программа >> Модуль >> Класс

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

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

SYG>Если Вы программируете на С++, то первым грубым приближением к понятию модуль будет просто один файл с исходным кодом, но этот файл компилируется в одну DLL-ку. Вот сколько файлов Вам понадобилось для написания программы "граф. редактор" — вот из стольки модулей она и состоит, причем каждый из них динамически загружается/выгружается во время работы программы. Язык С++ разумеется этого не поддерживает (так чтоб автоматом каждый файл в отдельную DLL-ку компилить), но в общем и целом модулем называется именно это.

Возьмем, например, Word.
Встроенный в Word граф. редактор диаграмм — на Ваш взгляд — это модуль, программа или класс?


ps
Мы с Вами очень подробно подискутировали о терминах, но по существу какие-то возражения будут?
Или в целом, Вы согласны с моими доводами?

DG>>Может все-таки стоило остановить только для данного самолета в данное время один единственный модуль, который рассчитывает расход горючего?

SYG>Что же Вы о создателях Оберон систем так плохо думаете?

Я думаю плохо не об Обероне, а о Вашей позиции "в случае ошибки необходимо останавливать всю программу".

SYG> Разумеется будет остановлена работа только того модуля, который выполнил недопустимую операцию. Модуль будет динамически выгружен из системы. Когда другие модули запросят доступ к нему, он автоматически загрузится в память обратно. Так сказать — горячая перезагрузка — на лету. Вместо этого модуля, если угодно, может быть загружен модуль от другого производителя. Или, гипотетически, этот модуль будет "на лету" перекомпилирован заново, ошибка в нем исправлена, а его новый скомпилированный вариант динамически загружен в память.

На словах все отлично.
Но непонятно, что в этом случае будет с модулями, которые использовали/вызывали данные модули? Они тоже будут выгружены? Или они получать сообщение об ошибке? Другими словами получат исключение?
Что будет с ресурсами, модулями и т.д., которые использовал выгружаемый модуль?
Что будет с ходом выполнения программы? Выполнение остановится? продолжится с какого-то места? еще что-то?



SYG>Ну как, можно считать вопрос на этом исчерпанным?

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

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

SW>Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>>Ну это быстренько можно "подпортить", и "рульность" С++ поубавится
SYG>>1) Пусть a,b,c — это очень большие объекты, так что на стеке втроем им места не хватит...
SYG>>2) Пусть a,b,c — это не объекты, а полиморфные переменные. В терминологии С++ статический тип a,b,c — пусть будет указатели на объекты "абстрактных классов". Так как в стандартном С++ есть только блок try catch, а FINALLY — нету, то жизнь сразу усложняется. Придется использовать классы обертки — "умные указатели", а это уже из другой оперы.
SW>Ответ на оба вопроса — Master Pointers ("ведушие указатели", Джеф Элджер, например). Нет никакой "другой оперы".

Это как раз и есть та самая "другая опера". "Другая опера" связа с тем как в С++ появляются эти самые умные, ведущие и прочие указатели. Они возможны в силу того что в С++ есть шаблоны. То что шаблоны — это точно "другая опера" Вы согласны? В свою очередь, шаблоны столь эффективны благодаря тому, что есть перегрузка операторов. То что перегрузка операторов — это точно "другая опера" Вы согласны? Вы вот, сможете без шаблонов и перегруженных операторов создать реализацию обертки указателя? Ответ — нет, не сможете. Для того чтобы всего лишь навсего эмулировать действие FINALLY Вам понадобится использовать грандиознейший по своему размаху механизм под названием "шаблоны"+"перегрузка операторов"+"автоматический вызов деструкторов для стековых объектов". Безусловно это уже другая опера. А вот в Delphi для этого просто ввели одно дополнительное словечко — FINALLY и проблемы не стало.

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

SYG>>Тем не менее, ни в одном из приведенных Вами примеров не было по настоящему "исключительной ситуации", то есть такой когда программа выполняет некоторое действие другими словами называемое "недопустимая операция". Нельзя вычислить квадратный корень из отрицательного числа, нельзя разделить на ноль, нельзя работать с чужой памятью, но при этом, сколько угодно раз можно отказать в сохранении или открытии файла — это не является "недопустимой операцией". Разницу понимаете?

DG>Нет, не понимаю.
DG>Я не вижу разницу между операциями "Деление на ноль", "Взять неберущийся интеграл", "Открыть файл, которого нет на диске", "Открыть файл, который не доступен".

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

DG>Вопрос на засыпку:
DG>если мы несколько модулей объединили вместе, то какой "элемент" мы получили в итоге? сразу программу?

А если мы сделаем DLL-ку размером 1 гигабайт, то это все равно будет DLL-ка или это уже будет что-то другое? Утрированное понятие модуля — это самая обычная DLL-ка, динамически загружаемая единица исполнения.

DG>Возьмем, например, Word.
DG>Встроенный в Word граф. редактор диаграмм — на Ваш взгляд — это модуль, программа или класс?
Word — это приложение работающее под OS Windows. Виндос не является модульной ОС и не обладает единым сборщиком мусора. Под Виндос нельзя писать полноценные многомодульные программы. Виндозные DLL-ки не обслуживаются никаким единым Виндозным сборщиком мусора. Я упоминал про BlackBox — это эмуляция ОС Оберон под Виндос. Микрософт сейчас ляпает платформу .NET — для того чтобы можно было писать многомодульные программы.

DG>Мы с Вами очень подробно подискутировали о терминах, но по существу какие-то возражения будут?
DG>Или в целом, Вы согласны с моими доводами?
Доводами о чем?

SYG>Файлы бывают не доступными, а еще файлы могут вообще отсутствовать на диске. Вы это знаете и программа Ваша тоже должна это знать. И для нее не должно быть сюрпризом то что файла нету. Это обычная штатная ситуация. Иногда файлы на диске есть, а иногда их нет. Иногда их можно прочитать/записать, а иногда бывает нельзя. Все это совершенно обычно. А вот разделить на ноль нельзя никогда, даже после дождичка в четверг и то нельзя разделить на ноль, даже если долго упрашивать компьтер и танцевать с бубном, все равно нельзя — это недопустимая операция была есть и будет вечно. По чужому адресу нельзя писать и читать ни сегодня ни завтра ни через сто лет — это недопустимая операция. Нелья вычислить значение квадратного корня из отрицательного числа ни сегодня ни завтра ни через сто лет — это недопустимая операция. Такую разницу понимаете?

не понимаю, Вы опять передергиваете.

Потому что операцию деления на ноль — вы воспринимаете, как деление на константу 0, а не как деление на переменную, которая иногда принимает в том числе и значение 0.
В этом случае, мы получаем все тоже самое, что и с файлами: что иногда мы делить на данную переменную можем, а иногда не можем.
Даже повторю Ваши слова "и для программы не должно быть сюрпризом, что иногда на данную переменную делить нельзя, а иногда можно."

Могу даже довести ситуацию с файлами к ситуации с делением на ноль.
Например, файл с именем ":" создать никогда нельзя, даже после дождика в четверг, но по Вашему получается, что это все равно не исключительная ситуация.

DG>>Вопрос на засыпку:
DG>>если мы несколько модулей объединили вместе, то какой "элемент" мы получили в итоге? сразу программу?

SYG>А если мы сделаем DLL-ку размером 1 гигабайт, то это все равно будет DLL-ка или это уже будет что-то другое? Утрированное понятие модуля — это самая обычная DLL-ка, динамически загружаемая единица исполнения.

Фиг с ними с Dll-ками, Вы так и не ответили, что такое модуль?


DG>>Возьмем, например, Word.
DG>>Встроенный в Word граф. редактор диаграмм — на Ваш взгляд — это модуль, программа или класс?
SYG>Word — это приложение работающее под OS Windows. Виндос не является модульной ОС и не обладает единым сборщиком мусора. Под Виндос нельзя писать полноценные многомодульные программы. Виндозные DLL-ки не обслуживаются никаким единым Виндозным сборщиком мусора. Я упоминал про BlackBox — это эмуляция ОС Оберон под Виндос. Микрософт сейчас ляпает платформу .NET — для того чтобы можно было писать многомодульные программы.

хм, т.е. я, правильно, понял что "истинные модули" есть только в обероне, а во всех остальных языках — это так, одно название?

S.Yu.Gubanov -> "Re[17]: Недопустимая операция = Исключительная ситуация" :

SG> это совершенно обычно. А вот разделить на ноль нельзя
SG> никогда, даже после дождичка в четверг и то нельзя разделить
SG> на ноль, даже если долго упрашивать компьтер и танцевать с бубном,
SG> все равно нельзя — это недопустимая операция была есть и будет

Хм... остатки знаний из инсттиута подсказывают, что при делении на ноль у
нас получится бесконечность и некоторые языки это поддерживают. Правда будет
ли в этом конкретный практический смысл — не ясно

SG> вечно. По чужому адресу нельзя писать и читать ни сегодня ни завтра
SG> ни через сто лет — это недопустимая операция. Нелья вычислить

Ну вот, а как же данные шарить между процессами?

SG> значение квадратного корня из отрицательного числа ни сегодня ни
SG> завтра ни через сто лет — это недопустимая операция. Такую
SG> разницу понимаете?

Ну да. Математики — враги народа — напридумывали всяких комплексных числел
Вон, DSP шники мучаются с преобразованиями Фурье

Yury Kopyl aka hrg | http://id.totem.ru | [TEAM Nemiroff борет]

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

DG>т.е. что все-таки должен сделать код, который вдруг увидел недопустимое имя файла?
Это философский вопрос или как?

Отсечка неправильных данных должна произойти на входе данных в систему. То есть, пользователь ввел неправильные данные, а они раз, и не ввелись, а выскочило диалоговое окно — "Введенные данные не правильные." Внутри системы неправильных данных быть не должно.

SYG>Точно не отвечу. Система BlackBox (эмулятор ОС Оберон под Виндос), кажется, переходит к выполнению следующей итерации своего главного цикла. Если есть исходный код модуля, то выскакиевает диалоговое окно со списком стека вызовов последних нескольких процедур со всеми значениями локальных переменных. Каждый элемент этого списка является гиперссылкой на соответсвующую позицию в исходном коде программы. С ресурсами ничего страшного не происходит — всем управляет единый сборщик мусора. Как конкретно обстоят дела в нативной ОС Оберон и ее многочисленных клонах я не знаю. Кроме того, есть еще парралельные системы, например, Blue Bottle на Active Oberon — там парралельность интегрирована в сам язык. Как там все внутрях устроено я еще тоже не знаю.


Но здесь опять же возникает вопрос, а как система узнает о том, что произошла ошибка? Получает некий сигнал? Чем этот сигнал отличается от исключения из "стандартных" языков программирования?

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

DG>Стандартный пример.
...
DG>Получается, что класс User-а уже может генерить ошибку, хотя изначально никаких ошибок не предполагалось

Вы привели самый что ни на есть "Стандартный пример" не правильного проектирования. Если есть вероятность того, что возвращаемые данные могут быть не валидными, то стандартный паттерн проектирования интерфейса такой:

TYPE
  Name = POINTER TO ARRAY OF CHAR;

  User = POINTER TO ABSTRACT RECORD 
    done-: BOOLEAN;
    (u: User) GetAge  (OUT age: INTEGER), NEW, ABSTRACT;
    (u: User) GetName (OUT name: Name),   NEW, ABSTRACT
  END;

Булевская переменная done доступная только для чтения (-) содержит в себе информацию о том удалось ли выполнить последнюю операцию.

VAR u: User;
    x: INTEGER; 
...
u.GetAge(x);
IF u.done THEN ... END;

Никакая ошибка нигде не генерится. Можно пойти дальше и, например, узнать почему последняя операция провалилась. Например, так:

TYPE
  User = POINTER TO ABSTRACT RECORD 
    done- : BOOLEAN;
    Error-: Error;
    ...

Error — полиморфная переменная типа список "абстрактных ошибок".

TYPE
  Error = POINTER TO ABSTRACT RECORD 
    ...информация об ошибке
    Next-: Error; предыдущая ошибка
  END;

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

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Что же Вы о создателях Оберон систем так плохо думаете? Разумеется будет остановлена работа только того модуля, который выполнил недопустимую операцию. Модуль будет динамически выгружен из системы. Когда другие модули запросят доступ к нему, он автоматически загрузится в память обратно. Так сказать — горячая перезагрузка — на лету. Вместо этого модуля, если угодно, может быть загружен модуль от другого производителя. Или, гипотетически, этот модуль будет "на лету" перекомпилирован заново, ошибка в нем исправлена, а его новый скомпилированный вариант динамически загружен в память. Что может быть устойчивее и надежнее? Вы бы, извините конечно, прежде чем глупые фантазии излагать вспомнили бы в каких областях Обероны используются: для случаев требующих особой безопасности — космос, электростанции, беспилотные летательные (военные) аппараты.

Вот оно откуда ноги растут — апологет Оберона объявился и готов (как миссионер ), обратить всех в истинную веру. Походу доказывая, что все ваши боги суть демоны и помощь их суть проклятие, а что его Бог никому не помогает, так ему и не положено . Кошмар

Напрашивается новый тред: Oberon vs All

http://deep.webest.net/forum/reply.php?num=0.0&amp;id=31178
http://deep.webest.net/forum/reply.php?num=0.0&amp;id=4541
http://deep.webest.net/forum/reply.php?num=0.0&amp;id=5129

На всякий случай скажу, что я не всегда разделяю мнение автора статей и переводчика

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

SYG>>Что значит упростить? Как Вы себе представляете работу динамической многомодульной системы? Как исключение передать из одного (бинарного) модуля внутрь другого (бинарного) модуля, а из того в третий и т.д. Вы себе можете представить? Все модули, разумеется, от разных производителей.

DG>И в чем именно проблема?

Проблема в ответе на вопрос: "Что значит упростить?"

DG>В .Net-е, Java-е, скриптах, Smalltalk-е и т.д. — это проблема же как-то решается.

Java — интерпретатор (там может быть все что угодно), Smalltalk — не модульный, а в .Net встроен JIT компилятор — это явно не "упрощение", а "утяжеление".

DG>Замечу, что подсчет ссылок и сборщик мусора — это две дополняющие друг друга стратегии.
DG>Подсчет ссылок лучше работает на малом кол-ве ссылок, сборщик мусора работает лучше на большом кол-ве ссылок.
DG>В идеальном случае — лучше использовать и то, и другое, т.к. у подсчета ссылок — есть существенный плюс: правильный (детерминированный) момент времени освобождения ресурсов.
DG>т.е. обобщенная стратегия, которая берут плюсы и минусы от обеих этих стратегий следующая:
DG>считаем ссылки, но если ссылок стало слишком много переходим на сборщик мусора, также периодически сборщик мусора проверяет объекты с подсчетом ссылок, ищет циклы, и убивает их

Это уже детали реализации. Просто все еще находятся некоторые люди наивно полагающие что задачу освобождения ресурсов (каждому new свой delete) можно решить в момент написания модуля программы. В общем случае эта задача статически неразрешима и для ее решения надо использовать динамические методы, причем одного лишь подсчета ссылок в общем случае будет недостаточно (например, два объекта ссылающихся друг на друга можно удалить только если есть полноценный сборщик мусора.)

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

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

AF>>>>для меня "серъёзный" код — это код со сложной архитектурой и множеством взаимосвязей и взаимозависимостей.

AR>>>А вот это бы я назвал именно сложным кодом.

AF>> Иногда да, иногда нет. В таких системах часто сам код очень простой, но именно наличие множества скрытых и не очевидных связей делает его написание делом не простым.

D> Может просто проблема проектирования? Код должен быть простым для понимания, тогда это хороший код. Смотря, конечно, для кого простым На асме писать очень просто, но при сложном алгоритме (да и просто по мере разбухания проекта, если его правильно не спроектировать) получается как раз такой "серьезный", по-твоему определению, код. На ЯВУ же этого запутывания имхо можно избежать.

Теоретически да. Практически, когда происходит упрощение кода, то (если код спроектирован и написан хорошо ) часто происходит добавление новых уровней абстракции и сущностей (что собственно и позволяет упростить код). Если чепловек с этими понятиями и моделями знаком — то для него код упрощается. Если же не знаком (что бывает гораздо чаще), то хотя каждая часть кода по отдельности возможно и стала проще — но код в целом может стать даже сложнее.
Простой пример. В своё время иногда писали на диск используя прерывания и аппаратуру контроллера. Код был довольно навороченным (прописывалась куча регистров и т.д.), но его суть очень проста. Если взять код, который пишет в файл под Windows — код будет гораздо яснее, очевиднее и проще. Но это только в том случае, если рассматирвать только клиентскую часть кода. А если рассматиривать и саму ОС — работу её кода, то всё стало намного сложнее и требует гораздо больше времени для понимания.
То же бывает и в других многоуровневых системах.

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

V>Я не вижу принципиальной разницы между исключениями и кодами возврата.

Исключения бывают двух сортов:
1) Псевдоисключения, которые вовсе никакие не исключения, а Ваши собственные доморощенные штуки, которые Вы используете как продвинутые коды возврата. Между ними и кодами возврата действительно нет никакой принципиальной разницы, а значит они в языке программирования в принципе излишни.

2) Истинные исключения, то есть те которые имеют свое происхождение от прерываний генерируемых процессором. Например, прерывание INT 0 — деление на ноль. По другому, "истинные исключения" можно назвать "недопустимые операции". Если программа совершает "недопустимую операцию", то она должна быть остановлена как не имеющая смысла.

Впрочем, если Вы не видите разницы, ну и не надо, мне не жалко. Если Вы полагаете что механизм исключений введен в язык только для удобства, а не потому что без этого механизма теоретически невозможно писать серьезные программы, то я согласен с Вами. Исключения — сами по себе излишни, можно обойтись и без них — вот моя точка зрения. Кажется наши точки зрения по этому пункту совпадают.


А вот по следующему пункту наши точки зрения противоположны:
V>Я лишь говорил, что ТЕОРЕТИЧЕСКИ можно обойтись без сборщика мусора

А Я лишь говорил, что в модульных системах без сборщика мусора обойтись ТЕОРЕТИЧЕСКИ нельзя.

И что дальше будем делать? Вы мне говорите "теоретически можно", а я Вам говорю "теоретически нельзя", и так до бесконечности будем, кто кого переговорит?

Предлагаю Вам решить такую задачу:
Вы являетесь автором одного динамически загружаемого модуля. Этот модуль создает объекты и отдает указатели на них другим динамически загружаемым модулям (другие модули написаны другими производителями, и у Вас есть/будут только их бинарники). На момент написания своего модуля Вы даже точно не знаете какие именно будут те самые другие модули. Как Вы будете принимать решение об уничтожении созданных в Вашем модуле объектов? Как Вы узнаете что созданный Вашим модулем объект больше никем не используется?

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

AF> А вы как думаете — какой код можно назвать "серъёзным" или "сложным"?

Не знаю какой код можно назвать "серьёзным", но вот "пальцастым" называется код, который пишут только настоящие пацаны

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


Поддерживаю.

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

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

AF>> А вы как думаете — какой код можно назвать "серъёзным" или "сложным"?

IT>Не знаю какой код можно назвать "серьёзным", но вот "пальцастым" называется код, который пишут только настоящие пацаны

А какой код пишут "настоящие пацаны"? Кстати на чём? С? С++? C#? Ещё что то более пацанское?

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

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


AF>> Подумав над данным вопросом сам, пришёл к выводу, что для меня "серъёзный" код — это код со сложной архитектурой и множеством взаимосвязей и взаимозависимостей.

D>Это хреновый код который не поддается пониманию и рефакторингу, такой код обычно выбрасывается на помойку после ухода программиста, писавшего его.

Это если код слишком сложен и содержит слишком много зависимостей, по сравнению с тем, что требуется для решения поставленной задачи. А если сама задача очень сложна? Экспертная система? Серврер БД? ERP система?

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

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

AF>> А вы как думаете — какой код можно назвать "серъёзным" или "сложным"?

Vi2>Наверное,

Vi2>серъёзный код — это код, за который дают серьезные деньги. Весь остальной код — несерьезен, за него дают или мало, или вообще ничего.
Гениально! Мне очень понравилось.

Vi2>сложный код — это код, который не может быть написан программистом ниже определенного уровня. Весь остальной код — несложен, его пишет или любой новичок, или никто не пишет.
Логично...

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

Там ведь было сказано:

"Конечно, все вышесказанное относится к большим промышленным проектам, где объем кода измеряется миллионами и десятками миллионов строк и над которым работает хотя бы человек 50. К софту класса "t.c" длиной в 100 строк это не относится -- это можно писать на любом языке программирования."

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

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


AF>> А какой код пишут "настоящие пацаны"? Кстати на чём? С? С++? C#? Ещё что то более пацанское?

_O_>ASM процессора Z80.

Yo! Man! А разве на нём ещё пишут?

_Obelisk_ -> "Re[3]: Серьёзный код " :

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


AF>> А какой код пишут "настоящие пацаны"? Кстати на чём? С? С++? C#?
AF>> Ещё что то более пацанское?

O> ASM процессора Z80.

Кстате — там было возможно писать резидентные проги

Yury Kopyl aka hrg | http://id.totem.ru | "Бей врага — друзья найдутся"(С)
Жванецкий

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

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

Vi2>>>серъёзный код — это код, за который дают серьезные деньги. Весь остальной код — несерьезен, за него дают или мало, или вообще ничего.
AF>> Гениально! Мне очень понравилось.

IT>Тогда получается, что российские программисты пишут не серьёзный код. Зато американские всегда серьёзный, даже индусы и китайцы

В общем то — отчасти — наверное да...

Но вообще то я больше иронизировал. Просто хочется что бы написание кода щедро финансировалось...

Я прекрасно понимаю, что одни в ящике за 3000р операционку реального времени ваяют, а другие, за $1200 кнопку на VB с грехом пополам прикручивают...

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

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

adb>Там ведь было сказано:

adb>"Конечно, все вышесказанное относится к большим промышленным проектам, где объем кода измеряется миллионами и десятками миллионов строк и над которым работает хотя бы человек 50. К софту класса "t.c" длиной в 100 строк это не относится -- это можно писать на любом языке программирования."

Полностью согласен. Но по-моему это вполне очевидно. Ну не может быть код в 1-2-3 строки серьёзным...
Но и в больших промышленных проектах — код то же быват разный...

AF> Полностью согласен. Но по-моему это вполне очевидно. Ну не может быть код в 1-2-3 строки серьёзным...
AF> Но и в больших промышленных проектах — код то же быват разный...

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

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

AF>> Полностью согласен. Но по-моему это вполне очевидно. Ну не может быть код в 1-2-3 строки серьёзным...
AF>> Но и в больших промышленных проектах — код то же быват разный...

adb>Если вы заметите, то упоминание "серъезного кода" было только в сабже. В тексте же речь шла только о "серъезных проектах".На лицо несоответствие сабжа с содержанием.

Согласен. Тогда какие проекты Вы считаете серъёзными, а какие — нет?

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

AF>> А вы как думаете — какой код можно назвать "серъёзным" или "сложным"?

AR>Серьезный код — код, важный по содержанию, требующий пристального внимания; ошибки в котором могут привести к опасным последствиям.
AR>С данной точки зрения даже простейший внешне код, являющийся частью системы управления атомным реактором или системой жизнеобеспечения в реанимации — серьезен (можно вспомнить Саттера с его 23 вариантами выполнения четырех строк внешне "несерьезного" кода).

Что же, на мой взгляд, очень разумно.

AF>>для меня "серъёзный" код — это код со сложной архитектурой и множеством взаимосвязей и взаимозависимостей.

AR>А вот это бы я назвал именно сложным кодом.

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

AF>> Наверняка у каждого из нас своя точка зрения по этому поводу.

AR>Я придерживался не только "точкой зрения", но и значением слов "серьезный" и "сложный" в литературном русском языке.

Есть ведь такое понятие как трактовка или сравнение... Для начинающего и Hello World — код сложный, для профи — код и в 5000 строк может быть очень простым. Потому то и интересно, кто и какими критериями пользуется...

AR>Но есть и еще одно определение:

AR>Серьезный код — код, который не вызывает приступов истерического смеха у серьезного программиста. (Желающие дать определение термину "серьезный программист" — welcome во флейм или юмор).

Ну насчёт "серьёзных программистов" это точно во флейм или юмор. Мы или умеем что то делать или нет.

AF>>>для меня "серъёзный" код — это код со сложной архитектурой и множеством взаимосвязей и взаимозависимостей.

AR>>А вот это бы я назвал именно сложным кодом.

AF> Иногда да, иногда нет. В таких системах часто сам код очень простой, но именно наличие множества скрытых и не очевидных связей делает его написание делом не простым.

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

AR>Интересно, как это код "с множеством связей... зависимостей... сложной архитектурой..." может быть простым?

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

Здравствуйте, DarkGray, Вы писали:
AR>>Интересно, как это код "с множеством связей... зависимостей... сложной архитектурой..." может быть простым?
DG>Простой в том смысле, что каждый отдельный модуль, класс пишется тривиально, но вот организация всего этого в единую систему требует серьезных усилий

Именно. Большая система из простых элементов "по определению" является сложной системой. И ее "организация" ни в коем случае не является тривиальной и/или простой задачей. Или это уже "мелочи"?

Назвать такой код простым — все равно что назвать простым любой код, ибо любой код состоит из "организованного множества" "простых" элементов языка и API.

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

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

AF>> Мы тут чудненько пофлеймили на тему "о применимости С++ в серьёзном коде" , но как то за кадром остался вопрос о том, что же такое "серьёзный код". Были правда некоторые попытки определить это понятие, но они быстро иссякли.
AF>> А вы как думаете — какой код можно назвать "серъёзным" или "сложным"? Как Вы вообще — разделяете ли код по каким-либо критериям и на какие то категории? И если да, то по каким?

P>Судя по теме "о применимости С++ в серьёзном коде" единственный серьёзный код — это машинный код, набранный переключателями на панели управления.
P>Никаких толстенных стандартов на язык программирования, так как описание команд процессора умещается в тонкой книжке.
P>BTW, интеловский процессор не может исполнять серьёзный код, т.к. описание самого процессора занимает 3 тома.
P>

То есть мы естественным образом приходим к распространённому среди микроэлектронщиков мнению, что интеловские процессоры — "не серьёзные", лоховские, а вот Альфа...

P>Если серьёзно (сорри за каламбур), то серьёзный код — это миф, призванный удовлетворить самомнение пишушего его программиста.
P>Программа — это способ решить те или иные задачи. Если она написана в соответствии с требованиями, с заданным качеством и в срок, то IMHO без разницы, на каком языке написан код и как он выглядит (даже если это будет write-only код).

Если "серъёзный" код это способ самоутверждения, то это код, который пишут "серьёзные" программисты.
Тем не менее бывает код очевидный, простой, который легко менять и это обходится без последствий, а есть такой код, который может и выглядит даже проще, но его изменение потруднее разгадывания кросворда....

P>А _сложным_ может быть алгоритм, но не реализующий его код.

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

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

AF>> Подумав над данным вопросом сам, пришёл к выводу, что для меня "серъёзный" код — это код со сложной архитектурой и множеством взаимосвязей и взаимозависимостей. Какой нибудь навороченый алгоритм, с кучей условий (какая нибудь сложная сортировка или шифрование) — код сложный (алгоритмически), но тем не менее к серьёзному я его не отношу. По тем же причинам к серъёзному коду не отношу большинство модулей ОС, так как на мой взгляд — это код специфический — который должен быть написан крайне аккуратно и хорошо продуман, но чего-либо принципиально сложного в нем нет.

A>типа вот . Супер простой код без взаимосвязей. Ну уж очень большой .

A>http://kernelmapper.osdn.com/map.php

Если ты ещё и сам это написал — то ты просто ДЖЕДАЙ! Однозначно...
А если серъёзно — выглядит пугающе, но интересно — дело тут в коде или в его представлении? Можно умеючи такие диаграммы для простейшего кода начертить, что страшно станет...

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


A>>http://kernelmapper.osdn.com/map.php

AF> Если ты ещё и сам это написал — то ты просто ДЖЕДАЙ! Однозначно...

да не . Это линукс кернель... причем довольно древний... 2.2 кажется... мне просто показалось что это будет в тему .

AF> А если серъёзно — выглядит пугающе, но интересно — дело тут в коде или в его представлении? Можно умеючи такие диаграммы для простейшего кода начертить, что страшно станет...

Скорее всего в прдеставлении... но и в коде тоже. Линукс (особенно ранние версии) написан "как курица лапой". Правда щас его причесывают помаленьку.

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

AR>(можно вспомнить Саттера с его 23 вариантами выполнения четырех строк внешне "несерьезного" кода).

Кого вспомнить?
Можно линк?

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

_O_>Здравствуйте, AndreyFedotov, Вы писали:
AF>> А какой код пишут "настоящие пацаны"? Кстати на чём? С? С++? C#? Ещё что то более пацанское?
_O_>ASM процессора Z80.
О! настальгия... между прочим асм там был ничего. даже недокументированные команды были! И какие!
а вообще серьезный код — это который взаимодействует с большим количеством сторонних компонент и библиотек. чер серьезней компоненты/библиотеки — тем серьезней код который с ними взаимодействует

Здравствуйте, VladD2, Вы писали:
VD>Вчера наблюдал результат творчества программистов Адобы (ИндизайнЦС). Я бы этих уродов выгнал бы на улицу. Не, лучше отправить в китай или индию. Большего они не стоят.
А еще при отладке плагинов под Адобы заметно, что там есть собранный в дебаге код

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

AF> Подумав над данным вопросом сам, пришёл к выводу, что для меня "серъёзный" код — это код со сложной архитектурой и множеством взаимосвязей и взаимозависимостей. Какой нибудь навороченый алгоритм, с кучей условий (какая нибудь сложная сортировка или шифрование) — код сложный (алгоритмически), но тем не менее к серьёзному я его не отношу. По тем же причинам к серъёзному коду не отношу большинство модулей ОС, так как на мой взгляд — это код специфический — который должен быть написан крайне аккуратно и хорошо продуман, но чего-либо принципиально сложного в нем нет.
AF> Наверняка у каждого из нас своя точка зрения по этому поводу. Предлагаю поделиться...

ты сам ответил на свой вопрос (выделено жирным). я бы только эти два утверждения местами поменял, т.к. нужно сначала (про)думать, а потом делать.

Здравствуйте, S.Yu.Gubanov, Вы писали:

[skiped]

Согласен. Вот именно так и следует оценивать код с точки зрения серьёзности. Предидущий оратор говорил о серьёзной задаче, а не о коде .

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

AR>Серьезный код — код, который не вызывает приступов истерического смеха у серьезного программиста. (Желающие дать определение термину "серьезный программист" — welcome во флейм или юмор).

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

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

AF>>>для меня "серъёзный" код — это код со сложной архитектурой и множеством взаимосвязей и взаимозависимостей.

AR>>А вот это бы я назвал именно сложным кодом.

AF> Иногда да, иногда нет. В таких системах часто сам код очень простой, но именно наличие множества скрытых и не очевидных связей делает его написание делом не простым.

Может просто проблема проектирования? Код должен быть простым для понимания, тогда это хороший код. Смотря, конечно, для кого простым На асме писать очень просто, но при сложном алгоритме (да и просто по мере разбухания проекта, если его правильно не спроектировать) получается как раз такой "серьезный", по-твоему определению, код. На ЯВУ же этого запутывания имхо можно избежать.

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

S>В данном серьезном коде допущена серьезная ошибка. Создание объекта TIniFile должно быть вынесено из блока try..finally

Да что Вы такое говорите! Да неужели? Правда что ли??? А если подумать?

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

Код:

f := NIL;
TRY
  f := TMyObject.Create(SomeObj.GetParameters());
  f.DoSmth();
FINALLY
  f.Free();
END;

остается безопасным в обоих случаях:
1) Объект еще не успел создаться, т.е. f = NIL (это из-за того что Free перед вызовом деструктора проверяет Self на равенство NIL),
2) Объект уже успел создаться — в FINALLY уничтожаем его

Здравствуйте, S.Yu.Gubanov, Вы писали:

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

Тогда объект TMyObject не создастся и освобождать объект методом Free() не требуется. Произойдет обычное прерывание из-за произошедшего исключения.

SYG>1) Объект еще не успел создаться, т.е. f = NIL (это из-за того что Free перед вызовом деструктора проверяет Self на равенство NIL),
SYG>2) Объект уже успел создаться — в FINALLY уничтожаем его

Общий принцип работы с исключениями:

obj := TMyObject.Create();  
  //создаем объект, если в процессе создания произошло исключение (объект не создастся), то 
  //просто вывалимся до ближайшей обработки исключения верхнего уровня. 
try
  //что-то делаем с объектом obj, что может вызвать иcключение
finally
  obj.free;
  //освобождаем объект и опять же вываливаемся до ближайшей обработки исключения верхнего уровня
end

Конечно, Ваш вариант абсолютно работоспособен и я поспешил утверждать что он содержит серьезную ошибку, т.к. как Вы уже написали выше "Free перед вызовом деструктора проверяет Self на равенство NIL".

Хотя...

Пришла мысль. Вот код, в котором Вас стиль использования исключений будет неправильным, и даже приведет к серьезной ошибке, которую не так очевидно будет обнаружить:

TMyClass=class(TObject)
public
    constructor Create(OpenFileName: string);
end;

procedure OpenManyFiles(ListFiles: TList);
var 
  obj: TMyClass;
begin

try
  obj:=TMyClass.Create('FirstFileName');
  ListFiles.Add(obj);
finally
  obj.Free;
end;

try
  obj:=TMyClass.Create('SecondFileName');
  ListFiles.Add(obj);
finally
  obj.Free;
end;

end;

Процедура OpenManyFiles открывает несколько файлов и сохранят объекты их обслуживающие в списке файлов ListFiles.
Возьмем случай, когда открытие первого файла прошло успешно, а второго 'SecondFileName' нет.
Тогда obj до вызова конструктора
obj:=TMyClass.Create('SecondFileName');
будет содержать ссылку на первый файл. Когда произойдет исключение, то в блоке finally вызовется метод Free для obj первого файла!, ссылка на который уже давно лежит в списке ListFiles и в последствии будет использоваться другим кодом. Т.е. новая ошибка затаится до момента, когда кто-то захочет пробежаться по элементам списка ListFiles. А наступить это может через большой промежуток времени, в абсолютно далеком месте программы и найти концы будет очень сложно.

Конечно можно избежать данной ситуации, если между открытиями первого и второго файла дописать obj:=nil, но это можно забыть сделать.

В случае же если создание объекта вынесено из блока try..finally (всегда считал это классическим способом), описанной выше проблемы просто не произойдет. И такой способ является абсолютно безопасным.

Согласен.

Здравствуйте, S.Yu.Gubanov, Вы писали:

Кстати классный пример того почему С++ рулит...

Taaa a;
Tbbb b;
Tccc c;
...

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

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

AF>> Мы тут чудненько пофлеймили на тему "о применимости С++ в серьёзном коде" , но как то за кадром остался вопрос о том, что же такое "серьёзный код". Были правда некоторые попытки определить это понятие, но они быстро иссякли.
AF>> А вы как думаете — какой код можно назвать "серъёзным" или "сложным"? Как Вы вообще — разделяете ли код по каким-либо критериям и на какие то категории? И если да, то по каким?
AF>> Наверняка у каждого из нас своя точка зрения по этому поводу. Предлагаю поделиться...
LVV>Серьезный код — это код, который делается не дял себя. Например, диплом. Это уже серьезно, так как диплом надо защищать и демонстрировать работоспособность системы. Если вы мне скажете, что диплом никто не читает, так вы ошибетесь — я читаю.
LVV>В общем, серьезный код — это код, оттогаемый от разработчика и используемый другими людьми.

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

ЗЫ: Исключения бывают конечно, но это именно исключения, а не правила.

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

D>Серьезность кода и диплом не имееют ничего общего, по крайней мере везде где я знаю так оно и есть. Я знаю такие дипломные работы, котрые даже на лабораторную для 1-ого курса не потянут. А код которых и глядеть страшно.

D>ЗЫ: Исключения бывают конечно, но это именно исключения, а не правила.
Ну так у нас сплошные исключения

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

AF>>> Подумав над данным вопросом сам, пришёл к выводу, что для меня "серъёзный" код — это код со сложной архитектурой и множеством взаимосвязей и взаимозависимостей.

D>>Это хреновый код который не поддается пониманию и рефакторингу, такой код обычно выбрасывается на помойку после ухода программиста, писавшего его.

AF> Это если код слишком сложен и содержит слишком много зависимостей, по сравнению с тем, что требуется для решения поставленной задачи. А если сама задача очень сложна? Экспертная система? Серврер БД? ERP система?

Тогда на помойку выбрасывается фирма, после ухода этого программиста.

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

C>Как раз наоборот — программист выше определенного (и достаточно высокого) уровня будет писать максимально простой код

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

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Можно поконкретнее? Что конкретно обозначают слова "забыли" и "помнит это за меня"? А то просто нету предмета для обсуждения.
Пример на C#

        static void Main(string[] args)
        {
            FileStream file=File.Create("some.file");

            file.Close();
        }

если забыть сделать file.Close() то фаил не будет закрыт до сборки мусора.
В С++

    std::fstream file("some.file");
    file.close();

file.close() делать не обязательно ибо фиал будет закрыт в деструкторе fstream при выходе переменной file из области видимости.

SYG>1) Уж точно даже не пытаться работать с неверными данными.
Это точно.
SYG>2) Как можно скорее сообщить об этом пользователю, если это возможно.
А как сообщить об этом пользователю? Допустим у меня есть некий очень сложный код который не знает в каком окружении он работает, а даже если бы и знал то пристовать к бользователю в обход того кода который взаимодействует с пользователем это бардак.
Дык вот вернуть ошибку из глубины этого кода без исключений довольно проблематично.

SYG>Я сам на работе на нем не пишу, но слышал, что есть такие конторы где пишут на оберонах (в основном для космоса, для беспилотных летательных аппаратов, электростанций и
Ты с Адой не путаешь? Даже если нет то по масштабу использования он в месте с Адой и рядом не стоял с С++.
Те за 10 лет ему удалось занять ничтожную часть производства ПО от сюда вывод...

SYG>Во-первых, если Вам обязательно надо что-то возвращать, то ни кто не заставляет Вас возвращать именно номер_кода_ошибки.
В любом случае этот код в силе
Re[10]: Пример не серьезного и аналогичного ему серьезного к

Автор: WolfHound
Дата: 15.07.04

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

SYG>1) Никогда нельзя знать "повис" указатель или нет.
Поверь мне они у меня и без ГЦ никогда не появится ибо:
Предохраняйтесь смартпоинтерами и ваши указатели не будут висячими.

SYG>2) Надо всего лишь запретить "насильное" приведение типов.
Не надо. Иногда без него ни куда. Но такие штуки у нормальных людей спрятаны в библиотеку за дуракоустойчивым интерфейсом.
SYG>Точно так же как в свое время запретили инструкцию goto.
Генерить парсер на конечном автомате без goto мягко говоря проблематично...
SYG>Проблема решена.
Как всегда одни проблемы решены, а другие добавлены...
Причем опять же как всегда решены мифические, а добавлены вполне реальные.

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

AF> Мы тут чудненько пофлеймили на тему "о применимости С++ в серьёзном коде" , но как то за кадром остался вопрос о том, что же такое "серьёзный код". Были правда некоторые попытки определить это понятие, но они быстро иссякли.
AF> А вы как думаете — какой код можно назвать "серъёзным" или "сложным"? Как Вы вообще — разделяете ли код по каким-либо критериям и на какие то категории? И если да, то по каким?
AF> Некоторые уже упоминались. Например "лохокод"
AF> Подумав над данным вопросом сам, пришёл к выводу, что для меня "серъёзный" код — это код со сложной архитектурой и множеством взаимосвязей и взаимозависимостей. Какой нибудь навороченый алгоритм, с кучей условий (какая нибудь сложная сортировка или шифрование) — код сложный (алгоритмически), но тем не менее к серьёзному я его не отношу. По тем же причинам к серъёзному коду не отношу большинство модулей ОС, так как на мой взгляд — это код специфический — который должен быть написан крайне аккуратно и хорошо продуман, но чего-либо принципиально сложного в нем нет.
AF> Наверняка у каждого из нас своя точка зрения по этому поводу. Предлагаю поделиться...

Мне кажеться, что "серъёзный" является синонимом "хорошего". Хороший код это адекватный код, в котором нет излишних наворотов и искуственнного усложнения. Обычно, такой код хорошо структуирован и полностью соответсвует принципу DRY(don't repeat yourself).

SYG>А теперь маленькое философское отступление. Те, кто писал действительно серьезный код знают, что исключений, возбуждаемых при ошибках программиста (напр. std::logic_error, который определяется стандартом как: для извещения об ошибках, которые, предположительно, могут быть обнаружены до выполнения программы) быть не должно. Самое лучшее, что мы можем сделать при обнаружении подобного рода ошибки -- это сразу же прервать выполнение программы, сгенерировав информацию, необходимую для определения сути происшедшего (напр. core dump). Дело в том, что "ошибка здесь" является, как правило, следствием "ошибки там" и продолжение исполнения некорректного кода в надежде на лучшее приведет к Ужасным Последствиям (напр. сумма, эквивалентная нескольким десяткам лет зарплаты программиста, будет зачислена на неизвестный счет где-нибудь в Буркина-Фасо. Но это, конечно, маловероятно, т.к. чаще всего обнаруженное несоответствие двойной бухгалтерии приводит к временной остановке всех операций до выяснения причин; а убыток от нескольких часов простоя серьезного банка приводит к гораздо более дорогостоящим последствиям...).


Рассмотрим, например, программу управляющую аэропортом. В том числе эта программа рассчитывает насколько времени у самолета хватит топлива.

А теперь допустим, что на посадку вдруг решил зайти планер, у которого соответственно расход горючего ноль, программа попыталась рассчитать на сколько времени такому "самолету" хватит горючего, но произошла ошибка — деление ноль.

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

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

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

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

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

E>Кстати, а хотя бы core dump твой ComponentPascal делать умеет?

Во-первых, Component Pascal — это язык и сам по себе он ничего делать не умеет. На нем писать самому надо. Во-вторых, скачайте из интернета доки и узнайте. Я почему-то о С++ подобных вопросов не задаю, типа "А ваш С++, ваще, хотя бы умеет делать то-то или то-то?"

E>4. Напоминаю, что есть такая технология, называется "plug in".
E>Я так понимаю, ты предлагаешь разработчику основного приложения смириться с тем, что оно может быть в любой момент закрыто, если в одном из плагинов (даже не им написанных) произошла ошибка?
E>Как по мне, так лучше просто отключить проблемный плагин.

Уже ответил:
http://www.rsdn.ru/Forum/Message.aspx?mid=725690&amp;only=1

Автор: S.Yu.Gubanov
Дата: 19.07.04

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Ну это быстренько можно "подпортить", и "рульность" С++ поубавится
SYG>1) Пусть a,b,c — это очень большие объекты, так что на стеке втроем им места не хватит...
SYG>2) Пусть a,b,c — это не объекты, а полиморфные переменные. В терминологии С++ статический тип a,b,c — пусть будет указатели на объекты "абстрактных классов". Так как в стандартном С++ есть только блок try catch, а FINALLY — нету, то жизнь сразу усложняется. Придется использовать классы обертки — "умные указатели", а это уже из другой оперы.
Ответ на оба вопроса — Master Pointers ("ведушие указатели", Джеф Элджер, например). Нет никакой "другой оперы".

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Во-первых, Component Pascal — это язык и сам по себе он ничего делать не умеет. На нем писать самому надо. Во-вторых, скачайте из интернета доки и узнайте.
Запустил сейчас на RSDN поиск строки "Compоnent Pascal" — 13 ccылок. Из них наверное половина твоих.
Пожалуй я, с твое разрешения, прощу себе, что до сегодняшнего дня про него кроме названия ничего не слышал
Что же касается твоего предложения "скачать доки", то я от этого на данный момент воздержусь — пока что твои рекламные сообщение не убеждают, что оно будет стоит потраченного времени. А судя по твоей реакции на мои попытки узнать о CP что-нибудь вразумительное, врял ли когда-нибудь это положение изменится

SYG> Я почему-то о С++ подобных вопросов не задаю, типа "А ваш С++, ваще, хотя бы умеет делать то-то или то-то?"
А ты задай — ответят
(кстити, набери в поиске RSDN "С++" и посчитай сколько ссылок будет там)

SYG>Уже ответил:
SYG>http://www.rsdn.ru/Forum/Message.aspx?mid=725690&amp;only=1

Автор: S.Yu.Gubanov
Дата: 19.07.04

только на последний пункт, да и то неубедительно (почему — выскажусь в той ветке).

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

DG>Я думаю плохо не об Обероне, а о Вашей позиции "в случае ошибки необходимо останавливать всю программу".

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

DG>Но непонятно, что в этом случае будет с модулями, которые использовали/вызывали данные модули? Они тоже будут выгружены? Или они получать сообщение об ошибке? Другими словами получат исключение?
DG>Что будет с ресурсами, модулями и т.д., которые использовал выгружаемый модуль?
DG>Что будет с ходом выполнения программы? Выполнение остановится? продолжится с какого-то места? еще что-то?

Точно не отвечу. Система BlackBox (эмулятор ОС Оберон под Виндос), кажется, переходит к выполнению следующей итерации своего главного цикла. Если есть исходный код модуля, то выскакиевает диалоговое окно со списком стека вызовов последних нескольких процедур со всеми значениями локальных переменных. Каждый элемент этого списка является гиперссылкой на соответсвующую позицию в исходном коде программы. С ресурсами ничего страшного не происходит — всем управляет единый сборщик мусора. Как конкретно обстоят дела в нативной ОС Оберон и ее многочисленных клонах я не знаю. Кроме того, есть еще парралельные системы, например, Blue Bottle на Active Oberon — там парралельность интегрирована в сам язык. Как там все внутрях устроено я еще тоже не знаю.

SYG>>Ну как, можно считать вопрос на этом исчерпанным?
DG>пока есть только лозунг "оберон — это круто, а, ну, все быстро пользуйтесь обероном", но нет ни одного конкретного описания или примера, как в обероне решаются затронутые в данной теме проблемы.

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

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Что же Вы о создателях Оберон систем так плохо думаете? Разумеется будет остановлена работа только того модуля, который выполнил недопустимую операцию. Модуль будет динамически выгружен из системы. Когда другие модули запросят доступ к нему, он автоматически загрузится в память обратно. Так сказать — горячая перезагрузка — на лету. Вместо этого модуля, если угодно, может быть загружен модуль от другого производителя. Или, гипотетически, этот модуль будет "на лету" перекомпилирован заново, ошибка в нем исправлена, а его новый скомпилированный вариант динамически загружен в память. Что может быть устойчивее и надежнее? Вы бы, извините конечно, прежде чем глупые фантазии излагать вспомнили бы в каких областях Обероны используются: для случаев требующих особой безопасности — космос, электростанции, беспилотные летательные (военные) аппараты.
А почему нужно выгружать именно модуль (в том значении этого слова, в котором ты его понимаешь)? Почему не группу модулей? Или наоборот — один только класс из "модуля"? Или Метод? Или, даже, секцию кода внутри метода (расположенную в блоке try)?
И (DarkGray про это уже рядом сказал), как мне описать процедуру выгрузки (в смысле разрешения конфликтов с другими модулями), чтобы указать что вот этот вот модуль нужно перечитать, а вот эти не трогать, а вместо этого, в случае чего, можно взять вон тот и т.п.? Для этого нужно какой-то параллельный код держать (в котором, кстати, в свою очередь, тоже возможны ошибки) и постоянно следить за его релевантностью.

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

Здравствуйте, S.Yu.Gubanov, Вы писали:


SYG>Мне что теперь, каждую свою фразу окружать сонмищем оговорок, в которых описывать все варианты ее истинности и толкования? Разумеется мы делим на переменную, и чтобы не совершить недопустимую операцию нам надо сначала проверять ее на неравенство нулю. А перед тем как создавать файл надо разумеется проверить его имя на допустимость. Но разница между этими двумя случаями состоит в том, даже не знаю как и объяснить-то, компьютер так что ли устроен, что делить на ноль он не может ну никак, а вот файл с недопустимым именем создает не компьютер, а программа, и она увидев недопустимое имя, просто не будет создавать такой файл и все, ничего страшного и исключительного не произойдет. Я не знаю как еще объяснить. Мне для этого компьютерной грамотности не хватает.

С вашим подходом код будет примерно следующий:

Нам надо открыть файл, это вовлекает вызов цепочки функций.

bool OpenFile(...) {.. }

bool Fn(...)
{
    if(!OpenFile(...)) return false;
}
..
bool Fk(...) 
{  
    if(!Fk+1(...)) return false;  // Fk+1 - имя функции
}

bool F1(..)
{
    if(!F2(...)) return false;
}

Тем самым нам КАЖДЫЙ вызов надо облекать в условие с проверкой результата. С исключениями гораздо проще.

Вышеприведенный подход использовал один товарищ у нас в проекте. В конце-концов товарища уволили а его код был полностью переписан.

Здравствуйте, S.Yu.Gubanov, Вы писали:


SYG>Вот уж кто в таких случаях на самом деле по взрослому рулит, так это (компилируемый) язык со сборщиком мусора и без "исключительных ситуаций", например, Component Pascal (http://www.inr.ac.ru/~info21/cpascal/cp_report_1.4_rus.htm)


Какие серьезные продукты созданы на базе этого языка ?

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

Дык, процессор — это такая же программа, но только выполненная в железе. Она также может увидеть недопустимый делитель, и ничего не делать.
Вот только непонятно, что это такое "ничего не делать" и в том, и вдругом случае?
т.е. что все-таки должен сделать код, который вдруг увидел недопустимое имя файла?


SYG>Попробую собрать в одном месте все что я говорил о модулях.

SYG>Модуль — это:
SYG>во-первых, абстракция языка программирования являющаяся единицей инкапсуляции и компиляции (весь исходный код программы находится в модулях)
SYG>во-вторых, являющаяся единицей исполнения. Во время выполнения программы модули динамически загружаются/выгружаются (позднее связывание).
SYG>в-третьих, на саму систему (в которой эти модули работают) налагается ограничение — обязательно должен быть единый сборщик мусора (это для того чтобы модули могли безбоязненно создавать внутри себя объекты и передавать их другим модулям, а те третьим и т.д.).

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

Под такое определение подходят, например, Java, .Net, SmallTalk, почти все скриптовые языки, системы построеные на основе COM/DCOM и т.д.

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

_O_>Здравствуйте, S.Yu.Gubanov, Вы писали:


SYG>>Вот уж кто в таких случаях на самом деле по взрослому рулит, так это (компилируемый) язык со сборщиком мусора и без "исключительных ситуаций", например, Component Pascal (http://www.inr.ac.ru/~info21/cpascal/cp_report_1.4_rus.htm)


_O_>Какие серьезные продукты созданы на базе этого языка ?

Недавно была конференция где об этом все друг другу хвастались
http://cern.ch/oberon.day

Там в разделе Presentations среди прочих презентаций есть презентация

C. Pfister (Oberon microsystems)
BlackBox: An Industrial-Strength Oberon Implementation

там хвастаются как они для электростанции написали ПО.

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

DG>Но здесь опять же возникает вопрос, а как система узнает о том, что произошла ошибка? Получает некий сигнал? Чем этот сигнал отличается от исключения из "стандартных" языков программирования?

Может и ни чем.
Просто программисту запрещено возбуждать свои собственные псевдоисключительные ситуации.

SYG>Отсечка неправильных данных должна произойти на входе данных в систему. То есть, пользователь ввел неправильные данные, а они раз, и не ввелись, а выскочило диалоговое окно — "Введенные данные не правильные." Внутри системы неправильных данных быть не должно.

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

Допустим, у нас есть int-овая переменная x. Допустимо ли в ней хранить значение 0, или отрицательные значения?
По идее, допустимо. Допустимо ли где-то в отдельном модуле делить на эту переменную? По идее, тоже допустимо.

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

int x = Input();
if (внешнее условие)
  x = 1/x;

Внимание, вопрос: допустимо ли хранить в переменной x значение равное нулю? И что делать, если в x был 0, и мы дошли до операции деления на ноль?

SYG>Точно не отвечу. Система BlackBox (эмулятор ОС Оберон под Виндос), кажется, переходит к выполнению следующей итерации своего главного цикла. Если есть исходный код модуля, то выскакиевает диалоговое окно со списком стека вызовов последних нескольких процедур со всеми значениями локальных переменных.

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

SYG>Отсечка неправильных данных должна произойти на входе данных в систему. То есть, пользователь ввел неправильные данные, а они раз, и не ввелись, а выскочило диалоговое окно — "Введенные данные не правильные." Внутри системы неправильных данных быть не должно.

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

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

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

т.е. оберон предназначен только для тех ситуаций, в которых мы заранее можем предусмотреть все варианты. Но такие задачи — или очень малы по объему, или требуют колосальных материальных затрат, т.к. необходимо на этапе разработке рассматривать все, даже исключительные варианты. Причем опыт показывает, что даже в этих случаях, обеспечить стопроцентный разбор вариантов не представляется возможным, и все равно получаются ситуации, которые не были предусмотрены разработчиком.

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


SYG>>Точно не отвечу. Система BlackBox (эмулятор ОС Оберон под Виндос), кажется, переходит к выполнению следующей итерации своего главного цикла. Если есть исходный код модуля, то выскакиевает диалоговое окно со списком стека вызовов последних нескольких процедур со всеми значениями локальных переменных.

DG>Что будет происходить, если система работает в автономной режиме? Когда никакого внешнего пользователя нет?
DG>Система будет тупо ждать, когда кто-нибудь придет и закроет диалоговое окно?

Если система автономная, то в ней, обычно, нет исходников — только бинарники. Кроме того в ней, обычно, нет подсистемы компилятора.

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

DG>Внимание, вопрос: допустимо ли хранить в переменной x значение равное нулю? И что делать, если в x был 0, и мы дошли до операции деления на ноль?

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

Конкретный пример:

Vx := x1 - x0;
Vy := y1 - y0;
V  := Math.Sqrt(Vx*Vx + Vy*Vy);
IF V > 0 THEN 
  Vx := Vx/V;
  Vy := Vy/V;
END;