Object-Oriented Programming Via Fortran 90/95

Ed Akin

Mentioned 1

Learn how to write technical applications in a modern object-oriented approach, using Fortran 90 or 95. This book will teach you how to stop focusing on the traditional procedural abilities of Fortran and to employ the principles of object-oriented programming to produce clear, highly efficient executable codes. In addition to covering the OOP methodologies the book also covers the basic foundation of the language and good programming skills. The author highlights common themes by using comparisons with Matlab and C++ and uses numerous cross-referenced examples to convey all concepts quickly and clearly. Complete code for the examples is included on the book's web site.

More on Amazon.com

Mentioned in questions and answers.

In some scientific environments, you often cannot go without FORTRAN as most of the developers only know that idiom, and there is lot of legacy code and related experience. And frankly, there are not many other cross-platform options for high performance programming (C++ would do the task, but the syntax, zero-starting arrays, and pointers are not compatible with some people).

So, let's assume a new project must use Fortran 90, but I want to build the most modern software architecture out of it, while being compatible with most recent compilers (Intel ifort, but also including the Sun/HP/IBM compilers)

So I'm thinking of imposing stuff that is widely known as common good sense, but not yet a standard in my environment:

  • global variable forbidden, no gotos, no jump labels, implicit none, etc.
  • "object-oriented programming" (modules with datatypes and related subroutines)
  • modular/reusable functions, well documented, reusable libraries
  • assertions/preconditions/invariants (implemented using preprocessor statements)
  • unit tests for all (most) subroutines and "objects"
  • an intense "debug mode" (#ifdef DEBUG) with more checks and all possible Intel compiler checks possible (array bounds, subroutine interfaces, etc.)
  • uniform and enforced legible coding style, using code processing tool helpers.

The goal with all that is to have trustworthy, maintainable and modular code. Whereas, in lot of legacy codes, re-usability was not a important target.

I searched around for references about object-oriented Fortran, programming-by-contract (assertions/preconditions/etc.), and found only ugly and outdated documents, syntaxes and papers done by people with no large-scale project involvement, and dead projects.

Any good URLs, advice, reference paper/books on this subject?

I'm in a rather hurry, so forgive me if I'm making this answer in the form of checkpoints instead of reasonable sentences.

  • try adhering to the standard (Fortran is a standardized language, and by adhering to standard language features, and avoiding vendor specific extensions, you'll have a portable between platforms program, for which you can be sure the compiler will give no problems). I don't know where I downloaded my copy, but I'm pretty sure you can download the latest draft (beware; many features of fortran 2008 or 2003 for that matter are still not implemented in the currect compiler, although many are almost there nowadays ... Cray being one) from J3's page
  • for all questions regarding the above, I heartily recommend comp.lang.fortran usenet group - not only does it have some very knowledgeable people there (for example. mr. Richard Maine ... will probably be willing to answer any standard compliance questions you may ask, with much detail, if asked nicely ... same goes for many others) but it also has people who've worked on large scale problems and will certanly know and be willing to give advice on your subject
  • books - in addition to all of the already mentioned (Metcalf, Reid and Cohen's book also has my recommendation, also "Fortran 2003 handbook" by Maine and others ...), try finding yourself a copy of Stephen J. Chapman's "Fortran 95/2003 for scientists and engineers" ... takes a little too confident stand on some topics, but still, overall a very nice book, with many "good programming practices" mentioned)
  • also, don't know if you've comed across this one "Object oriented programming via Fortran 90/95"

Some comments on your text:

( This may all seem "evident" modern programming assumptions, but in a legacy fortran world, most of these are big changes in the typical programmer workflow )

Even in a modern fortran world, some of these assumptions are questionable ... remember, fortran programmers are not programmers (I'm repeating this in condensed form; I've already written this on this forum so many times) but engineers, scientists and so on. To them (us?) code is not a goal, but merely a tool ... to professional programmers code is everything; they have nothing "beyond it" ... therefore, they cherish it so much. To us engineers, it is merely a means of getting the result we want ... with that in mind, although good programming practices pay later, do not necessary insist on them where there is no obvious need for them.

The goal with all that is to have trustworthy, maintainable and modular code. Whereas, in typical fortran, modularity is often not a primary goal, and code is trustworthy only if the original developer was very clever, and the code was not changed since then ! (i'm a bit joking here, but not much)

Somebody once said, and you wouldn't believe how true it is:
"There is nothing more permanent than a temporary fix".

Any good URL, advice, reference paper/books on the subject?

Given several above.

Also, while writing this answer, I see High Perf. Mark posted a very nice answer, with which I mostly agree ... it goes a little more into detail about standard adhering.

Also, my recommendation would be to definitely post this question also on comp.lang.fortran ... I gather you can get much more quality answers there, then in here (I believe there isn't more then 20 or so fortran programmers on whole of stackoverflow).

There was a set of code writing guidelines published freely by some european union commitee; they would be very useful as part of this answer, but unfortunatelly, I cannot find them in my quick google search, and haven't got the time to look extensively. Try searching on the topic ... maybe you'll have better luck.