По поводу ООП, но на делфи 7
расчетная задача - определение пересечений двухмерных линий и их расположение на плоскости, все линии в динамических массивах. почти типичный пример для ООП: объект, набор свойств, операции над объектами (переместить , положить, повернуть, проверить пересечение). когда убрали ооп и перешли на процедуры не меняя алгоритмов ускорение расчетов получилось около 2 раз. это цена ооп в расчетной задаче. дальше можно говорить что делфи кривое, программа кривая и т.л. но ясно, что цена за ооп не 1-2%.

Ну все-таки ООП бывает разным. Для такой задачи хорошо подошла бы библиотека CGAL, она вся построенна на ООП и generic programming. Думаю у них все очень даже оптимально получается.  А с процедурным подходом вряд ли можно сильно быстрее сделать, а все алгоритмы придется или дублировать, или в макросы заворачивать. Так что, может действительно, не всякое ООП стоит использовать для рассчетных задач...

В стандарте 2003 есть ассинхроный ввод-вывод. Потом, никто не говорит, что использование API плохо. Но всё хорошо в меру. И там, где возможно, я предпочитаю пользоваться только средствами Стандарта языка. Для переносимости. 


В отношении ООП: Смотря какие накладные расходы. Везде нужно грамотное проектирование. И, конечно, многое зависит от задачи. Но, поработав, с ООП в тех его объемах, что реализованы в NAG Fortran 5.1, я убедился в том, что там принят удобный и сбалансированный подход к ООП. С одной стороны в нём нет наворотов, а с другой - всё нацелено на максимальную скорость разработки и выполнения кода. Причём, концепция самого ООП такова, что сильная модификация кода по сравнению с элементами ООП на основе Ф95 (инкапсуляция на уровне модуля, статический полиморфизм и т.п.) не требуется. Потом, для математика в фортране есть одна классная черта - возможность ввести собственные операторы. Это очень удобно для многих вещей - естественность записи повышается.

Это сообщение отредактировал(а) popovda - 2.7.2008, 20:12

Очень много неподкреплённых высказываний.

Те, кто говорит про оптимизацию в С/С++, читайте, зачем вводился квалификатор restrict.

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

Недостаток ООП -- возможности писать плохопроизводительные программы.

Фрагментация памяти.

Некоторые виды оптимизаций невозможно проводить на языках с указателями, т.к. на этапе компиляции невозможно установить независимость участков памяти. Allocatable ввели в частности для такой гарантии. Это позволяет делать автовекторизацию у повышать производительность такого участка в 3.х раз для одинарной точности.

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

• "Птичность" языка:
  

  Код

  }             }         }     }

  
  Не понятно, что к чему относится, если нужно добавлять.
• Указатели. Подводные камни и невозможность автоматических векторных оптимизаций. restrict не только даёт возможность автовекторизации, но и даёт гарантию независимости на откуп программисту. ещё одна неявная "фигня".
• Сборщик мусора. Молчу. Все преимущества и недостатки многим известны.
• Отсутсвие ссылок = отсутсвие описателей на массивы = отсутсвие проверки массивов = отсутствие регулярного программирования.
• Следование собственным стандартам по представлению чисел с плавающей точкой. для понта. Приводит к несовместимости с надёжными вычислениями.
• Управляемость кода. Отсутсвие полной оптимизации под архитектуры и автоматической диспетчерезации для семейства процессоров.

!  Cr@$h

Тему закрываю. Одна тема -- один вопрос!

Это сообщение отредактировал(а) Cr@$h - 20.1.2009, 09:44