I've written a function which calculates the eigenvalues of a 2*2 matrix. It takes a 2*2 matrix as an argument and returns 2 eigenvalues via a 2-element array. I have declared the function in the program unit like this:
real, dimension(2), external :: eigenvalues
But it won't compile, it comes up with this error:
Error: EXTERNAL attribute conflicts with DIMENSION attribute
Is it just not possible to have functions that return arrays, or am I doing something wrong?
Any help/suggestions are appreciated, thanks. If it helps, I'm using fortran 90 with the gfortran compiler
Modestly extending the other two answers, I think other approaches are typically preferable to the old "external". (The "Fortran 2003 Handbook" lists at least one case in which "external" must be used.) As already suggested, for your own source code, place the procedures (functions & subroutines) into a contains section of a module and then use it. This will automatically make the interface of your procedures explicit so that the compiler can check compatibility between arguments in calls and the dummy arguments of the procedure -- this can catch a lot of programmer mistakes. If for some reason you don't have access to Fortran source code, for example, you are linking to a library or calling C, then I would write an interface statement describing the procedure. This will inform that compiler that the declared name is a function or program and specify the interface to allow argument check. I would only do this when the module method isn't possible because it is more work and prone to mistakes when changes are made because two items have to be changed.
Probably the reason this isn't working is, that according to the "Fortran 2003 Handbook", the use of the external attribute does not provide an explicit interface, and an explicit interface is required for a function returning an array argument. I don't know why the interface is considered to be non-explicit in this case.
The Intel Fortran compiler documentation tells me that EXTERNAL is incompatible with DIMENSION, which is roughly what your compiler is telling you. I've had a quick look at the standard for Fortran 2003 but have failed to interpret it unambiguously on this point -- so I'll agree with Intel and assert that what your are trying to do is non-standard.
You certainly can write functions which return arrays.
It looks a little odd to me that you have written the function EIGENVALUES and are then trying to declare it to be EXTERNAL. I would normally put my function definitions either in a CONTAINS section within a larger program unit or in a MODULE which the calling unit USEs. In neither case do I need to declare anything EXTERNAL.
Where is the source of EIGENVALUES wrt the source of the calling program ?
Related
I am trying to debug a fortran script and I can't figure out why an array is not being defined how it should be. I have parameters
parameter(nx0=101,nd0=40,nindex=1)
parameter(dep1=0,dep2=200,dep3=5)
parameter(del1=0,del2=1000,del3=10)
parameter(pmin=0,nump=6000)
and the array is defined as
real t(nx0,nd0,nindex)
However when I get fortran to print t (which is huge)
print *, 't = ', t
It outputs only zeros and NaNs. Yet when a vector is defined in the same manner:
real x(nx0)
x is defined properly with no zero or NaN terms that do not belong.
I can't understand why t is not initialized properly, does anyone know why?
NOTE: this fortran code that I'm working with is widely used and freely available via the USGS as HASH_v1.2
Variable initialisation is often compiler specific. You should check the documentation for your compiler. Better yet. Manually initialise the arrays and then check that the correct values are returned. Manual initialisation is best practise.
Whenever I program in Fortran I use modules and I don't have to worry about writing interfaces.
Now I'm writing Fortran code to use inside R. The problem is that the subroutines cannot be inside a module so I "have" to write interfaces. If I don't write the interface everything works fine, but smart internet people said I should write the interfaces.
Can someone explain me why? What are the benefit?
As Alexander Vogt says, interface blocks can be useful for providing generic identifiers and allowing certain compiler checks.
If you're using interface blocks to create generic identifiers you're probably doing so within modules, so the main reason to write such blocks when modules aren't about is for the explicit interfaces that they create in the scope in which they occur. It's these that allow those compiler checks and the use association with modules no longer happens.
However, there are times when an explicit interface is required, rather than being a nicety: if referencing a procedure with certain features an explicit interface will be required for your code to conform to the Fortran standard. Those features can be found in F2008, 12.4.2.2
A procedure other than a statement function shall have an explicit interface if it is referenced and
a reference to the procedure appears
(a) with an argument keyword (12.5.2), or
(b) in a context that requires it to be pure,
the procedure has a dummy argument that
(a) has the ALLOCATABLE, ASYNCHRONOUS, OPTIONAL, POINTER, TARGET, VALUE, or VOLATILE attribute,
(b) is an assumed-shape array,
(c) is a coarray,
(d) is of a parameterized derived type, or
(e) is polymorphic,
the procedure has a result that
(a) is an array,
(b) is a pointer or is allocatable, or
(c) has a nonassumed type parameter value that is not a constant expression,
the procedure is elemental, or
the procedure has the BIND attribute.
Beyond those, an implicit interface will be sufficient and the interface block not required. But could still helpful.
In your case, it's only for the calls between the various Fortran components where interfaces have this impact. So, you don't always need to write interfaces and some things can work without them.
The main benefit is that the compiler can perform argument checks. This way, it can warn you about programming errors, which would be very hard to detect otherwise.
Another very nice thing about interfaces is that you can bundle functions. Consider for example the sin function, which is defined for real and complex arguments of different kinds.
Using interfaces, you can call the same function for different types of variables.
For some features of modern Fortran such as function pointers, interfaces are (usually) required.
Just a slightly more "philosophical" viewpoint from the above excellent answers which deal with specific uses of interfaces.
You declare all your variables don't you? Presumably you do this to protect yourself against typos, accidental mis- and ab-use of the variable, and to avoid the reader having knowledge of occasionally arcane rules, amongst other reasons. So why don't you want to do the same for all your subprograms? All the above and more apply.
I know that it's poor practice to not include function prototypes, but if you don't, then the compiler will infer a prototype based on what you pass into the function when you call it (according to this answer). My question is why does the compiler infer the prototype from what you pass into the function rather than the definition of the function itself? I can imagine some kind of preprocessing step where all declared functions are identified and checked to see if a prototype exists for each one. If one doesn't have a prototype, the first line of the function is copied and stuck under the existing prototypes. Why isn't this done?
Because the C compiler was designed as a single pass compiler, where any given file does not know about the other source files that make up the project.
Although compilers have gotten more sophisticated, and may do multiple passes, the general outline of the compilation process framework remains as it was in K&R's day:
Pre-process each source file(macro text replacement only).
Compile the processed source into an object file.
Link the objects into an executable or library.
Inferring prototypes would have to happen in the first step, but the compiler does not know about the existence of any other objects which may contain the function definition at that time.
It might be possible to make a compiler which did what you suggest, but not without breaking the existing rules for how to infer prototypes. A change with such big consequences would make the language no longer C.
The major use for prototypes is to declare a function and inform the compiler about the number and type of arguments in cases where the definition is not visible. Since C was originally compiled single-pass, the definition is not visible when it occurs later in the translation unit, but the more important case from a modern perspective is when the definition is not visible at all, due to lying in a separate translation unit, possibly even in a library file that exists only in compiled form and where no information about the function's type is recorded.
Suppose I have a call to a function which takes a variable number of arguments in my source code. I want to do some kind of static analysis on this source code to find the type of the arguments being actually passed to the function. For example, if my function call is -
foo(a, b, c)
I want to find the data type of a, b and c and store this information.
You pretty well have to do the parse-and-build-a-symbol-table part of compiling the program.
Which means running the preprocessor, and lexing as well.
That's the bad news.
The good news is that you don't have to do much of the hard stuff. No need to build a AST, every part of the code except typedefs; struct, union, and enum definitions; variable-or-function declarations-and-definitions; and analyzing the function call arguments can be a no-op.
On further thought prompted by Chris' comments: You do have to be able to analyze the types of expressions and handle the va-arg promotions, as well.
It is still a smaller project than writing a whole compiler, but should be approached with some thought.
If this is in C++, you can hack together some RTTI using typeid etc.
http://en.wikipedia.org/wiki/Run-time_type_information
I'm following a guide to learn curses, and all of the C code within prototypes functions before main(), then defines them afterward. In my C++ learnings, I had heard about function prototyping but never done it, and as far as I know it doesn't make too much of a difference on how the code is compiled. Is it a programmer's personal choice more than anything else? If so, why was it included in C at all?
Function prototyping originally wasn't included in C. When you called a function, the compiler just took your word for it that it would exist and took the type of arguments you provided. If you got the argument order, number, or type wrong, too bad – your code would fail, possibly in mysterious ways, at runtime.
Later versions of C added function prototyping in order to address these problems. Your arguments are implicitly converted to the declared types under some circumstances or flagged as incompatible with the prototype, and the compiler could flag as an error the wrong order and number of types. This had the side effect of enabling varargs functions and the special argument handling they require.
Note that, in C (and unlike in C++), a function declared foo_t func() is not the same as a function declared as foo_t func(void). The latter is prototyped to have no arguments. The former declares a function without a prototype.
In C prototyping is needed so that your program knows that you have a function called x() when you have not gotten to defining it, that way y() knows that there is and exists a x(). C does top down compilation, so it needs to be defined before hand is the short answer.
x();
y();
main(){
}
y(){
x();
}
x(){
...
more code ...
maybe even y();
}
I was under the impression that it was so customers could have access to the .h file for libraries and see what functions were available to them, without having to see the implementation (which would be in another file).
Useful to see what the function returns/what parameters.
Function prototyping is a remnant from the olden days of compiler writing. It used to be considered horribly inefficient for a compiler to have to make multiple passes over a source file to compile it.
In C, in certain contexts, referring to a function in one manner is syntactically equivalent to referring to a variable: consider taking a pointer to a function versus taking a pointer to a variable. In the compiler's intermediate representation, the two are semantically distinct, but syntactically, whether an identifier is a variable, a function name, or an invalid identifier cannot be determined from the context.
Since it's not determinable from the context, without function prototypes, the compiler would need to make an extra pass over each one of your source files each time one of them compiles. This would add an extra O(n) factor for any compilation (that is, if compilation were O(m), it would now be O(m*n)), where n is the number of files in your project. In large projects, where compilation is already on the order of hours, having a two-pass compiler is highly undesirable.
Forward declaring all your functions would allow the compiler to build a table of functions as it scanned the file, and be able to determine when it encountered an identifier whether it referred to a function or a variable.
As a result of this, C (and by extension, C++) compilers can be extremely efficient in compilation.
It allows you to have a situation in which say you can have an iterator class defined in a separate .h file which includes the parent container class. Since you've included the parent header in the iterator, you can't have a method like say "getIterator()" because the return type would have to be the iterator class and therefore it would require that you include the iterator header inside the parent header creating a cyclic loop of inclusions (one includes the other which includes itself which includes the other again, etc.).
If you put the iterator class prototype inside the parent container, you can have such a method without including the iterator header. It only works because you're simply saying that such an object exists and will be defined.
There are ways of getting around it like having a precompiled header, but in my opinion it's less elegant and comes with a slew of disadvantages. Of couurse this is C++, not C. However, in practice you might have a situation in which you'd like to arrange code in this fashion, classes aside.