Имеет ли смысл менять Fortran на C++?

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

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

Сравнить два языка не могу, потому что Фортран не знаю даже в общих чертах :-/

> Начинаю программировать по текущему проекту.
>Может все это не стоит усилий, а главное -- понизит производительность?

Может и не стоит ...
Зависит от наличия ресурса времени и самой задачи - смотреть по месту тут надо.

Смени лучше на что-нибудь функциональное, Haskell например. Там и ленивые вычисления, и функторы, и абстракции непротекающие. Особенно если проект относится к вычислениям (судя по фортрану).

На плюсы - однозначно не стоит.

Ни в коем случае.

C++ программеров ("быдлокодеров", "место которым в дурке или на погосте" (с) VSL) как собак нерезаных. А вот фортран-девелоперы - это экзотика.

Кстати, олдфаги мне доказывали, что с матричными операциями в Фортране все намного более рационально, нежели в C++.

И форматированный вывод в фортране намного проще и удобнее

А вообще жутко принципиальной разницы между ними нет, особенно если пишется вычислятор, которому не нужен винсок и прочая лабуда

Люди на работе начинали писать наш проект на фортране лет десять назад и сейчас сильно рады что тогда свалили на плюсы. Говорят удается лучше структурировать код.

Насчет потери скорости - imho полный бред, т.к. современные компиллеры и в плюсах найдут векторность если она есть в коде.

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

Грубо говоря если ты пишешь один конкретный расчет для диплома на пару месяцев - мигрировать врядли стоит. Если пишешь кад с коммандой плюсистов и планируете развиваться лет 10 - имеет смысл задуматься.

Хренасе, какие мамонты среди нас обитают.

>Если пишешь кад с коммандой плюсистов и планируете развиваться лет 10 - имеет смысл задуматься

... о смене работы!

> компилирую gfortran, но пишу на чем-то больше напоминающем 77

А не лучше ли тогда использовать проверенный g77 вместо недопиленного gfortran?

Fortran 77 вполне себе вменяемая вещь, в отличии от FORTRAN IV (ЖЕСТКАЯ ЖЕСТЬ).
Если задача числодробилка, то фортран лучше. Если тебе гуй рисовать, то фортран в сторону... Ну и так далее. От задачи зависит. Хотя, на мой взгляд, Си прирлюснутый еще та шняга. :( Если бы мне пришлось выбирать, то скорее фртран, хотя, если приснится FORTRAN IV, буду кричать во сне. Был опыт. Как-то искал косяк в чужой программе. COMMON блоки и вычисляемое GOTO..... АААААААААААААААААААААААААААААААаааааааааааааааа..........
Кончилось тем, что переписал всю заново.

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

Если все библиотеки фортрановские, то смысла нет. Если C++ные, то смысл есть.

Zavisit ot zadachi, no, naprimer, matrichno-vectornye operatsii v F90 est' is korobki, taklzhe, kak i dinamicheskaya pamiat'. I na samom dele F90 priyatnyi yazyk. Dlia vychislite'nyh zadach v tselom Fortran podhodit bol'she. Tak chto luchshe promeniat' F77 na F90.

Стоит, код получается более читабельным и структурированным. Понижения производительности не будет. Если используются фортрановские бибилиотеки lapack/arpack/blas, то их можно использовать и в C++.

Язык без структур вот это шняга допотопная. Когда состояния хранят в массивах и передают в функции 20 аргументов вместо одной структуры вот это жесть.

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

Вот для затравки работающий параллельный Си код 
умножения разреженной матрицы на вектор слева. 
Интересно посмотреть тоже самое на Хаскеле.

#pragma omp parallel for
        for (j = 0; j < n; ++j) {
                double *p = &A->Ax[A->Ap[j]];
                int i0;
                r[j] = 0;

                for (i0 = A->Ap[j]; i0 < A->Ap[j + 1]; ++i0, ++p) {
                        int i = A->Ai[i0];
                        r[j] += *p * x[i];
                }
        }

шагай в ногу с прогрессом, переходи сразу на COBOL!

> Язык без структур вот это шняга допотопная.

Структуры в Fortran были ещё с семидесятых годов как расширения к стандарту. В современных версиях оно есть из коробки.

> Когда состояния хранят в массивах и передают в функции 20 аргументов вместо одной структуры вот это жесть.

Откройте для себя блоки COMMON

В общем вы, как обычно, не шибко в теме.

Как-то так.

-- Multiplying vectors
(ax, ay, az) `vx`  (bx, by, bz) = (ay * bz - az * by, az * bx - ax * bz, ax * by - ay * bx)

-- Multiplying matrix and vector (left version)
m `mxv` v = map (vx v) m

Бенчмарки пока не проводил.

Алсо, для операций с матрицами в Haskell есть специальные библиотеки с биндингами к тому же lapack.

99% фортрановских библиотек написано на fortran 77 и ничего этого там нет.

А если потребуется что-то нестандартное, то библиотеку придется писать под себя на более нормальном языке ? Тогда зачем нужен этот хаскель ?

> 99% фортрановских библиотек написано на fortran 77 и ничего этого там нет.

а) эти библиотеки уже написаны

б) сейчас нет необходимости писать так же

в) кроме g77 есть и другие компиляторы

Похоже на какую-то чушь. Конечно понятно, что умножение матрицы на вектор можно представить как n скалярных произведений, но то, что "Multiplying vectors" выполняет именно это у меня большие сомнения.

> Бенчмарки пока не проводил.

И без них ясно кто кого.

> б) сейчас нет необходимости писать так же

Расскажи это ученым, с которыми я работаю.

> в) кроме g77 есть и другие компиляторы

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

>> б) сейчас нет необходимости писать так же

>Расскажи это ученым, с которыми я работаю.

Это просто на просто означает, что они лучше вас понимают, что на самом деле важно. Мне лично совершенно параллельно на каком языке написать программу на fortran :) - хоть на perl, хоть на C++

>> в) кроме g77 есть и другие компиляторы

>gfortran появился недавно и даже не все в курсе что он есть и по инерции пользуются g77. На что-то более платное в наших научных организациях денег нет.

Значит нет особой необходимости в этом. Если это раздражает как-то особо, то имеет смысл подготовить и провести ликбез, где демонстрируются полезные нововведения. 80% проблем при взаимодействии решаются с помощью простых договорённостей и общих правил.

Основные проблемы не в языке и не в структурах - 99% проблем сидит в предметной области.

> Zavisit ot zadachi, no, naprimer, matrichno-vectornye operatsii v F90 est' is korobki, taklzhe, kak i dinamicheskaya pamiat'. I na samom dele F90 priyatnyi yazyk. Dlia vychislite'nyh zadach v tselom Fortran podhodit bol'she. Tak chto luchshe promeniat' F77 na F90.

+1

посмотреть на Fortran 90 и компилятор от Intel стоит в первую очередь, а потом уже сравнить с C++

> Если это раздражает как-то особо, то имеет смысл подготовить и провести ликбез, где демонстрируются полезные нововведения. 80% проблем при взаимодействии решаются с помощью простых договорённостей и общих правил.

Раздражает только в сложных случаях, когда void * из Си попадает в Integer в фортране, и приходится часами искать почему же на 32х битах все работает, а на 64х необъяснимые сегфолты. В остальных случаях пишется обертка к фортрану и про страшные 20 параметров в функциях и отстутствие структур можно временно забыть. А переучивать кого-то смысла нет.

> А если потребуется что-то нестандартное, то библиотеку придется писать под себя на более нормальном языке?

Если в библиотеке не находится нужного, библиотека расширяется / пишется своя. В Си и Фортране все не так?

Писать библиотеки можно на чем угодно.

> Тогда зачем нужен этот хаскель?

Чтобы писать понятные программы, а не мозгоебстись с указателями, как в примере выше.

> Похоже на какую-то чушь. Конечно понятно, что умножение матрицы на вектор можно представить как n скалярных произведений, но то, что "Multiplying vectors" выполняет именно это у меня большие сомнения.

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

> А переучивать кого-то смысла нет.

Я же говорю: набор простых правил, договорённостей, а так же автоматический Makefile для сборки библиотек решит 80% проблем.

какое умножение из 3-х, мой юный падаван? не верь википедии -- путь лёгекий на тёмную сторону есть это.

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

бугага, валяюсь под столом ...... бугагагагагагааааа, всё, вопросов про хаскель и линейную алгебру больше не имею

http://translit.ru >Зависит от задачи, но, например, матрично-вецторные оператсии в Ф90 есть ис коробки, таклже, как и динамическая памиать. И на самом деле Ф90 приятныи язык. Длиа вычислитеьных задач в тселом Фортран подходит больше. Так что лучше промениать Ф77 на Ф90.

> а так же автоматический Makefile для

постепенно искореняю этого динозавра в пользу cmake

> сборки библиотек решит 80% проблем.

ага, правда с cmake решаются 90% проблем :)

Смотря какая задача

Вместо того чтобы валяться под столом, дал бы ссылку на правильный алгоритм, глядишь, просвещусь.

например, вот http://www.inm.ras.ru/vtm/lection/all.pdf

> постепенно искореняю этого динозавра в пользу cmake

Без разницы что - главное чтобы _работало_ для всех.