We start off with some examples intended to test whether it's possible to
create a function with LEN given by specification expression via function name,
and SIZE given by specification expression via result name. Preliminary
examples: interface1.f90,
and interface2.f90.
Final examples: interface3.f90,
and interface4.f90.
Now I would like to present an example that is quite mysterious to me. It
attempts to use 4*atan(1.0d0) in an initialization expression, so that we can
use the calculated value of pi as a parameter. Firstly, we compile the file constant1.f90
which calculates the first seventeen significant figures of pi and saves them as
character LENs of a user-defined type. Then we compile the file constant2.f90
which defines a named constant instance of this user-defined type. Since this is
a constant, we can use the LENs of its subobjects to define the constant pi. We
link the two resulting object files together to create a program. Where did we
violate the standard such that an expression which was not an initialization
expression ultimately was used in an initialization expression? Answer: this
lies in Corregendum
1 where constant expressions are pretty much expunged from the standard, and
good riddance to them, too! Thanks to Steve Lionel at Intel
for informing me about the effect of the Corrigendum on my examples here and to
Richard Maine of X3J3 for telling me
how to find it.
I also have some examples that lf95 5.70f, cvf 6.6c, and g95 Windows download
of 12/18/04 all seem to fail on. First consider elem_assign.f90,
which tries to do an elemental defined assignment. New x and permuted x should
be the same, of course. Update 2/15/06: some code which
plausibly trips over this bug is to be found at order_stat.i90,
test program at order_stat_test.f90.
lf95 7.10.02 and ifort Package ID: W_FC_C_9.0.029 still trip, but g95 gcc
version 4.0.2 (g95!) Dec 21 2005 has fixed this. Now examine cyclic_specs1.f90,
where compilers seem to be required by the standard to encounter an internal
compiler error. Instead they all seem to find some excuse to reject this code.
Here's a more tedious example: first compile logical_gen.f90,
then run it and compile the resulting file logical_all.f90. None of the
above-mentioned compilers can do this. If you can get it to compile and run it
should yield a truth table for the 1024 possible binary logical operations in
f95. Correction: now that I have seen Corregendum 1 it is
apparent that the above example now is only valid as an extension to the f95
standard. But I will leave it in play as it's still valid in f03 and instead
provide logical_genb.f90
which creates logical_allb.f90 which should in turn produce a truth table with
768 entries, but this time should work on any f95 compiler.
As an example of generic programming in Fortran I offer GENERIC_BLAS.ZIP
which is a template version of the well-known BLAS package. It should be
complete with README.TXT file, *.bat files from which the user can hopefully
puzzle out how to compile and test on his own machine, and input files for the
test programs.
New 3/30/06: upgraded GENERIC_BLAS.ZIP
to work with extended precision, REAL(SELECTED_REAL_KIND(18,4931)).
A little test of whether the elemental intrinsics accept all their possible
arguments is test_intrinsic1.f90.
An
example of stream I/O portable across g95 (4/2/06), cvf 6.6C3, ifort 9.0.030,
and lf95 7.10.02 fire.f90.
Portability
is increased also to ftn96 PE 4.9.0 with fire2.f90 by
working around ftn95 bugs and implementing ftn95 syntax for stream I/O when
detected.
Another example of code that messes up a lot of compilers: logical.f90
which also needs the include files logical.i90
and ifaces.i90.
This doesn't compile on lf95 7.10.02 nor ftn95 PE 4.9.0 and results in a
spurious standards warning on ifort 9.0.030 and cvf 6.6c3 when f95 standards
checking is in force. Works OK on g95 4/2/06. It seems that having an intrinsic
extension operator can cause unanticipated problems for compilers.
New 10/14/07: My first attempts at using BIND(C) for Windows programming.
A console
example and a
Windows example.
New 1/9/08: Some bug fixes for the
console
example and the Windows
example.
New 7/20/10: Adaptation of the
Windows
example to use !GCC$ ATTRIBUTES STDCALL and function WinMain so that it works also with
32-bit gfortran.
New 12/20/10: Simple Windows program to send a test pattern to my TV.
New 3/16/08: An
attempt to create a program that uses multiple calling conventions
in gfortran.
New 4/30/08: Tests
whether some functions exist in gfortran.
New 12/20/10: Windows and
Linux utilities
to read and write floating control word and status word as well as mxcsr
and read time stamp counter and get CPUID.
New 12/31/10: I have improved my Hello, world in Opengl
program. It needs a relatively recent Windows version of gfortran, such as those available at
http://www.equation.com. I hope you
find this example useful.
New 1/11/11: Further improvements to my Hello, world in Opengl
program. The opengl_types, gl, and glu module are improved and this example has a 3-d image and text.
New 1/21/11: I am posting a C example program to
demonstrate that Pinyo Taeprasartsit's
MinGW
64-bit freeglut package works.
New 1/21/11: Now I have a Fortran version of the above
example, with screenshot, 64-bit executable, and build instructions.
New 2/10/11: I have been working on the GridView example from Norman Lawrence, Compaq Visual Fortran: a guide to
creating Windows applications, Digital Press 2002. The book can be found at
Google
Books and there is a companion site with the source code
for the book as well. So I have fixed some bugs in the program and added some
enhancements as an exercise in learning how to make Win32 API and OpenGL work in
Fortran. Please take a look at the result here.
New 6/14/11: Example using OpenGL to show an AVL tree.
New 7/27/12: I have been reading NeHe's OpenGL tutorial pages.
I have converted Lessons 01-05 to
gfortran. New 8/2/12: Now I have
Lessons 06-10 converted. New 8/8/12: Now I have
Lessons 11-15 converted. New 8/13/12: Now I have
Lessons 16-20 converted.