0

I'm working on a small Fortran library (novel code) which is being called from several C/C++ applications. The library is of such kind when almost every subroutine could be separately called from application. So I need to provide C interface for those subroutines.

  • I can use modules, which are very comfortable by itself. But then I need either to decode manually module name mangling (which isn't very hard for gfortran, but looks bad) or use bind(C,name="some_name") clause. The last one leads to compiler warnings like subroutine parameter wasn't explicitly made interoperable (so compiler wants me to replace double precision with real(kind=C_DOUBLE), for example). And I should in this case to replace almost every variable in a library with such ugly declarations, which results to bad-reading code.
  • I can use subroutines, when every file in a library consists of several subroutines (this is the way that I do now). Explicitly interfaces are fed between them with interface ... include "otherfile_h.f90" ... end interface which isn't very comfortable. Name mangling is rather simple in this case, and library subroutines could be easily directly called from C.

The approach that I use (bullet #2) requires more typing and it is error prone because of duplicating definitions in source/header files. Is there a better way to keep sources clear and readable with smart C interface?

Yury
  • 3,000
  • 2
  • 24
  • 24
  • I don't understand the use of the term 'comfortable' with regard to choosing between one approach to programming and another. I suspect that it refers to software factors which are subjective and arguable, which therefore rules this question unacceptable here on SO. If I have misconstrued your intention, please clarify. – High Performance Mark Jul 03 '12 at 08:18
  • @HighPerformanceMark Agree, reformulated my question. – Yury Jul 03 '12 at 10:00
  • 3
    I still think this question raises issues of opinion and of taste. I, for example, think that `real(kind=C_DOUBLE)` is perfectly readable and my 'answer' to your question *Is there a better way ...* is *No.* I'd go further and state that programming IN the language rather than programming AROUND the language is the way to happiness, fulfilment and success. But note that this is just commentary I don't offer an answer. – High Performance Mark Jul 03 '12 at 10:09
  • @HighPerformanceMark Actually I'm foremost C/C++ programmer, and I don't know conventional Fortran practices regarding this case. So if the answer is *use kind=C_DOUBLE, because I have a big experience with such code, and it is perfectly readable*, it is probably acceptable answer. – Yury Jul 03 '12 at 10:16

1 Answers1

2

The modern way to mix Fortran and C is to use Fortran's ISO C Binding. This will make your code portable since the ISO C Binding is part of the language standard. Manually figuring out the name mangling is compiler specific and might not work on another compiler. "Double precision" is not considered a best practice declaration for modern Fortran (see, e.g., Extended double precision and http://fortranwiki.org/fortran/show/Modernizing+Old+Fortran). The modern way is to use "real (kind=XYZ)". The concept of the language is that typically the programmer uses SELECTED_REAL_KIND intrinsic function to define an constant (e.g., MyDouble) for the precision that they need. If the precision that you need is C_DOUBLE, then it is very appropriate Fortran to use that kind value. This is not an ugly declaration. (I don't understand your bullet #2.)

Community
  • 1
  • 1
M. S. B.
  • 28,968
  • 2
  • 46
  • 73