Перехват Fortran STOP от переполнения стека

Так как то, что вы хотите, в любом случае приведет к непереносимому коду, почему бы просто не разрушить механизм выхода, используя неясный механизм длинного перехода:

#include<iostream>
#include<csetjmp>
#include<cstdlib>

// prototype for the external Fortran subroutine
extern "C" {
void fsub(double* x);
}

volatile bool please_dont_exit = false;
std::jmp_buf jenv;

static void my_exit_handler() {
if (please_dont_exit) {
std::cout << "But not yet!\n";
// Re-register ourself
std::atexit(my_exit_handler);
longjmp(jenv, 1);
}
}

void wrapped_fsub(double& x) {
please_dont_stop = true;
if (!setjmp(jenv)) {
fsub(&x);
}
please_dont_stop = false;
}

int main() {
std::atexit(my_exit_handler);
double x;
while(std::cin >> x) {
wrapped_fsub(x);
}
return 0;
}

призвание longjmp прыгает прямо в середине строки с setjmp позвонить и setjmp возвращает значение, переданное в качестве второго аргумента longjmp, Иначе setjmp возвращает 0. Пример вывода (OS X 10.7.4, GCC 4.7.1):

$ ./a.out
2
2.0000000000000000
6
STOP x >=5 : this kills the program
But not yet!
7
STOP x >=5 : this kills the program
But not yet!
4
4.0000000000000000
^D
$

Предварительная загрузка библиотеки не требуется (что в любом случае в OS X является более сложным, чем в Linux). Предупреждение: обработчики выхода вызываются в обратном порядке их регистрации. Следует быть осторожным, чтобы никакие другие обработчики выхода не регистрировались после my_exit_handler,

Объединяя два ответа, которые используют пользовательский _gfortran_stop_string функция и longjmpЯ думал, что вызов исключения внутри пользовательской функции будет аналогичным, а затем будет реализован в основном коде. Итак, это вышло:

main.cpp:

#include<iostream>

// prototype for the external Fortran subroutine
extern "C" {
void fsub(double& x);
}

int main() {
double x;
while(std::cin >> x) {
try { fsub(x); }
catch (int rc) { std::cout << "Fortran stopped with rc = " << rc <<std::endl; }
}
return 0;
}

catch.cpp:

extern "C" {
void _gfortran_stop_string (const char*, int);
}

void _gfortran_stop_string (const char *string, int len)
{
throw 666;
}

Затем компилируем:

gfortran -c fmodule.f90
g++ -c catch.cpp
g++ main.cpp fmodule.o catch.o -lgfortran

Бег:

./a.out
2
2.0000000000000000
3
3.0000000000000000
5
Fortran stopped with rc = 666
6
Fortran stopped with rc = 666
2
2.0000000000000000
3
3.0000000000000000
^D

Итак, похоже на работу 🙂

Я предлагаю вам разветвить свой процесс перед вызовом кода Фортрана и выйти из 0 (правка: если STOP завершается с нуля, вам понадобится код выхода дозорного, неуклюжий, но делает работу) после выполнения Фортрана. Таким образом, каждый вызов на Фортране завершается так же, как если бы он прекратился. Или, если «STOP» выдает ошибку, сгенерирует исключение, когда код фортрана останавливается, и отправляет какое-то другое сообщение, когда выполнение фортрана «завершается» нормально.

Ниже приведен пример, вдохновляющий ваш код, предполагая, что Fortran «STOP» является ошибкой.

 int main() {
double x;
pid_t pid;
int   exit_code_normal = //some value that is different from all STOP exit code values
while(std::cin >> x) {
pid = fork();
if(pid < 0) {
// error with the fork handle appropriately
} else if(pid == 0) {
fsub(x);
exit(exit_code_normal);
} else {
wait(&status);
if(status != exit_code_normal)
// throw your error message.
}
}
return 0;
}

Код выхода может быть константой вместо переменной. Я не думаю, что это имеет большое значение.

После комментария оказывается, что результат выполнения будет потерян, если он будет храниться в памяти процесса (а не, скажем, записывать в файл). Если это так, я могу думать о 3 возможностях:

• Код Фортрана теряет много памяти во время вызова, и, во-первых, позволить продолжить выполнение после STOP, вероятно, не очень хорошая идея.
• Код fortran просто возвращает некоторое значение (через аргумент, если мой fortran не слишком ржавый), и это может быть легко передано родителю через разделенное пространство памяти.
• Выполнение подпрограммы fortran действует во внешней системе (например, запись в файл), и никаких возвращаемых значений не ожидается.

В третьем случае моё решение выше работает как есть. Я предпочитаю его другим предлагаемым решениям, главным образом потому, что: 1) вам не нужно гарантировать, что процесс сборки поддерживается должным образом 2) fortran «STOP» по-прежнему ведет себя как положено, и 3) ему требуется очень мало строк кода и все » Фортран СТОП обходной путь «логика сидит в одном месте. Так что с точки зрения долгосрочного обслуживания, я предпочитаю это.

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

В 1-м случае вам придется возиться с кодом Фортрана, несмотря ни на что.