AVC wrote:

> Когда ко мне последний раз пришли с проблемой? Правильно — сегодня!
> Толковый парень, решает сложную математическую задачу.

Если он толковый, то почему пользоваться Гуглом не умеет? По фразе
"multidimensional array C++" выдается достаточно ссылок.

> Понадобился трехмерный массив заранее не определенной размерности.
> Для Оберона это вообще не проблема. И для Java, и для C#. А вот в Си++
> (сколько раз я уже об этом повторил на форуме?) *нет* нормальных массивов.

ЕСТЬ! Только не в языке, а в библиотеках.

> Может быть, скажете, что надо использовать STL, "зачем изобретать
> велосипед"?
> Да не годится vector STL в качестве велосипеда!
> Не дай Бог, забудешь, что вот здесь надо использовать не reserve, а
> resize, или еще одну из кучи таких же столь любимых "знатоками"
> "тонкостей".

Вот такой ошибки я не встречал _ни_ _разу_. Кстати, в C#/Java будут те
же проблемы с ихними resize/reserve в их библиотеках коллекций.

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

> Да, и не забудьте, что писать >> здесь надо через пробел: > >.

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

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

AVC>

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

AVC>

Ну вот, совсем другое дело


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

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

AVC>Напротив, каждый день я вижу, как мучаются эти программисты, многомиллионым количеством которых здесь принято громко хвастаться.
AVC>Ведь за консультацией по Си/Си++ они часто приходят ко мне.

Если перейти на личности, то я представляю себе, с каким отношением к C++ эти программисты затем уходят от тебя
Есть такое понятие, как unix way. Аналогично, есть понятие C++ way (хотя об этом книг и не написано). Так вот любая проблемма, которая тривиальным образом решается в каком-то языке программирования, но не имеет очевидного решения в другом языке просто говорит о том, что для этого (якобы ущербного) языка пытаются использовать чужой подход. Ниже я поясню это на примере.

AVC>Толковый парень, решает сложную математическую задачу. Понадобился трехмерный массив заранее не определенной размерности.
AVC>Для Оберона это вообще не проблема. И для Java, и для C#. А вот в Си++ (сколько раз я уже об этом повторил на форуме?) нет нормальных массивов.
AVC>Может быть, скажете, что надо использовать STL, "зачем изобретать велосипед"?
<...>
AVC>И все равно придется писать свой вспомогательный код!
AVC>Какой же это велосипед? Это просто цепи на ногах.

Привожу реальный пример, в котором отсутствие массивов в C++ позволило существенно сократить трудозатраты за счет изобретения велосипеда. В методе конечных элементов необходимо решать СЛАУ большой размерности, в которой матрица обладает двумя важными свойствами:
— отличные от нуля значения находится в узкой ленте вдоль главной диагонали;
— матрица симметрическая.
Из-за этих особенностей выгодно хранить только верхнюю полуленту матрицы. Но, если выделить массив, который хранит только полуленту, то к элементам такой "виртуальной" матрицы уже нельзя будет обращаться по простым индексам [i,j] -- нужно делать их преобразования. Т.е., везде, где можно было бы записать:

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

пришлось бы делать что-то вроде:

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

Лично для меня второй способ был бы гораздо печальнее, т.к. ошибиться в нем гораздо проще. Поэтому, используя возможности C++, был сделан класс виртуальной матрицы, в котором обращение вида:

a[i][j]

неявным для прикладного программиста образом преобразовывалось в:

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

Вот так, благодоря тому, что в C++ нет таких, казалось бы, основопологающих вещей, как матрицы, удалось получить простое, красивое и эффективное решение сложной задачи. И было сделано это где-то в 94-м году, когда и шаблонов-то в C++ я еще и не видел. А сейчас, на шаблонах, можно делать с матрицами еще более эффективные вещи. Правда, я этими вещами не занимаюсь, поэтому не могу дальше развить эту мысль.

AVC>А насчет вычислений: никуда Вам от них не деться. Даже индекс в массиве Вам приходится вычислять.
AVC>А там где вычисления — там и потенциальные ошибки.

Никогда не сталкивался с потерей точности или ошибками вычислений при вычислении целочисленных индексов из целочисленных же значений.

AVC>Си++ не помогает с ними бороться. Скорее — наоборот.

Имхо, C++ позволяет достаточно удобно записывать то, что ты хочешь получить. Если при этом ты сам записал что-то не то, то C++ здесь не при чем. Не имеет смысла менять безопасную бритву на опасную, если не умеешь пользоваться последней.

E>>>>Теперь объясни мне, где же я ошибся в определении причины катастрофы? Главное, что исключение возникло там, где его не ждали.
AVC>>>Главное — что сняли защиту.
E>>Нет, имхо, проблема была в проектировании, в том что было решено использовать оригинальные модули от Ариан 4 в Ариан 5. А уже то, что где-то был выполнен явный каст -- это уже следствие.

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

Так ведь это обычные условия. В реальной жизни всегда чего-нибудь не хватает.

E>>Собственно, поэтому мне и не нравятся аргументы типа: "C++ позволяет неявный каст, что плохо. С++ не контролирует выходы за пределы массивов, что плохо. С++ то, С++ се". Все это граничные условия, которые нужно учитывать, используя C++ для решения конкретных задач. Если какое-то из условий не было учтено, то, вероятно, это была ошибка проектирования. А ошибки проектирования страшны для любых языков.

AVC>Что верно, то верно.
AVC>Но когда я из переменной некоего класса получаю float неявным преобразованием через bool(), что уже само по себе абсурдно, а потом меня еще начинают поучать, что, дескать, это такая "фича" языка, и все просто OK, это — дурдом.

Это не дурдом, это особенность. Точно такая же, как необходимость объявлять переменные в Pascal-е в специальной секции var, а не в том блоке, где она необходима.

AVC>Чтобы там не провещал Страуструп, я еще не разучился различать черное и белое.

Имхо, мир гораздо богаче оттенками, чем только черное и белоее. Развивая эту мысль хотел бы провести такую аналогию: программирование на паскале-подобных языках -- это рисование фломастерами, нужный оттенок можно получить, только если он есть в наличии (ну, или если есть очень большой опыт и везение, скажем зеленый цвет можно получить проведя синим фломастером по следу желтого). Но даже рисование простым карандашом (что-то похожее на C) дает гораздо больше выразительных возможностей. C++ -- это уже масляная живопись -- много мудоты, краски долго сохнут, свежий слой можно класть либо на свежий еще слой, либо на полностью просохший слой. Писать можно только на специально прогрунтованных поверхностях (картоне, досках, холстах, стенах, на простом ватмане уже не получится). Зато какой результат в умелых руках получается! А Java/C# -- это темпера (хотя сам не пробовал, только читал) -- вроде почти тоже, что и масло, но ярче и сохнет быстрее, разводится простой водой, менее требовательна к поверхности. Но вот с полутонами и полупрозрачными слоями там беда, до масла далеко.

Прошу прощения за задержку.

>> Собственно, я защищаю Оберон за то, что это *первый в мире язык
>> программирования, обеспечивающий безопасность типов*.

C>Вранье. Причем наглое. До Оберона была Ада, в которой намного больше
C>средств контроля за типами, была типизированная scheme, была еще куча
C>языков, был даже ML.

Я чувствую некоторое смущение.
По крайней мере, об Аде я просто забыл в момент написания поста.
Причина понятна, хотя, может быть, и не извинительна: я никогда не рассаматривал Аду как реальный язык программирования для PC или каких-нибудь используемых мной в работе микропроцессоров.
В этот момент я думал в основном о цепочках C/C++ и Oberon/Java/C#.
Пока что я не готов возражать по безопасности типов в Аде (несмотря на то, что в "мое" время на ВМиК лекции Кауфмана иллюстрировались именно этим языком), поэтому свое слишком сильное утверждение (временно?) снимаю.
Конечно, "причина любви" к Оберону этим никак не устраняется, т.к. перешел я к нему от C++, а не от Ады.
А за напоминание об Аде — спасибо!
Что касается ML, то это вообще "другая песня". Функциональные или специализированные языки я здесь не обсуждаю за отсутствием собственного практического опыта в этой области (о чем искренне сожалею).

C>Оберон появился в конце 80-х, а Ада была еще в 70-х годах. Ее
C>предшественники — еще раньше.

Как бы то ни было, основным предшественником Ады был Паскаль.
Именно его (а не Алгол-68 или PL/1) выбрали в качестве отправной точки все четыре рабочие группы.
Кроме того, вряд ли стоит так упирать на то, что Ада появилась раньше Оберона.
Оберон — это некоторая переработка (в основном — упрощение, избавление от "лишних" конструкций) Модулы-2.
В 1979 году, когда уже активно использовался компилятор Модулы-2, компилятором Ады и "не пахло".

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

>> Когда ко мне последний раз пришли с проблемой? Правильно — сегодня!
>> Толковый парень, решает сложную математическую задачу.

C>Если он толковый, то почему пользоваться Гуглом не умеет? По фразе
C>"multidimensional array C++" выдается достаточно ссылок.

Ну да, конечно. "Если вы такие умные, то почему строем не ходите?"
Ваши программистские потребности возросли. Раньше Вы обходились boost'ом.
Теперь Вам для писания на Си++ нужен еще Google.
То ли еще будет!

>> Понадобился трехмерный массив заранее не определенной размерности.
>> Для Оберона это вообще не проблема. И для Java, и для C#. А вот в Си++
>> (сколько раз я уже об этом повторил на форуме?) *нет* нормальных массивов.
C>ЕСТЬ! Только не в языке, а в библиотеках.

Так я и говорю, что в языке нет.

>> Может быть, скажете, что надо использовать STL, "зачем изобретать
>> велосипед"?
>> Да не годится vector STL в качестве велосипеда!
>> Не дай Бог, забудешь, что вот здесь надо использовать не reserve, а
>> resize, или еще одну из кучи таких же столь любимых "знатоками"
>> "тонкостей".

C>Вот такой ошибки я не встречал _ни_ _разу_. Кстати, в C#/Java будут те
C>же проблемы с ихними resize/reserve в их библиотеках коллекций.

Логично.
Что-то вроде:
— Во-первых, я вашего горшка не брала. Во-вторых, когда я его вам вернула, он был целый. В-третьих, когда я его у вас брала, он уже был треснутый.

Прошу прощения за задержку с ответом: обстоятельства.

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

E>Да, опыт внушает.
E>Но, имхо, как раз фраза Страуструпа к тебе и относится, т.к. твой большой опыт не позволяет тебе увидеть, что он (опыт) всего лишь маленькая капля в море.

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

AVC>>Напротив, каждый день я вижу, как мучаются эти программисты, многомиллионым количеством которых здесь принято громко хвастаться.
AVC>>Ведь за консультацией по Си/Си++ они часто приходят ко мне.
E>Если перейти на личности, то я представляю себе, с каким отношением к C++ эти программисты затем уходят от тебя

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

E>Есть такое понятие, как unix way. Аналогично, есть понятие C++ way (хотя об этом книг и не написано). Так вот любая проблемма, которая тривиальным образом решается в каком-то языке программирования, но не имеет очевидного решения в другом языке просто говорит о том, что для этого (якобы ущербного) языка пытаются использовать чужой подход. Ниже я поясню это на примере.
E>Привожу реальный пример, в котором отсутствие массивов в C++ позволило существенно сократить трудозатраты за счет изобретения велосипеда. В методе конечных элементов необходимо решать СЛАУ большой размерности, в которой матрица обладает двумя важными свойствами:
E>- отличные от нуля значения находится в узкой ленте вдоль главной диагонали;
E>- матрица симметрическая.
E>Из-за этих особенностей выгодно хранить только верхнюю полуленту матрицы. Но, если выделить массив, который хранит только полуленту, то к элементам такой "виртуальной" матрицы уже нельзя будет обращаться по простым индексам [i,j] -- нужно делать их преобразования. Т.е., везде, где можно было бы записать:
E>

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

E>пришлось бы делать что-то вроде:
E>

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

E>Лично для меня второй способ был бы гораздо печальнее, т.к. ошибиться в нем гораздо проще. Поэтому, используя возможности C++, был сделан класс виртуальной матрицы, в котором обращение вида:
E>

E>a[i][j]
E>

E>неявным для прикладного программиста образом преобразовывалось в:
E>

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

E>Вот так, благодоря тому, что в C++ нет таких, казалось бы, основопологающих вещей, как матрицы, удалось получить простое, красивое и эффективное решение сложной задачи. И было сделано это где-то в 94-м году, когда и шаблонов-то в C++ я еще и не видел. А сейчас, на шаблонах, можно делать с матрицами еще более эффективные вещи. Правда, я этими вещами не занимаюсь, поэтому не могу дальше развить эту мысль.

ИМХО, никакой иной "пользы", кроме того, что это все это проделано неявно для программиста, не видно.
Такая "неявность" скорее вредна, чем полезна (пример с неявным (!) преобразованием во float через bool я уже приводил).
Чем хуже тривиальное get(a, i, j)? Только тем, что несколько иначе выглядит? Так ведь это и хорошо!
В противном случае программист может быть просто обманут, думая, что и правда имеет дело с массивом.

AVC>>А насчет вычислений: никуда Вам от них не деться. Даже индекс в массиве Вам приходится вычислять.
AVC>>А там где вычисления — там и потенциальные ошибки.
E>Никогда не сталкивался с потерей точности или ошибками вычислений при вычислении целочисленных индексов из целочисленных же значений.

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

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

E>>>>>Теперь объясни мне, где же я ошибся в определении причины катастрофы? Главное, что исключение возникло там, где его не ждали.
AVC>>>>Главное — что сняли защиту.
E>>>Нет, имхо, проблема была в проектировании, в том что было решено использовать оригинальные модули от Ариан 4 в Ариан 5. А уже то, что где-то был выполнен явный каст -- это уже следствие.
AVC>>Из отчета, ссылку на который дал Cyberax (за что ему отдельное спасибо, хотя не помню, чтобы мы хоть раз совпали во мнениях ), очевидно, что первопричина — в недостаточности вычислительных ресурсов. Соответствующую цитату из отчета я уже приводил.
AVC>>Если бы с ресурсами было все в порядке, вычисления производились бы с использованием соответствующего типа, а не 16-битного знакового целого; и все преобразования, если бы они потребовались, были бы защищены от подобных исключений.
AVC>>А так программисты вынуждены были искать, где пожертвовать надежностью.
E>Так ведь это обычные условия. В реальной жизни всегда чего-нибудь не хватает.

Одно дело, когда "чего-нибудь не хватает" в офисном приложении.
Другое дело — в аэрокосмической, ядерной или военной областях.
Я бы на Вашем месте не был настроен столь философски.
В главной же Вашей мысли, что это не столько ошибка кодирования, сколько большая проектная ошибка, я с Вами согласен. В свободное время япытался представить себе, что именно я бы сделал на месте программистов Ариана-5 в тех условиях. Ничего утешительного не придумал...
Но, кажется, отсюда мы с Вами делаем разные выводы. Вы говорите, что так было, так есть, так будет (или нет?). А я говорю, что, если не хватает ресурсов для нормального (защищенного и типо-безопасного) программирования, лучше вообще не браться за подобные проекты.

E>Это не дурдом, это особенность.

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

E>Точно такая же, как необходимость объявлять переменные в Pascal-е в специальной секции var, а не в том блоке, где она необходима.

Вообще-то, в Паскале, Модуле и Обероне переменная объявляется именно там, где нужна.
Просто некоторые Си++программисты не в курсе, как именно это делается.
Допустим, я хочу провести поиск какого-нибудь значения в массиве.
Ясно, что для этого мне потребуются дополнительные переменные, которые может быть больше в данной процедуре нигде не нужны.
Я просто выношу поиск во вложенную процедуру:

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;

А теперь важное замечание. Если нет рекурсии, и программист не запрещает, то компилятор сделает вложенную процедуру подставляемой (inline). Так что нет ни потери ясности, ни потери эффективности.
А вот в Си++ сидишь и гадаешь, как изволит компилятор отнестись к конструкции

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

Будет ли переменная i "жива" и после цикла, как в Visual C++ 6.0, или нет, как полагается по стандарту?

AVC>>Чтобы там не провещал Страуструп, я еще не разучился различать черное и белое.
E>Имхо, мир гораздо богаче оттенками, чем только черное и белоее. Развивая эту мысль хотел бы провести такую аналогию: программирование на паскале-подобных языках -- это рисование фломастерами, нужный оттенок можно получить, только если он есть в наличии (ну, или если есть очень большой опыт и везение, скажем зеленый цвет можно получить проведя синим фломастером по следу желтого). Но даже рисование простым карандашом (что-то похожее на C) дает гораздо больше выразительных возможностей. C++ -- это уже масляная живопись -- много мудоты, краски долго сохнут, свежий слой можно класть либо на свежий еще слой, либо на полностью просохший слой. Писать можно только на специально прогрунтованных поверхностях (картоне, досках, холстах, стенах, на простом ватмане уже не получится). Зато какой результат в умелых руках получается! А Java/C# -- это темпера (хотя сам не пробовал, только читал) -- вроде почти тоже, что и масло, но ярче и сохнет быстрее, разводится простой водой, менее требовательна к поверхности. Но вот с полутонами и полупрозрачными слоями там беда, до масла далеко.

Очень интересная параллель!
Знаете, это достаточно забавно, но среди Си++программистов достаточно много людей с художественными (но, к сожалению, не математическими) наклонностями!
Один мой добрый знакомый — действительно гениальный Си++программист (по крайней мере, второго такого я не встречал) — пытался как-то мне объяснить процесс своего мышления над программой. Сначала он немного помычал для внушительности, затем стал решительно тыкать пальцем в закатное небо и перечислять, какие оттенки и особенности он там видит. Сознаюсь — я мало что понял, но зато запомнил эту картину закатного неба на всю жизнь!
Я мог быть развить эту тему разных стилей программистского мышления, с их плюсами и минусами, но пусть лучше остается все как есть — в виде яркого воспоминания.

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

E>>Да, опыт внушает.
E>>Но, имхо, как раз фраза Страуструпа к тебе и относится, т.к. твой большой опыт не позволяет тебе увидеть, что он (опыт) всего лишь маленькая капля в море.

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

Я тоже. И сейчас пишу.
И еще раз, еще более уверенно в своей правоте, повторю, что слова Страуструпа к тебе и относятся.

E>>Привожу реальный пример, в котором отсутствие массивов в C++ позволило существенно сократить трудозатраты за счет изобретения велосипеда. В методе конечных элементов необходимо решать СЛАУ большой размерности, в которой матрица обладает двумя важными свойствами:
E>>- отличные от нуля значения находится в узкой ленте вдоль главной диагонали;
E>>- матрица симметрическая.
E>>Из-за этих особенностей выгодно хранить только верхнюю полуленту матрицы. Но, если выделить массив, который хранит только полуленту, то к элементам такой "виртуальной" матрицы уже нельзя будет обращаться по простым индексам [i,j] -- нужно делать их преобразования. Т.е., везде, где можно было бы записать:
E>>

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

E>>пришлось бы делать что-то вроде:
E>>

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

E>>Лично для меня второй способ был бы гораздо печальнее, т.к. ошибиться в нем гораздо проще. Поэтому, используя возможности C++, был сделан класс виртуальной матрицы, в котором обращение вида:
E>>

E>>a[i][j]
E>>

E>>неявным для прикладного программиста образом преобразовывалось в:
E>>

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

AVC>ИМХО, никакой иной "пользы", кроме того, что это все это проделано неявно для программиста, не видно.

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

AVC>Такая "неявность" скорее вредна, чем полезна (пример с неявным (!) преобразованием во float через bool я уже приводил).
AVC>Чем хуже тривиальное get(a, i, j)? Только тем, что несколько иначе выглядит? Так ведь это и хорошо!

Нет, это плохо. Такая запись гораздо длинее и черевата ошибками (как, например, заметить, где i и j случайно поменяли местами). А в получившемся варианте использовалась стандартная математическая запись.

И именно эта запись позволила корректно и быстро записать выражения аппроксимации (треугольниками и прямоугольниками) при вычислении начального значения матрицы (этим занимался не я, но те, кто это делал сказали мне спасибо), а формулы там трехэтажные были. А мне такая запись позволила легко реализовать три или четыре метода решения СЛАУ в поисках того метода, который бы давал решение за приемлимое время (вообще в этой задаче метод итераций сходился медлено, методы Гауса и квадратного корня нельзя было применять из-за особенности матрицы, пришлось использовать метод Халецкого).

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

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

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

AVC>>>А насчет вычислений: никуда Вам от них не деться. Даже индекс в массиве Вам приходится вычислять.
AVC>>>А там где вычисления — там и потенциальные ошибки.
E>>Никогда не сталкивался с потерей точности или ошибками вычислений при вычислении целочисленных индексов из целочисленных же значений.

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

Выход за границы массива и потеря точности при вычислениях -- это совершенно разные вещи. В первом случае я получаю абсолютно точное значение, просто из-за моей ошибки оно оказывается не в том диапазоне. А реальная потеря точности, это когда в правильном выражении получается неправильный результат из-за ограничений платформы. Например: c/(a-b). Если a != b, то это выражение корректно и в математическом смысле всегда дает корректный результат. Но, если a и b являются вещественными числами, то корректность выражения начнет зависеть от величины (a-b). Если это довольно близкие значения, то их разность окажется слишком маленьким числом из-за чего c/(a-b) не сможет быть представлена.
Еще один пример неявной потрери точности обсуждался в форуме по C++.

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

AVC>Одно дело, когда "чего-нибудь не хватает" в офисном приложении.
AVC>Другое дело — в аэрокосмической, ядерной или военной областях.
AVC>Я бы на Вашем месте не был настроен столь философски.

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

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

В любой проблеме скрыта возможность ((С) американская поговорка).
Так может тогда прогресс вообще остановить?
А как же Билл Гейтс, который с Полом Аленом (или я ошибаюсь) втиснули Бейсик в 4K, чего до них никто не делал?

E>>Это не дурдом, это особенность.

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

Буду рад. Только авторство укажи
На самом деле "в каждом закуточке свои заморочки". Глупо утверждать, что С++ -- это идеальный язык программирования. Но он реальный язык, с реальными возможностями и проблемами. И здесь можно либо просто оказаться от использования C++ (тогда не понятно, зачем на него наезжать), либо учитывать его особенности в работе и получать предсказуемые результаты, либо занять позицию страуса, а потом громко кричать: "Настоящие программисты на C++ не программируют!".
Конечно не программируют, они на нем думают, а потом просто свои мысли записывают. И все.

E>>Точно такая же, как необходимость объявлять переменные в Pascal-е в специальной секции var, а не в том блоке, где она необходима.

AVC>Вообще-то, в Паскале, Модуле и Обероне переменная объявляется именно там, где нужна.

Т.е., если переменная нужна в какой-то функции, то она должна быть объявлена в общей секции var этой функции Так ведь я об этом и говорил. А вот в C++, если переменная нужна в каком-то блоке функции, то она там и объявляется.

AVC>Просто некоторые Си++программисты не в курсе, как именно это делается.

Да, а твой пример наглядно показал, насколько нужно больше написать, чтобы сделать то, что в C++ вообще не занимает времени. Более того, твой код LocalSearch во-первых, жестко привязан к типу массива и искомого элемента и, во-вторых, жестко привязан к внутренностям GlobalProc. Поэтому тебе придется переписывать LocalSearch для GlobalProcReal (там где будут использоваться вещественные значения) и придется переписывать, если в GlobalProc нужно будет сделать поиск по еще одному массивчику b другой размерности.

А теперь сравни это все с std::find_if

AVC>А вот в Си++ сидишь и гадаешь, как изволит компилятор отнестись к конструкции
AVC>

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

AVC>Будет ли переменная i "жива" и после цикла, как в Visual C++ 6.0, или нет, как полагается по стандарту?

Если компилятор соответствует стандарту C++, то не будет. А ведь Visual C++ 6.0 стандарту не соответствует.

Кстати, есть ли для Modula и Oberon стандарт? ANSI или ISO?

AVC>Знаете, это достаточно забавно, но среди Си++программистов достаточно много людей с художественными (но, к сожалению, не математическими) наклонностями!

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

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

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

Нет, первопричина — в пресловутом кодреюзе.

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

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

Т>Нет, первопричина — в пресловутом кодреюзе.

Наверное, Вы имеете в виду, что код во многом унаследован от Ариана-4 (если не раньше)?
Вырисовывается такая картина: код во многом остался прежним, а вот траектория полета изменилась.
Можно подумать, что в этом и есть причина катастрофы.
Но мне так не кажется.
Если бы код, унаследованный от Ариана-4, был действительно корректным, то и с Арианом-5 беды бы не случилось.
Возможно, мое мнение покажется Вам спорным.
Все упирается в понятие ошибки; вопрос почти философский.

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

E>>>Да, опыт внушает.
E>>>Но, имхо, как раз фраза Страуструпа к тебе и относится, т.к. твой большой опыт не позволяет тебе увидеть, что он (опыт) всего лишь маленькая капля в море.
AVC>>(голосом кота Матроскина) Я еще и СУБД писал...
E>Я тоже. И сейчас пишу.
E>И еще раз, еще более уверенно в своей правоте, повторю, что слова Страуструпа к тебе и относятся.

Спасибо за ссылки — интересно.
Что же касается "капли в море", я с этим не спорю.
Но чтобы выяснить химический состав воды (H2O), нет нужды вычерпать всю воду из океана.

AVC>>ИМХО, никакой иной "пользы", кроме того, что это все это проделано неявно для программиста, не видно.

E>Именно в этом задача и состояла -- нужно было повысить уровень абстракции.

AVC>>Такая "неявность" скорее вредна, чем полезна (пример с неявным (!) преобразованием во float через bool я уже приводил).
AVC>>Чем хуже тривиальное get(a, i, j)? Только тем, что несколько иначе выглядит? Так ведь это и хорошо!

E>Нет, это плохо. Такая запись гораздо длинее и черевата ошибками (как, например, заметить, где i и j случайно поменяли местами). А в получившемся варианте использовалась стандартная математическая запись.

Интересно, а что помешает поменять местами i и j, например, в выражении

a[j][i]

?

E>И именно эта запись позволила корректно и быстро записать выражения аппроксимации (треугольниками и прямоугольниками) при вычислении начального значения матрицы (этим занимался не я, но те, кто это делал сказали мне спасибо), а формулы там трехэтажные были. А мне такая запись позволила легко реализовать три или четыре метода решения СЛАУ в поисках того метода, который бы давал решение за приемлимое время (вообще в этой задаче метод итераций сходился медлено, методы Гауса и квадратного корня нельзя было применять из-за особенности матрицы, пришлось использовать метод Халецкого).

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

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

E>Или ты считаешь, что операционнки с виртуальной памятью тебя обманывают, неявно вытесняя старые страницы на диск и подкачивая их по необходимости?

Когда все это тормозит (что обыкновенно), то я и правда начинаю сердиться.

AVC>>>>А насчет вычислений: никуда Вам от них не деться. Даже индекс в массиве Вам приходится вычислять.
AVC>>>>А там где вычисления — там и потенциальные ошибки.
E>>>Никогда не сталкивался с потерей точности или ошибками вычислений при вычислении целочисленных индексов из целочисленных же значений.
AVC>>И за границы массива никогда не выходили?!
E>Выход за границы массива и потеря точности при вычислениях -- это совершенно разные вещи. В первом случае я получаю абсолютно точное значение, просто из-за моей ошибки оно оказывается не в том диапазоне. А реальная потеря точности, это когда в правильном выражении получается неправильный результат из-за ограничений платформы. Например: c/(a-b). Если a != b, то это выражение корректно и в математическом смысле всегда дает корректный результат. Но, если a и b являются вещественными числами, то корректность выражения начнет зависеть от величины (a-b). Если это довольно близкие значения, то их разность окажется слишком маленьким числом из-за чего c/(a-b) не сможет быть представлена.
E>Еще один пример неявной потрери точности обсуждался в форуме по C++.

Обратите внимание: я говорил об ошибках в вычислениях, а Вы — о потере точности.
ИМХО, Вы слишком сузили тему.

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

AVC>>Одно дело, когда "чего-нибудь не хватает" в офисном приложении.
AVC>>Другое дело — в аэрокосмической, ядерной или военной областях.
AVC>>Я бы на Вашем месте не был настроен столь философски.

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

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

E>В любой проблеме скрыта возможность ((С) американская поговорка).

Угу. Особенно для американцев. И особенно — в чужих проблемах.

E>Так может тогда прогресс вообще остановить?

А что такое прогресс?

E>>>Это не дурдом, это особенность.
AVC>>Я, наверное, эту Вашу фразу на стенку повешу.
AVC>>Насколько здесь выразительнее сформулирована старая мысль "это не баг, это фича".
E>Буду рад. Только авторство укажи

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

E>На самом деле "в каждом закуточке свои заморочки". Глупо утверждать, что С++ -- это идеальный язык программирования. Но он реальный язык, с реальными возможностями и проблемами. И здесь можно либо просто оказаться от использования C++ (тогда не понятно, зачем на него наезжать), либо учитывать его особенности в работе и получать предсказуемые результаты, либо занять позицию страуса, а потом громко кричать: "Настоящие программисты на C++ не программируют!".
E>Конечно не программируют, они на нем думают, а потом просто свои мысли записывают. И все.

E>Да, а твой пример наглядно показал, насколько нужно больше написать, чтобы сделать то, что в C++ вообще не занимает времени. Более того, твой код LocalSearch во-первых, жестко привязан к типу массива и искомого элемента и, во-вторых, жестко привязан к внутренностям GlobalProc. Поэтому тебе придется переписывать LocalSearch для GlobalProcReal (там где будут использоваться вещественные значения) и придется переписывать, если в GlobalProc нужно будет сделать поиск по еще одному массивчику b другой размерности.
E>А теперь сравни это все с std::find_if

В данном случае Ваша критика несправедлива.
Вложенная процедура играет здесь ту же роль, что и блок в Си++ (собственно, и является блоком), только более выразительно.
Что касается зависимости LocalSearch от типа.
Во-первых, в данном частном случае я мог не использовать параметр (x: INTEGER), тогда в теле LocalSearch не было бы упоминания о типе. Я сделал это только для наглядности, чтобы проиллюстрировать прием.
Во-вторых, в Си++ зависимость от типа никак не меньше.
Говоря о find_if, Вы запамятовали упомянуть о некоторых деталях.
Во-первых, использование find_if предполагает использование итератора, причем привязанного как к типу элемента, так и к типу контейнера. Что-то вроде:

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

Во-вторых, Вы почему-то ничего не сказали о таких мелочах, как написании класса предиката, наследовании от unary_function или binary_function и т.д.
В-третьих, сколько всей этой ерунды надо помнить...

E>Кстати, есть ли для Modula и Oberon стандарт? ANSI или ISO?

Для Модулы-2 есть стандарт ISO (уже давно).
Именно поэтому в аэрокосмической сфере применяются в основном Ада и Модула-2 — языки, имеющие стандарты ISO.

AVC>>Знаете, это достаточно забавно, но среди Си++программистов достаточно много людей с художественными (но, к сожалению, не математическими) наклонностями!
E>Так может это и хорошо? Например, я часто видел, что у людей с ярковыраженным математическим мышлением довольно плохо с неординарными идеями.

О художественных способностях Си++программистов я упомянул с симпатией.
Мне нравится в них это качество. Другие их качества ине нравятся гораздо меньше.
И вообще... Про нас, математиков, все говорят, что мы сухари (х/ф "17 мгновений весны").
Вся математика — просто скукотища какая-то... Ни одной неординарной идеи!
А, впрочем, может — сверим неординарность мышления?
Вот у меня на RSDN ник AVC. Все просто и ординарно — это инициалы: имя, отчество и фамилия.
А как насчет eao? Ну, наверное, — ничего похожего...

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

AVC>>>(голосом кота Матроскина) Я еще и СУБД писал...
E>>Я тоже. И сейчас пишу.
E>>И еще раз, еще более уверенно в своей правоте, повторю, что слова Страуструпа к тебе и относятся.

AVC>Спасибо за ссылки — интересно.

Да не за что
Ну нужно же себя как-то рекламировать

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

AVC>>>ИМХО, никакой иной "пользы", кроме того, что это все это проделано неявно для программиста, не видно.

E>>Именно в этом задача и состояла -- нужно было повысить уровень абстракции.

AVC>>>Такая "неявность" скорее вредна, чем полезна (пример с неявным (!) преобразованием во float через bool я уже приводил).
AVC>>>Чем хуже тривиальное get(a, i, j)? Только тем, что несколько иначе выглядит? Так ведь это и хорошо!

E>>Нет, это плохо. Такая запись гораздо длинее и черевата ошибками (как, например, заметить, где i и j случайно поменяли местами). А в получившемся варианте использовалась стандартная математическая запись.

AVC>Интересно, а что помешает поменять местами i и j, например, в выражении
AVC>

AVC>a[j][i]
AVC>

AVC>?

Ну, если более высокий уровень абстракции мы не рассматриваем, а говорим о вероятности ошибок, то в выражении:

get_i( a, i, j )

Гораздо проще поменять местами i и j, можно ведь даже get_j написать, вместо get_i.

E>>Выход за границы массива и потеря точности при вычислениях -- это совершенно разные вещи. В первом случае я получаю абсолютно точное значение, просто из-за моей ошибки оно оказывается не в том диапазоне. А реальная потеря точности, это когда в правильном выражении получается неправильный результат из-за ограничений платформы. Например: c/(a-b). Если a != b, то это выражение корректно и в математическом смысле всегда дает корректный результат. Но, если a и b являются вещественными числами, то корректность выражения начнет зависеть от величины (a-b). Если это довольно близкие значения, то их разность окажется слишком маленьким числом из-за чего c/(a-b) не сможет быть представлена.
E>>Еще один пример неявной потрери точности обсуждался в форуме по C++.

AVC>Обратите внимание: я говорил об ошибках в вычислениях, а Вы — о потере точности.
AVC>ИМХО, Вы слишком сузили тему.

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

E>>В любой проблеме скрыта возможность ((С) американская поговорка).

AVC>Угу. Особенно для американцев. И особенно — в чужих проблемах.

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

E>>Так может тогда прогресс вообще остановить?

AVC>А что такое прогресс?

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

E>>>>Это не дурдом, это особенность.
AVC>>>Я, наверное, эту Вашу фразу на стенку повешу.
AVC>>>Насколько здесь выразительнее сформулирована старая мысль "это не баг, это фича".
E>>Буду рад. Только авторство укажи

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



E>>А теперь сравни это все с std::find_if

AVC>В данном случае Ваша критика несправедлива.
AVC>Вложенная процедура играет здесь ту же роль, что и блок в Си++ (собственно, и является блоком), только более выразительно.
AVC>Что касается зависимости LocalSearch от типа.
AVC>Во-первых, в данном частном случае я мог не использовать параметр (x: INTEGER), тогда в теле LocalSearch не было бы упоминания о типе. Я сделал это только для наглядности, чтобы проиллюстрировать прием.
AVC>Во-вторых, в Си++ зависимость от типа никак не меньше.

Но ведь в C++ мне не нужно писать LocalSearch для разных случаях, он уже написан.

AVC>Говоря о find_if, Вы запамятовали упомянуть о некоторых деталях.
AVC>Во-первых, использование find_if предполагает использование итератора, причем привязанного как к типу элемента, так и к типу контейнера. Что-то вроде:
AVC>

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

Ну и что? В случае с контейнерами итераторы уже реализованы. Но find_if можно использовать и с векторами:

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

AVC>Во-вторых, Вы почему-то ничего не сказали о таких мелочах, как написании класса предиката, наследовании от unary_function или binary_function и т.д.

Для многих стандартных алгоритмов, в том числе и для find_if, это не обязательно.

AVC>В-третьих, сколько всей этой ерунды надо помнить...

Да, вот с этим сложно спорить.

E>>Кстати, есть ли для Modula и Oberon стандарт? ANSI или ISO?

AVC>Для Модулы-2 есть стандарт ISO (уже давно).
AVC>Именно поэтому в аэрокосмической сфере применяются в основном Ада и Модула-2 — языки, имеющие стандарты ISO.

По существование ISO стандартов для Модулы и Ада не знал, спасибо.
Хотя, думаю, причина использования в этих областях Ада и Модула-2 не в этом.
Да и Ада применяется только на Западе

AVC>Вот у меня на RSDN ник AVC. Все просто и ординарно — это инициалы: имя, отчество и фамилия.
AVC>А как насчет eao? Ну, наверное, — ничего похожего...

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

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

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

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

AVC>>>>ИМХО, никакой иной "пользы", кроме того, что это все это проделано неявно для программиста, не видно.
E>>>Именно в этом задача и состояла -- нужно было повысить уровень абстракции.

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

E>>>Выход за границы массива и потеря точности при вычислениях -- это совершенно разные вещи. В первом случае я получаю абсолютно точное значение, просто из-за моей ошибки оно оказывается не в том диапазоне. А реальная потеря точности, это когда в правильном выражении получается неправильный результат из-за ограничений платформы. Например: c/(a-b). Если a != b, то это выражение корректно и в математическом смысле всегда дает корректный результат. Но, если a и b являются вещественными числами, то корректность выражения начнет зависеть от величины (a-b). Если это довольно близкие значения, то их разность окажется слишком маленьким числом из-за чего c/(a-b) не сможет быть представлена.
E>>>Еще один пример неявной потрери точности обсуждался в форуме по C++.
AVC>>Обратите внимание: я говорил об ошибках в вычислениях, а Вы — о потере точности.
AVC>>ИМХО, Вы слишком сузили тему.
E>May be. Но выход за пределы массива, это явная ошибка, избежать которую позволяет даже минимальный уровень знаний. Более того, не нужно иметь серьезную математическую подготовку, чтобы найти ее. А вот с потерей точности дело гораздо сложнее. Во время учебы я сам сталкивался с тем, что не знание тонкостей применяемого вычислительного метода сложно получить работоспособную реализацию именно из-за органичений в представлении вещественных чисел.

Совершенно согласен.
Более того, поднятые тобой вопросы управления точностью вычислений с плавающей точкой мне интересны гораздо больше выходов за пределы массива. Просто я с туповатым педантизмом зафиксировал небольшое отклонение от намеченного курса, примерно так, как судья в теннисе кричит "Аут!" без всякой задней мысли.

E>>>В любой проблеме скрыта возможность ((С) американская поговорка).
AVC>>Угу. Особенно для американцев. И особенно — в чужих проблемах.
E>Ну можно к американцам по разному относиться, но то что, сейчас они остались единственной сверхдержавой, это факт. А вот мы все такие умные, что... Но это уже офтопик.

На самом деле, я уважаю американцев за некоторые их качества: упорство, инициативность, изобретательность. И др.
Некоторые американцы у меня вызывают искреннее восхищение. Например, Бенджамен Франклин. (Не за то, что он изображен на купюре. )
Претензии же у меня к США почти исключительно нравственного характера, но серьезные.
Ведут они себя как римляне в античные времена, следуя принципу divide et impera и зачастуя разжигая в людях рознь.
О ядерных бомбардировках, напалме, химическом оружии и т.д. я уже не говорю.
Впрочем, это уже и правда офтоп для программистского форума.

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

По ряду пунктов мы как бы скатываемся в офтопик.
Правда, я уверен, что при обсуждении некоторых проблем это практически неизбежно и даже правильно.
Некоторые вещи можно понять только в связи с другими, вместе с которыми они составляют систему.
В противном случае, мы, прямо как узники платоновской пещеры, обречены видеть только мелькание теней на стене.
Конечн, при расширении темы важно не потерять из виду основной цели обсуждения и не сбиться на треп.
Что касается именно прогресса, то (ИМХО) не следует забывать, что приобретая что-то новое, мы также что-то и утрачиваем. И я не вижу никаких гарантий, что утраченное не окажется более ценным.
Например, в пору моего детства продукты в продовольственных магазинах не отличались большим разнообразием. Это, наверное, плохо и "непрогрессивно". Но практически все они были натуральными. А это хорошо. Что важнее? В последнее время мне бросается в глаза, что дети в массе стали болезненней, чем прежде. (Я уже не говорю о том, что и самих детей стало меньше.)
В отношении языков программирования наблюдается тенденция пренебрегать надежностью. Возможно, в пользу производительности, хотя подтверждающих это данных у меня нет. Наверное, пока мы остаемся в рамках офисных приложений, это экономически оправдано, т.к. цена ошибок и сбоев сравнительно невысока, а рост производительности может быть значительным (хотя это зависит и от организационных факторов).
Часто такой подход иллюстрируют таким примером: хотя автомобиль делает жизнь немного более опасной, люди пренебрегают этим риском ради дополнительных удобств (экономия времени, свобода передвижения и т.д.)
Но (ИМХО) было бы ошибочно переносить такой подход на все сферы жизни. Существует ряд отраслей (ядерная, военная и т.д.), чреватых глобальными катастрофами. Здесь приоритет следует отдать надежности, в том числе — надежности ПО. А надежность ПО включает в себя много составляющих, среди которых строгий контроль типов, простота языка и основанная на этом корректность компилятора играют далеко не последнюю роль.
Создание такого простого языка — трудная задача. На мой взгляд, Вирт с ней справился лучше и раньше других.
Что касается Ады, справедливо упомянутой Cyberax'ом, то, при многих достоинствах, она слишком сложна и тяжеловесна.
В своей тьюринговской лекции Хоар просил не доверять такому сложному языку. (Я не случайно упоминаю Хоара. Он не только изобретатель быстрой сортировки, исследователь в области параллельного программирования, автор языка Оккам и ряда привычных уже нам конструкций языков программирования, вроде case ... of (он же switch). Его влияние на Вирта в области языков программирования было так велико, что его можно назвать "крестным отцом" Паскаля и последующих языков Вирта. )
Что касается Си++, то когда-то мне нравился этот язык. Пока в него не решили запихнуть все-все-все и еще чуть-чуть, а фундамент оставили прежним. К языку Си у меня больших претензий нет. Как "высокоуровневый ассемблер" он вполне хорош. А вот распространение Си++ во все области ПО (которое упомянуто у Страуструпа и поразило тебя) меня откровенно пугает. Представь себе, что над тобой нависает покосившийся небоскреб, практически лишенный фундамента.

E>Но ведь в C++ мне не нужно писать LocalSearch для разных случаях, он уже написан.

Иногда написание "обвески" для его вызова съедает больше...
Но главная моя претензия в данном случае все же состоит в том, что язык разбухает. Требуется знать все больше и больше (о все меньшем и меньшем ).
Уже и тривиальный цикл написать нельзя. Говорят: используйте стандартные алгоритмы. Т.е. их все надо помнить...

AVC>>Говоря о find_if, Вы запамятовали упомянуть о некоторых деталях.
AVC>>Во-первых, использование find_if предполагает использование итератора, причем привязанного как к типу элемента, так и к типу контейнера. Что-то вроде:
AVC>>

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

E>Ну и что? В случае с контейнерами итераторы уже реализованы. Но find_if можно использовать и с векторами:
E>

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>

Наверное, здесь имелся в виду find, а не find_if?
Думается, простой код

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

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

AVC>>Во-вторых, Вы почему-то ничего не сказали о таких мелочах, как написании класса предиката, наследовании от unary_function или binary_function и т.д.
E>Для многих стандартных алгоритмов, в том числе и для find_if, это не обязательно.

Это мелочь, но и здесь можно немного поспорить.
Все алгоритмы, чье имя заканчивается на _if, предполагают получить в качестве параметра предикат.
Рассмотрим в качестве примера одно из определений find_if (для компилятора GNU C++):

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;
}

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

AVC>>В-третьих, сколько всей этой ерунды надо помнить...
E>Да, вот с этим сложно спорить.

Ага, ага, я победил...

E>>>Кстати, есть ли для Modula и Oberon стандарт? ANSI или ISO?

AVC>>Для Модулы-2 есть стандарт ISO (уже давно).
AVC>>Именно поэтому в аэрокосмической сфере применяются в основном Ада и Модула-2 — языки, имеющие стандарты ISO.

E>По существование ISO стандартов для Модулы и Ада не знал, спасибо.
E>Хотя, думаю, причина использования в этих областях Ада и Модула-2 не в этом.
E>Да и Ада применяется только на Западе

Да, у нас пишут на Модуле-2.

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

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

AVC>Надо сказать, что наше общение не прошло для меня бесследно.


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

AVC>В связи с бедным Арианом, я задумался над тем, что такое ошибка в программе.
AVC>После чего совсем погрустнел. Даже кушаю плохо...

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

E>>>>Именно в этом задача и состояла -- нужно было повысить уровень абстракции.
AVC>Скажу только, что раньше полностью разделял твою точку зрения (что и претворял на практике; и что забавно — именно в матричных вычислениях).
AVC>А сейчас — с оговорками.

А с какими?

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

AVC>Что касается именно прогресса, то (ИМХО) не следует забывать, что приобретая что-то новое, мы также что-то и утрачиваем. И я не вижу никаких гарантий, что утраченное не окажется более ценным.

Ну что тут сделаешь. Се ля ви. Так было, так есть, так будет.
Это такая же объективная реальность, как и сложность C++

AVC>В отношении языков программирования наблюдается тенденция пренебрегать надежностью. Возможно, в пользу производительности, хотя подтверждающих это данных у меня нет. Наверное, пока мы остаемся в рамках офисных приложений, это экономически оправдано, т.к. цена ошибок и сбоев сравнительно невысока, а рост производительности может быть значительным (хотя это зависит и от организационных факторов).
AVC>Часто такой подход иллюстрируют таким примером: хотя автомобиль делает жизнь немного более опасной, люди пренебрегают этим риском ради дополнительных удобств (экономия времени, свобода передвижения и т.д.)

Тут хочется вспомнить анекдот в тему:

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

AVC>Но (ИМХО) было бы ошибочно переносить такой подход на все сферы жизни. Существует ряд отраслей (ядерная, военная и т.д.), чреватых глобальными катастрофами. Здесь приоритет следует отдать надежности, в том числе — надежности ПО. А надежность ПО включает в себя много составляющих, среди которых строгий контроль типов, простота языка и основанная на этом корректность компилятора играют далеко не последнюю роль.

С этим сложно спорить. Но широкоизвестные космические катастрофы, связанные с ошибками ПО, никак с этим не были связаны. Про Ариан мы уже долго говорим. Был еще старый случай с фортраном и запятой вместо десятичной точки (хотя этот пример и может попасть в данную категорию, если только все это было на самом деле). А ведь еще был случай с Mars Explorer (или как его там), когда разные модули вычисляли значения в разных системах счисления.

Кроме-то, здесь в форумах кто-то предъявлял статистику Ericsson о качестве ПО. Если мне не отшибает память, там оказалось, что средняя плотность ошибок составляет 3 штуки на 1000 строк кода. Вне зависимости от языка программирования!

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

Сейчас на наших глазах происходит интересное явление: острая конкуренция в языках программирования. С одной стороны, огромные финансовые вливания в Java и C#, с другой стороны -- Perl, Python, Ruby, PHP, да и старичек C++ сдаваться не собирается. Почему языки, лишенные мощной финансовой поддержки (т.к. Perl, Python, Ruby) успешно конкурируют с монстрами Java/C#? Имхо потому, что эти языки создавались для решения конкретных проблем. И развивались для решения других конкретных проблем. И выжили благодоря тому, что хорошо эти проблемы решали. Т.е. это реальные инструменты для реальных задач. Аналогично и с C++. Его необъятность и сложность проистекают из того, что он хорошо решает реальные задачи (было бы наоборот, его бы уже не было). Вот, например, я привел одну такую задачу, которую с помошью generic-ов Java и C# просто так не решить: А generic-и так могут?

Автор: eao197
Дата: 30.05.05

Если же брать Oberon, Modula-2, Smalltalk и др. оригинальные и интересные языки, то окажется, что универсальными они так и не стали. Действительно, за счет своих отличных (?) качеств они заняли доминирующее положение в той или иной нише. Но там они и остались. И в конкретной нише, скажем, в военной области, можно еще сравнивать C++ и Modula-2. Но если смотреть на язык программирования шире, то жизнь (или рынок, если быть точнее) уже доказали, что творения Вирта, какими бы гениальными они не были, для широкого применения не пригодны.

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

Кто говорит? Ну и пусть говорят
Чувство меры и здравый смысл еще никто не отменял.

AVC>Наверное, здесь имелся в виду find, а не find_if?

Да, это я ошибся.

AVC>Думается, простой код
AVC>

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

AVC>проще и понятнее.

Если он один (цикл этот), то да. Если их несколько, то нет. А дальше -- больше.
Оказывается, что если код развивается, то может оказаться, что a -- это больше не вектор, а list или даже set. Соответственно, цикл пришлось бы модифицировать. А обращение к find (find_if) нет.
Еще один вариант -- поиск должен поиметь side effect. В случае с циклом нам бы пришлось помещать в if() {...} дополнительную логику, которая может оказаться и не маленькой. В случае же с find_if эта логика может быть скрыта в предикате и не загромождать код основной процедуры.

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

Если только это до маразма не доходит.

AVC>>>Во-вторых, Вы почему-то ничего не сказали о таких мелочах, как написании класса предиката, наследовании от unary_function или binary_function и т.д.
E>>Для многих стандартных алгоритмов, в том числе и для find_if, это не обязательно.

AVC>Это мелочь, но и здесь можно немного поспорить.
AVC>Все алгоритмы, чье имя заканчивается на _if, предполагают получить в качестве параметра предикат.
AVC>Рассмотрим в качестве примера одно из определений find_if (для компилятора GNU C++):
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>

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

Когда я сказал, что предикат для find_if не обязательно должен быть производен от unary_function, то я имел в виду именно это. Насколько я помню, наследование от *_function становиться важным при использовании различных bind1st и bind2nd. Хотя я, например, предпочитаю наследоваться от unary_function по простым прозаическим причинам:

1. Когда я указываю в unary_function параметры шаблона, то получаю для них удобные псевдонимы argument_type и result_type. Это позволяет мне в коде предиката использовать короткое имя argument_type вместо, например, std::map< some_my_key_t, some_my_value_t >::value_type const &.

2. Я имею возможность сменить типа параметра для unary_function, но это не затронет кода предиката, т.к. там я пользуюсь псевдонимами argument_type и result_type.

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

AVC>>Надо сказать, что наше общение не прошло для меня бесследно.
E>
E>Ну да, одна надпись на стене чего стоит



AVC>>В связи с бедным Арианом, я задумался над тем, что такое ошибка в программе.
AVC>>После чего совсем погрустнел. Даже кушаю плохо...
E>Мн-да. На самом деле тема серьезная. Мне проще, я не пишу софт, от которого зависит чья-нибудь жизнь.

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

E>>>>>Именно в этом задача и состояла -- нужно было повысить уровень абстракции.
AVC>>Скажу только, что раньше полностью разделял твою точку зрения (что и претворял на практике; и что забавно — именно в матричных вычислениях).
AVC>>А сейчас — с оговорками.

E>А с какими?

Как-нибудь соберусь разобрать все это подробнее.
В основном, я вижу опасность в неявном применении переопределенных операторов.
Я уже приводил на форумах примеры "неадекватного" поведения Си++ в подобных случаях.

E>>>>>Так может тогда прогресс вообще остановить?
AVC>>>>А что такое прогресс?
E>>>Ну хотя бы создание того, что еще совсем недавно казалось невозможным.
AVC>>Что касается именно прогресса, то (ИМХО) не следует забывать, что приобретая что-то новое, мы также что-то и утрачиваем. И я не вижу никаких гарантий, что утраченное не окажется более ценным.
E>Ну что тут сделаешь. Се ля ви. Так было, так есть, так будет.
E>Это такая же объективная реальность, как и сложность C++

C++ действительно сложен.
Вопрос в том, насколько необходима, а насколько излишня такая сложность.

AVC>>В отношении языков программирования наблюдается тенденция пренебрегать надежностью. Возможно, в пользу производительности, хотя подтверждающих это данных у меня нет. Наверное, пока мы остаемся в рамках офисных приложений, это экономически оправдано, т.к. цена ошибок и сбоев сравнительно невысока, а рост производительности может быть значительным (хотя это зависит и от организационных факторов).
AVC>>Часто такой подход иллюстрируют таким примером: хотя автомобиль делает жизнь немного более опасной, люди пренебрегают этим риском ради дополнительных удобств (экономия времени, свобода передвижения и т.д.)

E>Тут хочется вспомнить анекдот в тему:
E>

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

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

AVC>>Но (ИМХО) было бы ошибочно переносить такой подход на все сферы жизни. Существует ряд отраслей (ядерная, военная и т.д.), чреватых глобальными катастрофами. Здесь приоритет следует отдать надежности, в том числе — надежности ПО. А надежность ПО включает в себя много составляющих, среди которых строгий контроль типов, простота языка и основанная на этом корректность компилятора играют далеко не последнюю роль.

E>С этим сложно спорить. Но широкоизвестные космические катастрофы, связанные с ошибками ПО, никак с этим не были связаны. Про Ариан мы уже долго говорим. Был еще старый случай с фортраном и запятой вместо десятичной точки (хотя этот пример и может попасть в данную категорию, если только все это было на самом деле). А ведь еще был случай с Mars Explorer (или как его там), когда разные модули вычисляли значения в разных системах счисления.

Да, был такой случай в 1999 году.
С Фортраном тоже был случай. Кажется, это было в нашем (еще советском) проекте в начале 1970-х.
Я не понимаю, почему ты полагаешь, что широкоизвестные катастрофы никак не связаны с надежностью языка.
Смотри сам.
В случае с циклом FOR в Фортране, просто очевидно, что большая доля вины — на языке.
В случае с Арианом, из-за недостаточности ресурсов целочисленную переменную не защитили от переполнения, что привело к отключению компьютера. Обращаю внимание, что игнорирование переполнения могло привести к еще худшим последствиям. В области безопасности программа должна быть корректна на 100%. 99% недостаточно!
Из-за недостаточности ресурсов выбрали неадеватный тип данных для представления horizontal bias.
В случае с потерей орбиты Марса, если бы вычисления, связанные с разными единицами измерения, относились к разным типам, то ошибку, скорее всего, удалось бы предотвратить, т.к. потребовалось бы явное приведение типов.
Т.е. напротив, трудно назвать случай не связанный с языком (или нарушением его правил)!

E>Кроме-то, здесь в форумах кто-то предъявлял статистику Ericsson о качестве ПО. Если мне не отшибает память, там оказалось, что средняя плотность ошибок составляет 3 штуки на 1000 строк кода. Вне зависимости от языка программирования!

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

E>Сейчас на наших глазах происходит интересное явление: острая конкуренция в языках программирования. С одной стороны, огромные финансовые вливания в Java и C#, с другой стороны -- Perl, Python, Ruby, PHP, да и старичек C++ сдаваться не собирается. Почему языки, лишенные мощной финансовой поддержки (т.к. Perl, Python, Ruby) успешно конкурируют с монстрами Java/C#? Имхо потому, что эти языки создавались для решения конкретных проблем. И развивались для решения других конкретных проблем. И выжили благодоря тому, что хорошо эти проблемы решали. Т.е. это реальные инструменты для реальных задач. Аналогично и с C++. Его необъятность и сложность проистекают из того, что он хорошо решает реальные задачи (было бы наоборот, его бы уже не было). Вот, например, я привел одну такую задачу, которую с помошью generic-ов Java и C# просто так не решить: А generic-и так могут?

Автор: eao197
Дата: 30.05.05

Спасибо за действительно интересный пример!
Постараюсь его обдумать.
Конечно, сразу ясно, что возникшую проблему ты решил за счет специализации шаблонов.
Т.е. в "сердцевине" решения что-то вроде:

#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;
}

Для стимулирования воображения, хотелось бы (если можно) увидеть маленький кусочек клиентского кода.
Т.е. я все примерно представляю, но в последнее время я мало доверяю своим "беглым мыслям". Стар стал, воображение уже не то...
Также ясно, что твоя жизнь оказалась бы гораздо приятнее, если бы Visual C++ 6.0 соответствовал стандарту.
Обошелся бы без "сверхплановых" наворотов.
(Однако, обращаю твое внимание, что ситуация с Visual C++ 6.0 косвенно связана с чрезмерной сложностью языка. Если уж такая фирма оказалась не в состоянии вовремя представить компилятор, соответствующий стандарту.)
Думается, что, на настоящий момент, generic-и на такое неспособны. (Правда, я мог отстать от жизни в своем захолустье. )
Но, будем справедливы, generic-и действуют в других обстоятельствах.
ИМХО, такие удобства достались Си++ далеко небесплатно.
Си++ расчитан на "старую" модель монолитной (stand-alone) программы.
Отсюда — трудности с компонентным программированием, чрезмерные навороты с COM и т.д.
Грубо говоря, Си++ — доживший до наших времен динозавр.
У динозавров несомненно были свои преимущества и особые эволюционные приспособления.
Но они вымерли. Все, кроме Си++.
Другой подход, более "современный" (конечно, все относительно) был реализован в Обероне еще в середине 1980-х.
Там вообще нет монолитных программ. (Разумеется, вне обероновской среды компиляторы предоставляют возможность создания и обычных exe-шек.)
Процесс инициируется не загрузкой программы, а вызовом команды (экспортируемой модулем процедуры).
Модули подгружаются автоматически, если они указаны в списке импорта загружаемого модуля (и не были загружены раньше).
При этом компонентное программирование получается просто само собой — и совершенно бесплатно. Просто пишешь свой модуль, и ни о чем плохом не думаешь.
Нет нужды читать умные книги, с названиями вроде "Сущность технологии COM". (Книга неплохая, но даже в ней написано, что COM возник из-за неспособности Си++ поддержать компонентное программирование напрямую. Т.е. на одну кучу избыточной сложности уже громоздится другая.)
Компонентная модель потребовала дополнительной безопасности типов (поэтому в Обероне, если не указывать в списке импорта SYSTEM, с переменной можно обращаться только в соответствии с его типом) и централизованной сборки мусора, что, кстати, является дополнительным удобством для программиста.
Через десяток лет возникла Java, через полтора — С# и .NET. Основные идеи были заимствованы из Оберона. Как принято в мире языков с Си-подобным синтаксисом — неявно .

E>Если же брать Oberon, Modula-2, Smalltalk и др. оригинальные и интересные языки, то окажется, что универсальными они так и не стали. Действительно, за счет своих отличных (?) качеств они заняли доминирующее положение в той или иной нише. Но там они и остались. И в конкретной нише, скажем, в военной области, можно еще сравнивать C++ и Modula-2. Но если смотреть на язык программирования шире, то жизнь (или рынок, если быть точнее) уже доказали, что творения Вирта, какими бы гениальными они не были, для широкого применения не пригодны.

Как говорится, "не говори квак, пока не прошел ВАК".
Что там доказала жизнь, судить рано.
На все требуется время.
Оберон — почти ровесник Си++. ИМХО, Си++ был принят (хотя и он популярным стал только в 90-х) "программистскими массами", потому что давал дополнительные удобства (много дополнительных удобств и... неудобств ) на основе старой модели, прочно засевшей в головах программистов.
Оберон же, видимо, опередил свое время. Но теперь (с таким опозданием!) эти идеи стали воплощаться в других языках и системах, уже пользующихся поддержкой "рыночных акул". Да и "старичок" Оберон не окончил еще свой земной путь.
Здесь же и Компонентный Паскаль, и пользующаяся поддержкой Microsoft новый член обероновского семейства языков — Zonnon.

AVC>>Но главная моя претензия в данном случае все же состоит в том, что язык разбухает. Требуется знать все больше и больше (о все меньшем и меньшем ).
AVC>>Уже и тривиальный цикл написать нельзя. Говорят: используйте стандартные алгоритмы. Т.е. их все надо помнить...
E>Кто говорит? Ну и пусть говорят
E>Чувство меры и здравый смысл еще никто не отменял.

Глядя на Страуструпа, я уже этого сказать не могу.

AVC>>Думается, простой код
AVC>>

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

AVC>>проще и понятнее.

E>Если он один (цикл этот), то да. Если их несколько, то нет. А дальше -- больше.

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

E>Оказывается, что если код развивается, то может оказаться, что a -- это больше не вектор, а list или даже set. Соответственно, цикл пришлось бы модифицировать. А обращение к find (find_if) нет.

Ну, по крайней мере, приведенный тобой пример с массивом точно уж пришлось бы модифицировать.
В массиве Си++ никаких begin() и end() нет.
А если добавить, что компилятор Си++ помнит о массиве только в области его определения...

E>Еще один вариант -- поиск должен поиметь side effect. В случае с циклом нам бы пришлось помещать в if() {...} дополнительную логику, которая может оказаться и не маленькой. В случае же с find_if эта логика может быть скрыта в предикате и не загромождать код основной процедуры.

А что, в цикле использовать предикат запрещено?

AVC>>Но если уж начал применять STL, то, конечно, надо применять его везде — для выработки автоматизма.
E>Если только это до маразма не доходит.

Ну, тогда применять вообще не надо.

AVC>>>>Во-вторых, Вы почему-то ничего не сказали о таких мелочах, как написании класса предиката, наследовании от unary_function или binary_function и т.д.
E>>>Для многих стандартных алгоритмов, в том числе и для find_if, это не обязательно.

AVC>>Это мелочь, но и здесь можно немного поспорить.
AVC>>Все алгоритмы, чье имя заканчивается на _if, предполагают получить в качестве параметра предикат.
AVC>>Рассмотрим в качестве примера одно из определений find_if (для компилятора GNU C++):
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>>

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

E>Когда я сказал, что предикат для find_if не обязательно должен быть производен от unary_function, то я имел в виду именно это. Насколько я помню, наследование от *_function становиться важным при использовании различных bind1st и bind2nd. Хотя я, например, предпочитаю наследоваться от unary_function по простым прозаическим причинам:
E>1. Когда я указываю в unary_function параметры шаблона, то получаю для них удобные псевдонимы argument_type и result_type. Это позволяет мне в коде предиката использовать короткое имя argument_type вместо, например, std::map< some_my_key_t, some_my_value_t >::value_type const &.
E>2. Я имею возможность сменить типа параметра для unary_function, но это не затронет кода предиката, т.к. там я пользуюсь псевдонимами argument_type и result_type.

Боже мой, как все-таки облегчили труд программиста в последнее время!
Я бы сказал, налицо все признаки прогресса.

Здравствуйте, AVC

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

Хотя, мне кажется, что в некоторых ветвях данного топика, в частности, в той, в которой мы сейчас общаемся, разговор пошел гораздо серьезнее священных войн. Жалко, что мы в дебрях этой ветви прячемся, а то мог бы еще кто-нибудь подключиться.
Уважаемые модераторы, нельзя ли нас (вот отсюда: Re[16]: Почему настоящие программисты избегают C++

Автор: eao197
Дата: 05.06.05

) в "Философию программирования" переместить?

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

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

Взаимно!

E>Хотя, мне кажется, что в некоторых ветвях данного топика, в частности, в той, в которой мы сейчас общаемся, разговор пошел гораздо серьезнее священных войн. Жалко, что мы в дебрях этой ветви прячемся, а то мог бы еще кто-нибудь подключиться.
E>Уважаемые модераторы, нельзя ли нас (вот отсюда: Re[16]: Почему настоящие программисты избегают C++

Автор: eao197
Дата: 05.06.05

) в "Философию программирования" переместить?

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

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

E>В качестве примера -- катастрофа Ариан 5 при старте, тогда из-за ошибок программистов не было перехвачено исключение и софт просто вырубился, как на основной, так и на резервной системе контроля. <SKIP>

IMHO катастрофа Ариан 5(если ты конечно об этом http://www.osp.ru/os/1998/06/21.htm) — чисто конфигурационная проблема, не зависящая от ярыка программирования.

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

Проблема не в языках а в головах

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

AVM>Проблема не в языках а в головах

Вот именно это я и подразумевал.

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

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

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

AVC>>>Весь смысл высокоуровневости — позволить компилятору гарантировать определенные свойства программ, например — безопасность типов (type safety).
AVC>>>С моей стороны это вовсе не эстетская критика.
AVC>>>Я полагаю, что только прирожденный душегуб согласится писать сложное ПО, отвечающее за безопасность людей, на низкоуровневых языках, подобных Си и Си++.

E>>Что-то в этой ветке часто упоминается, что есть языки, в которых выход за пределы массива четко и точно отлавливается в run-time. И говорится, что это круто, и что из-за отсутствия таковой возможности C/C++ must die!

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

Эта разговоры продолжаются с года с 1985-ого, когда вышли первые более менее нормальные компилятор и описание...
На моей памяти, начиная с 1997 года, эти это уже 3-яя волна подобных "похорон" языка.
А вот что-то не умирает он и до сих пор носится по двору без башки... Или даже я сказал бы так — одну отрубили, а 2 выросло...

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

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

К вопросу о падающих космических аппаратах, языках программирования и статической типизации:

http://www.flownet.com/gat/jpl-lisp.html, в разделе "1994-2000 — Remote Agent"

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, Вы писали:

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.

Очень интересно, что все участники дискуссии полностью проигнорировали этот фрагмент отчета. Собственно, ничего удивительного в этом нет, это типичное заблуждение, которое заключается в том, что ПО можно сделать свободным от дефектов и предусматривать какие-то меры восстановления от программных сбоев нет необходимости. И это-то при том, что именно программные ошибки занимают второе место среди причин отказов информационных систем (первое место — cockpit failure), а аппаратные сбои только на третьем.

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

Ссылка по теме: диссертация Joe Armstrong'а на тему "Making reliable distributed systems in the presence of software errors" (здесь)