I am using some F77 fixed format code with my F90 program. I am trying to include both kinds of code in my main program. Here's how I have arranged my code:
Header files:
File Name:include.inc
include 'module_variables.F90'
include 'message.F90'
include 'module_common_functions.f90'
include 'module_input_gdf.F90'
...
Relavant LAPACK files
File Name: lapack.inc
include 'xerbla.f'
include 'strsm.f'
include 'slaswp.f'
include 'sgetrs.f'
include 'sgetrf.f'
...
Now my main program looks like:
include 'lapack.inc'
include 'include.inc'
program MDL_HydroD
use module_variables
use module_write_files
use module_read_files
...
When I try to compile my main code with ifort "MDL HydroD.F90", the F77 formatted files give error message:
xerbla.f(1): error #5078: Unrecognized token '\' skipped
*> \brief \b XERBLA
---^
This is because the compiler is reading the commented section (starts with *). Is there any way I can compile with both type of fortran code in my header.
Note: I am using Intel Composer XE 2013 with command prompt.
There are compiler specific directives (not part of the standard language), for that compiler, that allow you to change the source form in use.
Place the relevant directive before the include file, and then place the other directive after the include file to switch the source form back. Perhaps:
!DEC$ NOFREEFORM
INCLUDE 'lapack.inc'
!DEC$ FREEFORM
See http://software.intel.com/en-us/node/466230 for more information.
Related
Apparently it is recommended to force include precompiled headers, so that the source may be used with and without precompiled headers. Even CMake uses the force include method on precompiled headers.
However for example Microsofts MSVC documentation says:
The compiler treats all code occurring before the .h file as precompiled. It skips to just beyond the #include directive associated with the .h file, uses the code contained in the .pch file, and then compiles all code after filename.
and for the /FIoption the documentation says:
This option has the same effect as specifying the file with double quotation marks in an #include directive on the first line of every source file specified on the command line, in the CL environment variable, or in a command file.
So to summarize this: All includes that are above/before an include directive of a corresponding precompiled header, will be precompiled into the PCH file. Force-including that file will put this in the first line of a file.
My question now is: How does this work together? Is there some special logic for PCH files during build process or am I missing something?
Update: I checked the gcc documentation as well and it looks like that gcc searches for precompiled headers for each include directive it finds and uses precompiled headers if possible. So do I understand it correctly that MSVC kind of summarizes all includes before (including the header itself) an include that should be used to generate a precompiled header, where gcc instead generates a precompiled header for that specific header?
If that's right it arises the question: Is gcc really way more flexible regarding preocmpiled header usage and how easy it is to gain a performance boost during compilation out of it?
Suppose I have a file test.f90 (free-form code) that includes some other file foo.h (fixed code).
The two didn't work well together because they have different comment styles, so I put a preprocessor directive !DIR$ NOFREEFORM at the top of the foo.h source code, which tells Intel's Fortran Compiler ifort to interpret that file as fixed-form source code.
Unfortunately, the rest of my code in test.f90 gets errors that indicate ifort is interpreting it as fixed-form rather than free-form code.
I haven't rigorously checked, but is it possible that the preprocessor directive in foo.h is causing ifort to interpret the code in test.f90 as fixed-form? I didn't think this was possible because ifort treats each included file as a separate compilation, rather than just copy-pasting the code.
The latest standard states
The effect of the INCLUDE line is as if the referenced source text
physically replaced the INCLUDE line prior to program processing.
so it is entirely possible, in fact absolutely inevitable, that the preprocessor directive in the included file causes the compiler to change its interpretation of the code.
include-d files are not separate compilation units.
I guess you should be able to use!DEC$ FREEFORM to switch the compiler's behaviour back again.
I am trying to include a file 'a.h' into a Fortran program 'b.f'
The contents of the files are as follows:
a.h
c This is a comment
k = 10
100 format( I5 )
b.f
program test_include
include 'a.h'
write(*,100) k
end program test_include
When I try to compile the file 'b.f' using the following command
gfortran -ffree-form b.f
The compiler gives the error
Included at b.f:2:
c This is a comment
1
Error: Unclassifiable statement at (1)
But when I change the comment line to
!c This is a comment
gfortran compiles it successfully and the program runs correctly.
Can someone tell me how to make gfortran recognize lines beginning with 'c' in a '*.h' file as a comment. I am trying to include a similar file (with comments beginning with 'c') from a library into my free-form fortran code, and I can't really make all the comments beginning with 'c' in that file, to begin with '!'.
The include file is in fixed-form! You cannot mix free and fixed form in a single file. Since
[the] effect of the INCLUDE line is as if the referenced source text physically replaced the INCLUDE line priorto program processing [,]
the combined source text needs to be either fixed or free form, but not a mixture of both.
[Source: Fortran 2008 Standard, Cl. 3.4 (6)]
This leaves you two options:
Convert the main program to fixed form, or
Convert the include files to free form.
For 1), you need to specify -ffixed-form, and format b.f to comply to fixed form. b.f would then look like
program test_include
include 'a.h'
write(*,100) k
end program test_include
For 2) , you would convert the include files to free form. The include could then be written as:
! This is a comment
k = 10
100 format( I5 )
If you cannot convert all files, I would suggest writing wrapper modules in fixed-form, include the source code, and from then on use the wrapper modules instead. In case of the snippet you provided, this would require further thought, but in case of include files with only variables/parameters/interfaces this could look like
module wrapper_vars
include 'vars.h'
end module
For subroutines and functions, you could also use modules:
module wrapper_subroutines
contains
include 'subroutines.h'
end module
I wrote a simple C++ program to parse an XML string, called sample.cpp. The program includes a header file, tinyxml.h. When I compiled the program on a unix machine I got the error:
tinyxml.h: No such file or directory
How can we add new header files to the standard library and make them compile? Can anyone please help to get it done? Thank you
You need to tell your compiler where to find the header file. This depends on the compiler, but is typically done by specifying -I<directory> on the command line.
If the header file is in the same directory as the cpp file, you need to include it in quotes, instead of angle brackets, ie.
#include "tinyxml.h"
Instead of
#include <tinyxml.h>
I'm studying C++ right now, coming from a background in Python, and I'm having some trouble understanding how C++ handles multiple source files. In Python, the import statement first checks the current working directory for the module you're trying to import and then it checks the directories in sys.path. In C++, where would I place a custom made .h file? Where would the compiler even look?
For example, I've got a program, foo.exe compiled from a single source file, foo.cpp, both in the same directory. I decide that I want to organize things a little better, so I create a new .h file, bar.h and dump stuff in there. Would I just need to #include to get to the stuff I put there? What if I want to use bar.h with another program (in a completely different directory)?
There are two include variants:
#include "path-spec"
#include <path-spec>
Quote notation:
This form instructs the preprocessor to look for include files in the same directory of the file that contains the #include statement, and then in the directories of any files that include (#include) that file.
The bracket notation looks for header files in certain defined locations.
With gcc you can get some information about these pathes via:
$ echo | gcc -v -x c++ -E -
Compilers accept
-I or /I
options to add additional pathes.
It (generally) looks in the include path if you use #include <foo>, else it uses relative paths if you use #include "../../foo/bar.h".
You set the include path with -I or /I on most compilers. Consult its manual for details.
Don't define any objects in headers though -- you will have multiple definition errors at link time if you do (and include the header in multiple source files).
It works in a similar way. The #include only is used by the compiler. In execution time the file bar.h doesn't gets used. But in compile time it is.
In compile time, the file could be in two places:
1.- The current directory (as in python)
2.- The directories configured in your include path. Where to configure that directories depends of the compiler you are using. Most of them let you define the include directories in the compile command line. And most IDEs let you configure it in some Options menu.
Hope it helps.
If your header files are in the same dir, you can include them like:
#include "bar.h"
If you want to include this header from another dir:
#include "../foobar/bar.h"
Basically quotations mean to search from current directory and brackets like in #include <abc.h> mean to search in standard header file directories. You can add custom directories to the standard search path by adding a -I /path/to/your/custom/headers in the compile command.
#include with angle brackets looks in the system include directories. Like this:
#include <iostream>
With double quotes it looks in the current directory and other directories given to the compiler to search.
#include "foo.h"
g++ -I../include foo.cpp
the thing you are missing in the python model is the linker.
in python you import code and its interpreted right there and then. in c/c++ you compile each source file into an object file. You then tell the linker to collect a bunch of object files into an executable
Typically the includes in c/c++ source files only contain descriptions of whast in the other C files (the names of functions, etc) not the function contents. This is enough for the compiler to compile a given file. Then the linker will combine your object files with libraries of 'well known' functions and make an executable