E>В качестве примера -- катастрофа Ариан 5 при старте, тогда из-за ошибок программистов не было перехвачено исключение и софт просто вырубился, как на основной, так и на резервной системе контроля. И что толку, что софт был написан на Ada, а не на C++? Поэтому то, что Oberon/Java/C# сгенерирует out of bound exception в run-time, имхо, ничем не поможет программе, в которой это исключение совершенно не ожидалось. А ведь в подавляющем большинстве случаев оно не ожидается

История постоянно подтверждает правоту Н.Вирта. Например, взрыв в 1996 г. ракеты-носителя Ариан-5 стоимостью около 500 миллионов долларов через 40 секунд после старта произошел, как выяснилось, из-за сбоя программного обеспечения: одна из вспомогательных подпрограмм пыталась преобразовать длинное целое значение в короткое без проверки величины значения. Компиляторы Оберона по умолчанию отказываются компилировать такие программы, считая их ошибочными, тем самым "тыкая носом" проектировщика в точки потенциальных сбоев.

It has been stated to the Board that not all the conversions
were protected because a maximum workload target of 80% had been set
for the SRI computer.

AVC>>>Говорят, что если петуху отрубить голову, он еще может носиться по двору. Вот C++ и носится... А потом бряк — и уже вверх ногами!

Я думаю, что C++ is dead.

Говорят, что если петуху отрубить голову, он еще может носиться по двору. Вот C++ и носится... А потом бряк — и уже вверх ногами!

AVC>в каких-то диких странах.

As ever, it is hard to estimate the number of C++ programmers, but in 2003, the IDC reported well over three million full-time C++ programmers (compared to my estimate of 400,000 in 1991; §D&E7.1), and that’s not an implausible number. I’m not in a position to accurately count, but all the indicators I have, show a steady increase in the use of C++ over the last decade (1995-2004) after the explosive growth of C++’s first decade (1985-1994). I never experienced a year without growth.

So what do all of those C++ programmers actually do? What kind of applications do they write and what kind of programming styles do they employ? I don’t know; nobody knows. In the same way as there are too many C++ programmers to count, there are too many different application areas and too many programming styles for any one person to grasp. It is common to hear generalizations along the line “C++ is used like this”. Such statements are typically wishful thinking based on very limited experience. We are playing “blind men and the elephant” with a very large creature. There are people who have read more than a million lines of C++ code, written hundred of thousands of lines of C++, read all the articles in C-vu, C/C++ Users Journal, etc., read all the good C++ books and dozens of the bad ones, read all the academic papers relating to C++, and “lived” on the C++ newsgroups for years. There are not many such people, and even they have only scratched the surface. Such people are usually the last to utter simple generalizations. In fact, I hear the most succinct and confident generalizations (both positive and negative) about C++ from people who have hardly any experience with C++. Ignorance is bliss.

AVC>Кажется, Вы полагаете, что вычисления — это только "численные методы"?

AVC>>>>Говорят, что если петуху отрубить голову, он еще может носиться по двору. Вот C++ и носится... А потом бряк — и уже вверх ногами!

E>Здесь хочется придраться к словам

ИМХО, если петуху отрубить голову, он еще может, ИМХО, носиться по двору. Вот, ИМХО, C++ и носится... А потом, ИМХО, бряк — и уже вверх ногами!

AVC>>Кажется, Вы полагаете, что вычисления — это только "численные методы"?

AVC>

AVC>Уф!

a[i][j] = b[j][i];

a[ get_i(i, j) ][ get_j(i, j) ] = b[ get_i(j, i) ][ get_j(j, i) ];

a[i][j]

a[ get_i(i, j) ][ get_j(i, j) ]

AVC>Из отчета, ссылку на который дал Cyberax (за что ему отдельное спасибо, хотя не помню, чтобы мы хоть раз совпали во мнениях ), очевидно, что первопричина — в недостаточности вычислительных ресурсов. Соответствующую цитату из отчета я уже приводил.

AVC>>Уф!

E>Если перейти на личности, то я представляю себе, с каким отношением к C++ эти программисты затем уходят от тебя

E>a[i][j] = b[j][i];
E>

E>a[ get_i(i, j) ][ get_j(i, j) ] = b[ get_i(j, i) ][ get_j(j, i) ];
E>

E>a[i][j]
E>

E>a[ get_i(i, j) ][ get_j(i, j) ]
E>

AVC>>Из отчета, ссылку на который дал Cyberax (за что ему отдельное спасибо, хотя не помню, чтобы мы хоть раз совпали во мнениях ), очевидно, что первопричина — в недостаточности вычислительных ресурсов. Соответствующую цитату из отчета я уже приводил.

PROCEDURE GlobalProc(v: INTEGER);
  CONST size = 1024;
  VAR a: ARRAY size OF INTEGER;
  PROCEDURE LocalSearch(x: INTEGER): INTEGER;
    VAR i: INTEGER; (* здесь могут быть объявлены и другие вспомогательные переменные *)
  BEGIN
    FOR i := 0 TO size-1 DO
      IF a[i] = x THEN RETURN i END
    END;
    RETURN -1
  END LocalSearch;
BEGIN
  (* ... море кода, где переменная i не нужна *)
  IF Local(v) >= 0 THEN (* ура, значение найдено! :)  *)
  ELSE (* увы, не найдено... :(  *)
  END;
  (* ... еще море кода, где переменная i не нужна *)
END GlobalProc;

for (int i = 0; i < size; i++) ;

AVC>>(голосом кота Матроскина) Я еще и СУБД писал...

a[j][i]

AVC>>И за границы массива никогда не выходили?!

AVC>>Я бы на Вашем месте не был настроен столь философски.

AVC>>Я, наверное, эту Вашу фразу на стенку повешу.

E>Буду рад. Только авторство укажи

list<elem_type>::iterator i = find_if(l.begin(), l.end(), cond(v));
if (i != l.end()) { ... }

AVC>>>(голосом кота Матроскина) Я еще и СУБД писал...

AVC>a[j][i]
AVC>

AVC>?

get_i( a, i, j )

AVC>>>Я, наверное, эту Вашу фразу на стенку повешу.

E>>Буду рад. Только авторство укажи

AVC>Обязательно!

AVC>list<elem_type>::iterator i = find_if(l.begin(), l.end(), cond(v));
AVC>if (i != l.end()) { ... }
AVC>

int a[ 20 ];
int * pos = find_if( a, a + sizeof(a)/sizeof(a[0]), v );
if( pos != a + sizeof(a)/sizeof(a[0]) ) { ... }

AVC>А как насчет eao? Ну, наверное, — ничего похожего...

E>Алексей, может на "ты" перейдем? А то мне как-то неудобно, я здесь в форуме ко всем на "ты", а мне в ответах "вы", да еще с большой буквы.

AVC>>list<elem_type>::iterator i = find_if(l.begin(), l.end(), cond(v));
AVC>>if (i != l.end()) { ... }
AVC>>

E>int a[ 20 ];
E>int * pos = find_if( a, a + sizeof(a)/sizeof(a[0]), v );
E>if( pos != a + sizeof(a)/sizeof(a[0]) ) { ... }
E>

for (int i = 0; i < sizeof a / sizeof a[0]; ++i)
    if (v == a[i]) {  ... }

template <class _InputIter, class _Predicate>
inline _InputIter find_if(_InputIter __first, _InputIter __last,
                          _Predicate __pred,
                          input_iterator_tag)
{
  while (__first != __last && !__pred(*__first))
    ++__first;
  return __first;
}

E>Да и Ада применяется только на Западе

AVC>>А как насчет eao? Ну, наверное, — ничего похожего...

E>Ну почему же? Все именно так, только еще рост в сантиметрах добавлен Причем именно такой ник получился из за ошибки: когда я себе делал первый почтовый ящик, то попросил администратора сделать логин eao195 (точное значение ), но он ошибся и сделал eao197. А потом уже менять не хотелось, чтобы почта не терялась

E>И не нужно меня обвинять в "сухости" и прагматизме -- я ведь не художник, а программист

AVC>После чего совсем погрустнел. Даже кушаю плохо...

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

AVC>Что касается Си++, то когда-то мне нравился этот язык. Пока в него не решили запихнуть все-все-все и еще чуть-чуть, а фундамент оставили прежним. К языку Си у меня больших претензий нет. Как "высокоуровневый ассемблер" он вполне хорош. А вот распространение Си++ во все области ПО (которое упомянуто у Страуструпа и поразило тебя) меня откровенно пугает. Представь себе, что над тобой нависает покосившийся небоскреб, практически лишенный фундамента.

AVC>Но главная моя претензия в данном случае все же состоит в том, что язык разбухает. Требуется знать все больше и больше (о все меньшем и меньшем ).

AVC>Уже и тривиальный цикл написать нельзя. Говорят: используйте стандартные алгоритмы. Т.е. их все надо помнить...

AVC>for (int i = 0; i < sizeof a / sizeof a[0]; ++i)
AVC>    if (v == a[i]) {  ... }
AVC>

AVC>Это мелочь, но и здесь можно немного поспорить.

AVC>template <class _InputIter, class _Predicate>
AVC>inline _InputIter find_if(_InputIter __first, _InputIter __last,
AVC>                          _Predicate __pred,
AVC>                          input_iterator_tag)
AVC>{
AVC>  while (__first != __last && !__pred(*__first))
AVC>    ++__first;
AVC>  return __first;
AVC>}
AVC>

E>

E>Ну да, одна надпись на стене чего стоит

AVC>>После чего совсем погрустнел. Даже кушаю плохо...

E>Это такая же объективная реальность, как и сложность C++

#include <cstdio>

template <bool T = false>
struct s {
    s() { printf("false\n"); }
};

// specialisation

template <>
struct s<true> {
    s() { printf("true\n"); }
};

int main()
{
    s<false> s1; // false
    s<true>  s2; // true
    s<>      s3; // false
    return 0;
}

AVC>>Но главная моя претензия в данном случае все же состоит в том, что язык разбухает. Требуется знать все больше и больше (о все меньшем и меньшем ).

AVC>>Уже и тривиальный цикл написать нельзя. Говорят: используйте стандартные алгоритмы. Т.е. их все надо помнить...

E>Кто говорит? Ну и пусть говорят

AVC>>for (int i = 0; i < sizeof a / sizeof a[0]; ++i)
AVC>>    if (v == a[i]) {  ... }
AVC>>

AVC>>Это мелочь, но и здесь можно немного поспорить.

AVC>>template <class _InputIter, class _Predicate>
AVC>>inline _InputIter find_if(_InputIter __first, _InputIter __last,
AVC>>                          _Predicate __pred,
AVC>>                          input_iterator_tag)
AVC>>{
AVC>>  while (__first != __last && !__pred(*__first))
AVC>>    ++__first;
AVC>>  return __first;
AVC>>}
AVC>>

...
# ошибка "Operand Error" произошла из-за неожиданно большой величины BH (Horizontal Bias – горизонтальный наклон), посчитанной внутренней функцией на основании величины "горизонтальной скорости", измеренной находящимися на Платформе датчиками. Величина BH служила индикатором точности позиционирования Платформы;
# величина BH оказалась много больше, чем ожидалось потому, что траектория полета Ariane 5 на ранней стадии существенно отличалась от траектории полета Ariane 4 (где этот программный модуль использовался ранее), что и привело к значительно более высокой "горизонтальной скорости".
...
Однако, Ariane 5, в отличие от предыдущей модели, имел уже принципиально другую дисциплину выполнения предполетных действий – настолько другую, что работа рокового программного модуля после времени старта вообще не имела смысла. Однако, модуль повторно использовался без каких-либо модификаций – видимо из-за нежелания изменять программный код, который успешно работает.
...
Расследование показало, что в данном программном модуле присутствовало целых семь переменных, вовлеченных в операции преобразования типов. Оказалось, что разработчики проводили анализ всех операций, способных потенциально генерировать исключение, на уязвимость. И это было их вполне сознательным решением добавить надлежащую защиту к четырем переменным, а три – включая BH – оставить незащищенными. Основанием для такого решения была уверенность в том, что для этих трех переменных возникновение ситуации переполнения невозможно в принципе. Уверенность эта была подкреплена расчетами, показывающими, что ожидаемый диапазон физических полетных параметров, на основании которых определяются величины упомянутых переменных, таков, что к нежелательной ситуации привести не может. И это было верно – но для траектории, рассчитанной для модели Ariane 4. А ракета нового поколения Ariane 5 стартовала по совсем другой траектории, для которой никаких оценок не выполнялось. Между тем она (вкупе с высоким начальным ускорением) была такова, что "горизонтальная скорость" превзошла расчетную (для Ariane 4) более чем в пять раз.

E>В качестве примера -- катастрофа Ариан 5 при старте, тогда из-за ошибок программистов не было перехвачено исключение и софт просто вырубился, как на основной, так и на резервной системе контроля. И что толку, что софт был написан на Ada, а не на C++? Поэтому то, что Oberon/Java/C# сгенерирует out of bound exception в run-time, имхо, ничем не поможет программе, в которой это исключение совершенно не ожидалось. А ведь в подавляющем большинстве случаев оно не ожидается

The Remote Agent software, running on a custom port of Harlequin Common Lisp, flew aboard Deep Space 1 (DS1), the first mission of NASA's New Millennium program. Remote Agent controlled DS1 for two days in May of 1999. During that time we were able to debug and fix a race condition that had not shown up during ground testing. (Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem. The story of the Remote Agent bug is an interesting one in and of itself.)

AVC>>Из отчета, ссылку на который дал Cyberax (за что ему отдельное спасибо, хотя не помню, чтобы мы хоть раз совпали во мнениях ), очевидно, что первопричина — в недостаточности вычислительных ресурсов. Соответствующую цитату из отчета я уже приводил.

The reason behind this drastic action lies in the culture within the Ariane programme of only addressing random hardware failures. From this point of view exception — or error — handling mechanisms are designed for a random hardware failure which can quite rationally be handled by a backup system.

AVC>>>Из отчета, ссылку на который дал Cyberax (за что ему отдельное спасибо, хотя не помню, чтобы мы хоть раз совпали во мнениях ), очевидно, что первопричина — в недостаточности вычислительных ресурсов. Соответствующую цитату из отчета я уже приводил.

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

Although the failure was due to a systematic software design error, mechanisms can be introduced to mitigate this type of problem. For example the computers within the SRIs could have continued to provide their best estimates of the required attitude information. There is reason for concern that a software exception should be allowed, or even required, to cause a processor to halt while handling mission-critical equipment. Indeed, the loss of a proper software function is hazardous because the same software runs in both SRI units. In the case of Ariane 501, this resulted in the switch-off of two still healthy critical units of equipment.

GZ> В системе реального времени? Запуск в безопасном режиме? Остановите ракету, мне надо перегрузиться.

GZ>Однако C++ ничего не предпринимает чтобы запретить тебе контролировать выход за границы. Пользуйся объектами.

*((&array[0]) - 10) = 12345;

Язык С++ дает на 25% больше ошибок, чем традиционные Си или Паскаль, а исправление ошибок в ОО программах на С++ требует в 2-3 раза больше времени. Наследование порождает в 6 раз больше ошибок.

PROCEDURE sum(VAR x: ARRAY OF REAL): REAL;
  VAR i: INTEGER; s: REAL;
BEGIN s := 0.0;
  FOR i := 0 TO LEN(x)-1 DO s := x[i] + s END ;
  RETURN s
END sum

VAR a: ARRAY MAX(INTEGER)+2 OF REAL;

pragma SUPPRESS(OUT_OF_BOUNDS);

E>Кроме того, я не очень понимаю твою фразу по поводу разных типов. Ведь оперировали-то одним понятием: дистация. Может быть даже тип ввели такой distance . Только одни вычисляли дистанцию в футах, а другие -- в метрах .

E>Алексей, если так пойдет и дальше, то мы не столько спорить, сколько поддакивать друг другу будем

E>Я думаю, что объективности от Страуструпа ожидать тяжело. Ведь C++ -- это его детище, а какой родитель к своим детям объективно относится?

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

E>Наверное, это объективно так и есть. Вероятно в C++ постоянно находится какая-то неизведанная область, в которую, если есть к этому призвание, всегда хочется заглянуть. Поэтому замшелых C++ программистов так тяжело в другую веру перетянуть. Я сам попробовал на Java поработать. Удобно, просто и скучно пока решаешь типовые задачи для которых готовые framework-и есть. Не удобно, сложно, еще более скучно, если требуется сделать что-то нестандартное. Иное дело C++. Вот придет в голову такая идея: Re: Aka Tuple

Автор: Alexey Chen
Дата: 25.06.05

и ура! День (неделя, месяц) прошел не зря!

MODULE Test;

  IMPORT StdLog;

  PROCEDURE Do*;
    VAR i16: SHORTINT; i64: LONGINT;
  BEGIN
    i64 := 1000000000000001L;

    i16 := SHORT(SHORT(i64));  (* Вот так кастуются от LONGINT к SHORTINT *)

    StdLog.Int(i64); StdLog.Ln;
    StdLog.Int(i16); StdLog.Ln
  END Do;

END Test.

Java Owner: Esmertec, Inc.
Purpose: commercial
Info: www.esmertec.com/
Code: www.esmertec.com/
Source: not available
Requires: target hardware with the Jbed operating system
Provides: Library components of Jbed's Java library. They are needed on the target hardware when running Java code on Jbed, in addition to the Jbed modules.


--------------------------------------------------------------------------------

Javae Owner: Esmertec, Inc.
Purpose: commercial
Info: www.esmertec.com/
Code: www.esmertec.com/
Source: not available
Requires: Windows, BlackBox
Provides: Tool and glue components for turning BlackBox into a Java cross-development environment. Glue to a Java byte-code compiler. Only needed for cross-developing Jbed applications.


--------------------------------------------------------------------------------

Jbed Owner: Esmertec, Inc.
Purpose: commercial
Info: www.esmertec.com/
Code: www.esmertec.com/
Source: not available
Requires: target hardware with the Jbed operating system
Provides: OS components that implement the Jbed real-time operating system. They are needed on the target hardware that runs Jbed.


--------------------------------------------------------------------------------

Jbede Owner: Esmertec, Inc.
Purpose: commercial
Info: www.esmertec.com/
Code: www.esmertec.com/
Source: not available
Requires: Windows, BlackBox
Provides: Tool components for turning BlackBox into a (Component Pascal and Java) cross-development environment. Only needed for cross-developing Jbed applications.


--------------------------------------------------------------------------------

JComm Owner: Esmertec, Inc.
Purpose: commercial
Info: www.esmertec.com/
Code: www.esmertec.com/
Source: not available
Requires: Windows, BlackBox
Provides: Glue components for the communication between Windows PCs and Jbed systems. Only needed for developing or communicating with Jbed applications.