tags:

views:

75

answers:

1

Hi; I am a modeler who programs...I would never call myself a programmer, yet I program in C# and in FORTRAN. I have a FORTRAN model that I have connected to some C# code through a dll. I have found that I must have a common block in order to keep the variables in memory in the dll. I have also found that I cannot use more than one include statement.... my include file for the common variables are all Unlabeled. Chapman (2008) "FORTRAN 95/2003 for scientists and Engineers" states "The unlabeled COMMON statement should never be used ...".

How can I ensure that I do not have corrupted memory in my common file? I guess I can experiment, but I was hoping to have some sound advice on this. I am using the Lahey-F ver 7.2 within Microsoft Visual Studio 2008

Anyone, any thoughts?

A: 

As a programmer who models what I'd like to know is exactly why Chapman states that the unlabelled COMMON should not be used. From what I can remember the blank / unnamed common block is global and must be defined in the main program.

The only way to be sure about this is probably to make a simple Fortan DLL and then disassemble it to see what it's done with / where it put the common block.

Also it'd be useful if you could paste examples of errors etc. when you try to use a named common. It may be that there is a better solution once we understand exactly what's not working.

Richard Harrison
Thanks, I will look into it.
DavidAS
Re why unlabeled common blocks are said to be poor practice: there is only one such block and the variables overlap in memory order ("sequence association" in Fortran terminology). Mistaken conflicts are easy and code re-use difficult -- how can you add some code that uses unlabeled common to another program that uses different unlabeled common? One solution: label your common blocks. A better solution in Fortran >= 90: use module variables instead of common and get away from sequence association.
M. S. B.
Thanks for posting. Yes, I agree with using modules; my program is structured around modules. However, modules (with local and global (public) variables) do not stay in memory when used in a dll. At least, I have not been able to demonstrate that. If someone knows how to keep private and public variables in active memory in a dll please, please tell me how. The documentation, to my finding, does not demonstrate that.
DavidAS
@M.S.B Thanks - that's how I remember Fortan 7/IV in general, except generally we used COMMON /DATAPOOL/. @David my experience and understanding of DLL leads me to believe that the only way to decide this is to produce a small example DLL and post it with the sources so I can look at the disassembly.
Richard Harrison