Итак. Пример прост: фортрановская программа вызывает статическую библиотеку на C. Всё сделано в VisualStudio 2003/2005 и Intel Fortran 10.1. По субъективным впечатлениям - g95+gcc работают гораздо удобнее, но оптимизация кода ниже. Да и не родные это для Windows компиляторы. Так что смотрите, кому интересно

Исходник библиотеки


Исходник модуля с интерфейсами к библиотеке



И сама вызывающая программа


P.S. пора бы всё же фортрановский код подсветить
P.S.S кстати, интересный способ предлагает Silverfrost Fortran для связывания с C. Удобный, но не стандартный. Объявление C_EXTERNAL

Например для

Обратите внимание - результат объявляется по-фортрановски, а в скобках указывается - по ссылке или по значению передавать аргумент.
Довольно удобно.

Это сообщение отредактировал(а) popovda - 15.10.2009, 22:26

Присоединённый файл ( Кол-во скачиваний: 5 )
 F_call_C.rar 483,93 Kb

Интересно, а как компилятор Фортрана определяет, что второй аргумент showArray - это указатель именно на double, а не на что-то другое? Или сейчас это уже не имеет значения?

Вот это и мне интересно Тем более, что стандарт допускает передачу массива определенной длины в C-функцию не только как type(c_ptr), но и именно как массив, передаваемый по ссылке. Интеловцы, судя по всему, не доработали. Так же похоже, что используется неявное приведение типа. Вроде такой логики компилятора: "раз пользователь передаёт массив типа real(8) в функцию, то ответственность, что в C это именно real(c_double) == double лежит на самом пользователе и на C". Причём, для обратной операции, например получения адреса первого элемента массива, используется функция C_F_POINTER, которая приводит указатель с к указателю Фортрана.

Следует заметить, что в g95 передача массива как массива (естественно, без атрибута value) так же работает. 

С другой стороны, что тут кто должен проверять? Интересно, а так сработает:


Тут не вопрос: из описателя Fortran вытаскивается указатель и передаётся в С-функцию.

Возможно, я не так понял. Если С ловит double и интерфейс на Fortran написан doiuble, то проверять ничего не нужно. А вот если программист ошибется и напишет в Fortran другой тип, то по идее должна срабатывать ошибка при компоновке! Должна. Вся эта информация должна хранится в *.lib.

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


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

Да. Вроде бы так. Но с массивом подразумеваемой длины 10-ый интел у меня страшно кочевряжился и не заработал. g95 этот же код съел. Так что я в легком затруднении 

[code]
! Для void showArray(const int sz, double Arr[])
    subroutine ShowArray(sz, Arr) bind(C,name = "showArray")
        use, intrinsic :: iso_c_binding;
        
        integer(c_int), value, intent(in) :: sz;
        type(c_ptr), value, intent(in) :: Arr;
[\code]

Что до интерфейса - пользователь передаёт в C-функцию указатель type(C_PTR), и это всего лишь указатель, целое число. А целое - оно всегда целое. 

P.S. Точка с запятой - привычка из C. И Ады. Лучше я буду их и фортране ставить - это не вызывает ошибки, чем я буду забывать их ставить в C и тем более Аде. 

С x86 понятно - здесь указатели на все типы совпадают (даже если вспомнить про сегменты, которые несколько нарушают идею, что указатель = целое число). Меня интересовали другие архитектуры. В стандарте C явно оговаривается, что, например, (void*) и (double*) могут иметь разный размер и разное внутреннее представление. Отсюда и вопрос - как Фортрану указать вид указателя, принимаемого программой на C?

Кстати, на форуме Intel мне указали на ещё одну проблему - если, например, в структуре указать атрибут sequence, то некоторые данные C не правильно будет интерпретировать, например, у меня так было с символами. Дутчик категорически не рекомендовал использовать его при межъязыковом программировании. Если не изменяет память, Бартеньев, как раз наоборот, - рекомендовал.