Здравствуйте, 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# -- это темпера (хотя сам не пробовал, только читал) -- вроде почти тоже, что и масло, но ярче и сохнет быстрее, разводится простой водой, менее требовательна к поверхности. Но вот с полутонами и полупрозрачными слоями там беда, до масла далеко.