- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have tried to separate the definition of a common block into a separate file, and including this file in my Fortran code.
This results in a host of error messages, mainly referring to some end of file problem.
Is it not possible to INCLUDE a file with a common block? Do I need to set up some option in a particular way to succeed in this?
Thanks.
This results in a host of error messages, mainly referring to some end of file problem.
Is it not possible to INCLUDE a file with a common block? Do I need to set up some option in a particular way to succeed in this?
Thanks.
Link Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Since you did not include an example of what you tried, this is just a guess. Although I use modules for new development because they are supported by the Fortran 90 standard, I maintain a lot of legacy code that used common blocks that are defined in include files. I suspect that your problem is that the include file contains an "END" statement or that the syntax of the INCLUDE is somehow mangled.
If this does not help, please include a small extract of the include file and the routine that tries to INCLUDE it.
John
If this does not help, please include a small extract of the include file and the routine that tries to INCLUDE it.
John
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is the error message I get:
----
...MEMCOMMON.FOR(30) : Error: Syntax error, found END-OF-FILE when expecting one of:
----
...MEMCOMMON.FOR(30) : Error: Syntax error, found END-OF-FILE when expecting one of:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My guess is that you have named the INCLUDE file with a .F or .FOR file type and have included it in the project as a "source file". This means that Developer Studio will try to compile it as a standalone Fortran source, which it isn't. If this is the case, click on the name of the file under "Source Files" and press the Delete key. This will remove it from the project (but won't delete the file itself.) Now do Build..Update dependencies. The INCLUDE file should now show up under "External dependencies" and you can build without error.
If you continue to have problems, send us a ZIP file of your project to vf-support@compaq.com, and we'll look at it.
Steve
If you continue to have problems, send us a ZIP file of your project to vf-support@compaq.com, and we'll look at it.
Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Putting COMMON blocks and their variable declarations into an include file is the safest way to ensure uniform definition of COMMON blocks in all the routines that use them. Hence this in itself would not cause your problem. I think Steve's suggestion is probably the answer.
On a slightly different point, is there not a storage efficiency problem in the way INTEGER and DOUBLE PRECISION variables are mixed in the COMMON block? I have always followed the principle of having separate COMMON blocks for for INTEGER/REAL (4 bytes, usually) and DOUBLE PRECISION (8 bytes).
If they must be mixed in the same COMMON block, it used to be the recommended practice to list the largest storage declarations (ie DOUBLE PRECISION) first, then INTEGER/REAL, then INTEGER*2, etc., to minimise storage alignment problems. Is this still recommended?
In the example quoted, INTEGERs MEMTYN and MEMPYN are mixed with DOUBLE PRECISION variables in the COMMON block.
Regards,
Graham Kipp
On a slightly different point, is there not a storage efficiency problem in the way INTEGER and DOUBLE PRECISION variables are mixed in the COMMON block? I have always followed the principle of having separate COMMON blocks for for INTEGER/REAL (4 bytes, usually) and DOUBLE PRECISION (8 bytes).
If they must be mixed in the same COMMON block, it used to be the recommended practice to list the largest storage declarations (ie DOUBLE PRECISION) first, then INTEGER/REAL, then INTEGER*2, etc., to minimise storage alignment problems. Is this still recommended?
In the example quoted, INTEGERs MEMTYN and MEMPYN are mixed with DOUBLE PRECISION variables in the COMMON block.
Regards,
Graham Kipp
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The suggestion by Steve solved the problem of error messages. I also find Graham's suggestion useful - I get lots of warnings about possible alignment problems.
Q: There are many Fortran 90 books available. None of those I have seen are directed towards a specific compiler, however (I don't consider the book by Etzel and Dickinson a Fortran 90 book). The consequence of this is that it will be relatively difficult for newcomers to start using, say Visual Fortran: An important part of starting to use a compiler is related to getting to know the user interface of the compiler/development system.
It would really reduce the hurdle of starting to use Visual Fortran if you "bribed" one of the current Fortran 90 book authors to include an introduction to Visual Fortran!!!!
Thanks!
-Bernt Lie
Q: There are many Fortran 90 books available. None of those I have seen are directed towards a specific compiler, however (I don't consider the book by Etzel and Dickinson a Fortran 90 book). The consequence of this is that it will be relatively difficult for newcomers to start using, say Visual Fortran: An important part of starting to use a compiler is related to getting to know the user interface of the compiler/development system.
It would really reduce the hurdle of starting to use Visual Fortran if you "bribed" one of the current Fortran 90 book authors to include an introduction to Visual Fortran!!!!
Thanks!
-Bernt Lie
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Actually, a book on using Visual Fortran was being written by an author of a popular Fortran 90 book, but he dropped the project due to lack of time. We located another author who is working on a book, but it probably won't be out until at least the second half of 2001.
However, the problem you had is not specific to Visual Fortran - you violated Fortran standard language rules. Some compilers would complain, some would not.
By the way, we do have the Getting Started book and the Tutorial Overview which should introduce the user interface, though I admit these could be better. We're working on that.
Steve
However, the problem you had is not specific to Visual Fortran - you violated Fortran standard language rules. Some compilers would complain, some would not.
By the way, we do have the Getting Started book and the Tutorial Overview which should introduce the user interface, though I admit these could be better. We're working on that.
Steve
![](/skins/images/45C6C2D737ED71F4C51F0145C8CB1E9C/responsive_peak/images/icon_anonymous_message.png)
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page