Converting Fortran source to C++ Source

manoharbalu

We have 5 to 6 Fortran Libraries each of which contains at least 60 to 70 fortran source files (.for). These libraries are linked in an application developed in PASCAL language under Delphi 5 IDE. Now, Since we want to redevelop the application using MFC, the Delphi Pascal application could be possibly redeveloped in MFC. My question is...Is there any easy and quick way of converting the fortran libraries to C or C++ to be linked with the redeveloped application in MFC

Jochen Arndt

There might be no need to convert the libraries. It should be sufficient to create header files defining the exported functions and the calling conventions and linking the MFC application against the libraries. Depending on how the libraries has been build, you may also try to rebuild them using options for C/C++ access. Your FORTRAN compiler/linker documentation should have some information about building libraries to be accessed from C/C++.

manoharbalu

The Fortran Libraries were built using Fortran compiler in visual studio 97 IDE in Winxp OS As we had moved to Win 7 and later, We dont want to use the Fortran Compiler anymore. But the Libraries require periodical updations and rebuild. Is that possible without conversion from Fortran to C++? Please advise and provide any alternate suggestions if any.

Jochen Arndt

I don't know if it is possible. When using an old Fortran compiler with a newer C/C++ project, the libraries must be build as static libraries. It depends also on the dependencies of your Fortarn libraries. You can use the Dependency Walker (depends.exe) Home Page[^] to load your Fortran DLLs and check which other dependencies exist. If there are some, you might have problems because those might refer to quite old DLL versions. You can check it using a small test project:

#include

// Link with library. Copy library to build path (debug / release),
// specify full path here, or add path of libraray to project settings.
#pragma comment(lib, "fortran_library_name")

extern "C"
{
// Functions exported by fortran_library_name and used in this program.
// Note that function names may be all upper case.
// The function name may be also exported with a leading underscore.
// You can see the names in the DependencyWalker.
void __stdcall some_fortran_lib_func1();

// Another example with Fortran code
// REAL\*8 FUNCTION SOME\_FORTRAN\_LIB\_FUNC2 (a, b)
// REAL\*8 a \[VALUE\]
// REAL\*8 b \[REFERENCE\]
// b = SQRT(a)
// SOME\_FORTRAN\_LIB\_FUNC2 = a \* a
// END
double \_\_stdcall SOME\_FORTRAN\_LIB\_FUNC2(double f, double \*p);

}

int main()
{
some_fortran_lib_func1();
// Print result here if functions returns a value or modfies parameters
return 0;
}

Use the above code snippet to try first with a simple function (few parameters). If that works proceed with all functions declaring and testing them for correct results (I assume that most - if not all - are just doing some calculations).

manoharbalu

What if I want to change the Fortran Library function code? If I have to change it in the Fortran Library source and rebuild in the old setup, then I require to change all my Fortran Source to be converted to C++. Please consider my above requirement too. How to do modifications and build library files from the Fortran library source without using Fortran compiler in VS97 setup?

Lost User

See Fortran Source to be converted to C++ - Google Search[^].

Jochen Arndt

manoharbalu wrote:

What if I want to change the Fortran Library function code?

Then do that.

manoharbalu wrote:

If I have to change it in the Fortran Library source and rebuild in the old setup, then I require to change all my Fortran Source to be converted to C++.

Why? As long as the function return type or the parameters are the same there is even no need to touch the C/C++ code (provided that you can import the library created by the old compiler as suggested by me).

manoharbalu wrote:

How to do modifications and build library files from the Fortran library source without using Fortran compiler in VS97 setup?

That makes no sense. To compile Fortran code you need a Fortran compiler. If you want a more recent Fortran compiler without paying for it you can use GNU Fortran[^] which can be also used with Windows. If you don't want to use any Fortran compiler, you have to rewrite the code in C/C++. [EDIT] There is no "easy" way. Even when using some kind of automatic conversion you have to do some manual work and check if the results are identical to the original version. This often requires understanding what the functions are doing. Then it is better to do the conversion manually too. [/EDIT]

leon de boer

To be able to advise you I need to know a couple of things 1.) Are we talking Fortran 77 or Fortran 90 code in the libraries and what complexity on exchange interface. 2.) How closely are you trying to mimic the functionality of the Delphi Application. For point 1 there are some real complexities in linking Fortran 90 libraries to C++ as most of the advanced features are more closely related to Pascal than C++. Things that will give you nightmares are things like multi dimension arrays in column-major order, variant data fields require special conversions and any strings exchanges. So conceptually the linking of the libraries is easy but if the exchanges out of the Fortran libraries are complex the problem turns to a nightmare. So it's pretty much the same as linking them to Pascal but there are less consistency with datatypes used in the languages. With point 2, I would first question why you want to use MFC and C++ for that matter? Delphi is much more structurally similar to C# this will give you the idea Delphi vs. C# comparison | vsChart.com[^]. C++ is a level lower than Delphi, so what I am wondering here what is driving the want to bring the development onto C++. Don't get me wrong if you have a good C++ programmer they can easily convert it but the exact mimic of the framework well that is another story. I wrote the complete clean room copy of the Borlands objects unit that is in FreePascal (you will find me on the credits). I have also actually written a mimic of the whole Delphi 3 framework in C++ for an application I needed to exactly mirror and it took me just under 2 years. So is this being driven by a programmer wanting to make this choice or is it just a thought bubble. I have similar reservations about MFC. It's still "current" and "used" but even Microsoft has now released it as free to use in VS2015 as it's commercial value is receding. Commercially most would select a different framework and to do that you start asking yourself do you need cloud access and the new technologies. If you don't need these you might select MFC but there are other choices.

In vino veritas

leon de boer

I am going to interrupt here because Jochen may be misleading you, while not meaning to. While he has shown a simple function with a double in out etc that is all nice and easy like he has indicated because they are all standards in both languages. The thing that gets a bit fun is if your interface exchanges has string, multi dimensional arrays and variant records and the like which he hasn't mentioned. So do you have any pascal specific structures being exchanged, stuff your Pascal compiler would have known but C++ doesn't have. For example your pascal string the first byte is the length and then the string data follows with no ending #0 character so C++ will crash and die if you interface that as a C string, you have to marshal it. Any multi dimensional array will similarly be backwards row major in C++, column Major in Pascal/Fortran. Complex numbers are another thing that doesn't exist in C++ so if you have them on the interface they need special handling. If you have Pascal/Fortran variant records you will need structures with unions and packing control with C++ and a lot of marshalling. Probably look at the library interfaces and write out all the different types exchanged on the interface as a start. So it's exactly like how you link it to Delphi but sometimes C++ will have no idea of the type you are exchanging, unlike Delphi which natively knows them as the languages share the type definitions. There is also an added complication we need to talk about, your library files will be strictly ANSI and strictly 32 bit to link. If you select 64 bit complilation and unicode or wide character set on the C++ compiler you will not be able to link the old libraries, they would require what is referred to as a thunk interface which would have to be then written.

In vino veritas

David A Gray

Since your existing libraries can be linked, you need not convert them all at once. However, if you really do intend to abandon the Fortran compiler, then convert them you must, eventually. However, C++ and Fortran are enough alike that the conversion may be simpler than you think. For instance, the control structures should be fairly straightforward. While you may have to visit each one briefly, I suspect that a lot of the conversion can be handled by editor macros or Perl scripts written around regular expressions. If the libraries use PRINT and FORMAT statements, all of which will need to be completely rewritten to use something like sprintf(), you may not be able to do quite as much with automation, though I would explore it. It's been too long, and I've forgotten most of what I once knew about FORMAT statements, but it's quite possible that you can accomplish much of that conversion with regular expressions, too. Along that line, since they are essentially literal constants, consider replacing the FORMAT statements with #define macros or string resources, so that they incur little or no runtime overhead. There is a trade-off between #define macros and string resources. A #define resolves to a constant that is baked into the code, and costs basically nothing to use. A string resource requires a Windows API call (LoadString) every time you need a new pointer to the string. If you set your character set to Unicode and null terminate your string resources, LoadString can return a pointer to the string, right where it sits. There is a resource compiler option, settable in the project configuration, to null terminate your resource strings. Otherwise, you need a buffer of up to 4097 TCHARs to hold each string. Better yet, let MFC look after all of that by using its CString class, which even sports a LoadString method that looks after the memory for you. Another potentially thorny issue is COMMON blocks, either blank or labeled. Blank common is essentially process global storage that must be externally linked, and is usually easiest to define as part of the source file in which main() is defined. If there are also labeled COMMON blocks, consider putting each into a static class. Regardless, the actual common block definitions should go into header files. If you surround them with preprocessor guard cod