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

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