Здравствуйте, 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. А потом уже менять не хотелось, чтобы почта не терялась
И не нужно меня обвинять в "сухости" и прагматизме -- я ведь не художник, а программист