Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

new book: Guide to Fortran 2003 Programming (Brainerd)

27 views
Skip to first unread message

Beliavsky

unread,
Jul 7, 2009, 9:11:24 AM7/7/09
to
http://www.springer.com/computer/programming/book/978-1-84882-542-0
Guide to Fortran 2003 Programming
Brainerd, Walter S.
2009, X, 357 p. 34 illus., Hardcover
ISBN: 978-1-84882-542-0
$79.95

About this textbook
Fortran, the premier language for scientific computing since its
introduction in 1957, originally was designed to allow programmers to
evaluate formulas—FORmula TRANslation—easily on large computers.
However, now Fortran compilers are available on all sizes of machines,
from small desktop computers to huge multi-processors. Fortran has
many modern features that will help programmers write efficient,
portable, and maintainable programs useful for everything from "hard
science" to text processing.

This concise, accessible, and easy-to-read Guide to Fortran 2003
Programming introduces the most important features of Fortran 2003
(also known as Fortran 03), the latest standard version of Fortran.
The text is organized for instruction from beginning to end, but also
so that particular topics may be studied and read independently—making
the work eminently suitable as a reference for professionals.


Features:
* Presents a complete discussion of all the basic features needed to
write complete Fortran programs: the form of Fortran programs, data
types, simple expressions and assignment, and simple input and output

* Makes extensive use of examples and case studies to illustrate the
practical use of features of Fortran 03, and to show how complete
programs are put together

* Provides a detailed exploration of control constructs, modules,
procedures, arrays, character strings, data structures and derived
types, pointer variables, and object-oriented programming

* Introduces the topic of modules as the framework for organizing data
and procedures for a Fortran program

* Investigates the excellent input/output facilities available in
Fortran

* Includes appendices listing the many intrinsic procedures and
providing a brief informal syntax specification for the language

* Supplies simple problems throughout the book, to enable the reader
to exercise knowledge of the topics learned

This indispensable textbook/reference provides a tutorial for anyone
who wants to learn Fortran 03, including those familiar with
programming language concepts but unfamiliar with Fortran. Experienced
Fortran 95 programmers will be able to use this volume to assimilate
quickly those features in Fortran 03 that are not in Fortran 95.


Walt Brainerd is the owner of The Fortran Company and has co-authored
the useful Springer reference, The Fortran 2003 Handbook: The Complete
Syntax, Features and Procedures.

Written for:
Anyone who wants to learn Fortran 03
Keywords:
Array processing
C interoperability
Floating-point arithmetic
Fortran
Fortran 2003
IEEE arithmetic
Numerical computing
Object-oriented programming
Parallel computation
Programming languages
Scientific computing

tho...@antispam.ham

unread,
Jul 7, 2009, 6:17:34 PM7/7/09
to
Are there are complete Fortran 2003 compilers yet? Last I read, IBM's
was the closest, but none supported the full standard.

Damian

unread,
Jul 7, 2009, 10:41:23 PM7/7/09
to
On Jul 7, 3:17 pm, tho...@antispam.ham wrote:
> Are there are complete Fortran 2003 compilers yet?  Last I read, IBM's
> was the closest, but none supported the full standard.

Cray released a version with full Fortran 2003 support about six
months ago. I think the only significant feature IBM is missing is
derived type parameters. My money would be on IBM to be the next to
offer full Fortran 2003 support, followed by NAG, followed by Intel,
followed by gfortran.

Damian

Richard Maine

unread,
Jul 8, 2009, 3:43:18 AM7/8/09
to
Damian <dam...@rouson.net> wrote:

> On Jul 7, 3:17 pm, tho...@antispam.ham wrote:
> > Are there are complete Fortran 2003 compilers yet? Last I read, IBM's
> > was the closest, but none supported the full standard.
>
> Cray released a version with full Fortran 2003 support about six
> months ago. I think the only significant feature IBM is missing is
> derived type parameters.

How about allocatable-length characters? I don't know whether or not the
IBM compiler hs them, but some people do seem to overlook that feature
when making feature lists. I regard it as an important feature likely to
be used extensively once compiler support for it becomes widespread. I
have seen people try to explain it as related to derived-type
parameters, but I disgaree with such characaterization.

--
Richard Maine
email: last name at domain . net
domain: summer-triangle

Damian

unread,
Jul 8, 2009, 10:06:06 AM7/8/09
to

The IBM compiler successfully compiles the following:

program main
implicit none
character(:) , allocatable :: message
message = 'Hello, world!'
print *,message
end program

I agree on how useful this feature is. I used to hate dealing with
character data and now I love it!

Damian

Paul van Delst

unread,
Jul 8, 2009, 10:22:45 AM7/8/09
to
Richard Maine wrote:
> Damian <dam...@rouson.net> wrote:
>
>> On Jul 7, 3:17 pm, tho...@antispam.ham wrote:
>>> Are there are complete Fortran 2003 compilers yet? Last I read, IBM's
>>> was the closest, but none supported the full standard.
>> Cray released a version with full Fortran 2003 support about six
>> months ago. I think the only significant feature IBM is missing is
>> derived type parameters.
>
> How about allocatable-length characters? I don't know whether or not the
> IBM compiler hs them, but some people do seem to overlook that feature
> when making feature lists.

<rant>
A pet peeve of mine at the moment is the response I get when I ask vendors about their
release timeline for a fully f2003-compliant compiler. Invariably I get asked, in
different forms, the question "What f2003 features would you like?" Argh. The feature I
want is a fully compliant f2003 compiler. Each vendor updates their f2003 features list
whenever an upgrade is released but each vendor has a different list.
</rant>

Sorry.

cheers,

paulv

Bil Kleb

unread,
Jul 8, 2009, 11:58:33 AM7/8/09
to
Paul van Delst wrote:
>
> <rant>
> A pet peeve of mine at the moment is the response I get when I ask
> vendors about their release timeline for a fully f2003-compliant
> compiler. Invariably I get asked, in different forms, the question "What
> f2003 features would you like?" Argh. The feature I want is a fully
> compliant f2003 compiler. Each vendor updates their f2003 features list
> whenever an upgrade is released but each vendor has a different list.
> </rant>

The standards committee could remove this inconsistency by
specifying a ranked priority for new feature additions or
update the standards more frequently, i.e., smaller iterations?

Regards,
--
Bil Kleb
http://fun3d.larc.nasa.gov

Bil Kleb

unread,
Jul 8, 2009, 12:01:53 PM7/8/09
to
Bil Kleb wrote:
>
> The standards committee could remove this inconsistency by
> specifying a ranked priority for new feature additions or
> update the standards more frequently, i.e., smaller iterations?

Or, more to the point: WIP (work in process) is rarely a good thing.^1

Regards,
--
Bil Kleb
http://fun3d.larc.nasa.gov

[1] See for instance,

http://www.infoq.com/articles/hiranabe-lean-agile-kanban


Damian

unread,
Jul 8, 2009, 12:55:49 PM7/8/09
to

I share a similar frustration but I can't complain since I know
nothing about compiler development and therefore don't know which
features will be easier or harder to implement or what major customers
they might be trying to satisfy. At a certain level, I'm sure it's
all market driven. If people who want certain features migrate to the
vendors that have them, the other vendors will have to follow.
Unfortunately, however, people rarely have that freedom either because
they are tied to vendors who support their platform or tied to the
compiler the system administrator provides on that platform or simply
don't want to write code that only works with one compiler. Plus the
Fortran community is probably sufficiently small that the vendors
don't have as many developers devoted to Fortran as to C++, java, C#,
etc.

My most frustrating experience was having one vendor ask me to submit
a prioritized list of F2003 features. I put a fair amount of thought
and time into it and had high hopes but never received a response and
their latest release has not even a single one of the features I
requested (the object-oriented features).

One thing I'm a little surprised about is that no vendor I know of has
implemented Fortran 2008 submodules. My naive assumption is that this
is low hanging fruit. It would be really useful for large projects
(especially for publicly released API's) because it would allow
separating interfaces from implementations and preventing unnecessary
compilation cascades. I think this would be big bang for the buck.

Damian

Steve Lionel

unread,
Jul 8, 2009, 1:41:13 PM7/8/09
to
Richard Maine wrote:

> How about allocatable-length characters? I don't know whether or not the
> IBM compiler hs them, but some people do seem to overlook that feature
> when making feature lists. I regard it as an important feature likely to
> be used extensively once compiler support for it becomes widespread. I
> have seen people try to explain it as related to derived-type
> parameters, but I disgaree with such characaterization.

Intel Fortran 11.1 supports deferred-length allocatable characters, but
at the moment one needs to add the "-assume realloc_lhs" switch to get
it to work. This will be fixed in an update. Also, several bugs in
this have been reported, and they too will be fixed.

Someone else asked about submodules - Cray supports these today, I believe.

The reason vendors ask about priorities is that we want to implement
first what our customers want most. All of us have finite development
resources and implementing all of F2003 is a LOT of work. In addition,
it would appear that some F2008 features (submodules and co-arrays to
name just two) are of more interest to the majority of our customers
than some of the remaining F2003 features (user-defined derived type I/O
to name one.) Would you prefer to wait for submodules while we finish
UDDTIO? Most of the customers we ask say "no".

We will get all of F2003, eventually. I'd say that, today, we (Intel)
have nearly all of the important bits. I think the question to ask is
"does compiler X now have the features from F2003 that I want to use in
my application?" If it does, then the fact that it doesn't support
every piece of F2003 is perhaps not as important.

--
Steve Lionel
Developer Products Division
Intel Corporation
Nashua, NH

For email address, replace "invalid" with "com"

User communities for Intel Software Development Products
http://software.intel.com/en-us/forums/
Intel Software Development Products Support
http://software.intel.com/sites/support/
My Fortran blog
http://www.intel.com/software/drfortran

Bil Kleb

unread,
Jul 8, 2009, 2:12:10 PM7/8/09
to
Steve Lionel wrote:
>
> Someone else asked about submodules - Cray supports these today, I believe.

As of last December, Cray claims to support the entire 2003 standard, viz,

http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/1221812bfdda69be

Damian

unread,
Jul 8, 2009, 2:32:18 PM7/8/09
to

I too would prefer submodules before UDDTIO.

From what I can tell, Intel 11.1 has almost everything I want. The
biggest missing piece for my work is type-bound operators. I use a
programming style I refer to as "abstract data type calculus," which
involves defining derived types that model high-level mathematical
constructs (e.g., scalar, vector, and tensor fields) and physical
constructs (e.g., fluids and particles) and then enables a syntax
where one can write partial differential equations in a manner that
very closely resembles their textbook/blackboard form. Type-bound
operators are critical to this approach.

Damian

Ian

unread,
Jul 8, 2009, 3:53:58 PM7/8/09
to
The April edition of Fortran Forum has a compiler table
which looks at compiler support for the Fortran 2003 standard.

Copies can be found at

https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=comp-fortran-90

under the files area.

Jane and I also make copies available at our Fortranplus site.

http://www.fortranplus.co.uk/

http://www.fortranplus.co.uk/resources/fortran_2003_compiler_support.pdf

release 4 is in the August edition and adds the entries that Richard
Maine requested.

it also contains support details for the 2008 standard.

The December edition will include an entry for HP
and updated information from IBM.

hope this helps.

cheers

ian

Steve Lionel

unread,
Jul 8, 2009, 3:54:12 PM7/8/09
to
Bil Kleb wrote:
> Steve Lionel wrote:
>>
>> Someone else asked about submodules - Cray supports these today, I
>> believe.
>
> As of last December, Cray claims to support the entire 2003 standard,

Submodules are part of F2008 (draft), not F2003. Yes, Cray is the first
to claim support for all of F2003, and they already have submodules and
co-arrays (the latter, in one form or another, for over a decade.)

Tobias Burnus

unread,
Jul 8, 2009, 5:49:43 PM7/8/09
to
Damian wrote:
> On Jul 8, 7:22 am, Paul van Delst <paul.vande...@noaa.gov> wrote:
>> <rant>
>> A pet peeve of mine at the moment is the response I get when I ask vendors about their
>> release timeline for a fully f2003-compliant compiler. Invariably I get asked, in
>> different forms, the question "What f2003 features would you like?" Argh. The feature I
>> want is a fully compliant f2003 compiler. Each vendor updates their f2003 features list
>> whenever an upgrade is released but each vendor has a different list.
>> </rant>

Well, I can understand that no vendor wants to put a timeline - it is
too easy that the timeline slips. And of cause it would be great if
a(ny) compiler would support all features, but as development costs
time, I think it is reasonably to ask for what features should be
implemented first.

> I share a similar frustration but I can't complain since I know
> nothing about compiler development and therefore don't know which
> features will be easier or harder to implement or what major customers
> they might be trying to satisfy.

Well, adding intrinsics - especially if they have (near) equivalents to
vendor extensions is relatively easy (assuming the C library supports
them). A trivial one is for instance the error function "erf" of Fortran
2008, where one just needs to tell the compiler that it is no longer a
vendor extension but belongs to Fortran 2008. Adding things like
derived-type length parameters, polymorphic datatypes and UDDTIO are on
the other hand much harder.

But the question is not only what is easy and what is hard but also how
much is a feature requested. I think besides looking at customer
requests and at looking what (seems to) make sense, all vendors also
look what other vendors do. This does not lead to a common subset but
still one sees a trend which features are earlier implemented and which
are not.

> One thing I'm a little surprised about is that no vendor I know of has
> implemented Fortran 2008 submodules. My naive assumption is that this
> is low hanging fruit. It would be really useful for large projects
> (especially for publicly released API's) because it would allow
> separating interfaces from implementations and preventing unnecessary
> compilation cascades. I think this would be big bang for the buck.

I had expected the same, but I have somehow the feeling that some other
Fortran 2003 features were more asked for and thus the TR item shifted.
I think to make submodules really useful, one also needs one kind of
compile on demand:

Example: I have at /usr/include/fortran_modules/ an <interface>.f90 file
- and if I compile a file which has "USE interface", the compiler firsts
checks whether the .mod file is there - and failing so, it automatically
grabs the "/usr/include/fortran_modules/interface.f90" file and compiles
it to create the .mod file. That way one can work with modules in a
similar fashion as with C's .h header files. Currently, Linux
distributions ship and HPC centers place the .mod file somewhere and if
one compiles with another compiler (or a different version of the same
compiler), one has the problem that the .mod file does not fit.


Steve Lionel wrote:
> The reason vendors ask about priorities is that we want to implement
> first what our customers want most. All of us have finite development
> resources and implementing all of F2003 is a LOT of work.

I think the problem is not only that Fortran 2003 is that large, but
that there are competing wishes and requests:


First, ever user wants to have to have a bug-free compiler, which of
cause does not exists. Thus one needs to fix all the bugs found by the
users. (Using testsuites and careful review one can try to
prevent/reduce new bugs and one might even find old bugs accidentally,
but user bugreports are most important.)

Secondly, performance. I think this is the most important pre-sales item
- and is an item shared by (nearly) all users, whether they just want to
have a Fortran 77 compiler or a fully fledged Fortran 2008 compiler.
While I think some vendors regard SPEC as too important (and invent and
use strange options, tailored for this special testsuite), I think that
is an area which should not be neglected by vendors - and it usually is not.

Thirdly, new features: They might be either from the Fortran 2003/2008
standard or also a "common" vendor extension. I think the current focus
is really on the standard, but some vendor extensions might still find
their way into the compiler.

Fourthly, diagnostics: This is an item will presumably is of little
interest for pre-sales talks but afterwards it becomes more important.
There is lots of room for improvement for compile- and run-time diagnostic.

Fifthly, the ABI shall be stable, the library should not growth in size
and the compiler code shall be cleaned up and organized such that it
remains maintainable. Takes time, but is not user visible - except if
the ABI has been broken.


I think in gfortran, essentially the same applies as for commercial
vendors. Except that performance is a bit less important* (either one
sees it as free compiler for the students where performance is not
critical or as additional compiler to the (hopefully) highly optimizing
(and hopefully sufficiently bug-free) commercial compiler) and except
that some development is also driven by interest and knowledge of
certain parts of the compiler.


> We will get all of F2003, eventually. I'd say that, today, we
> (Intel) have nearly all of the important bits. I think the
> question to ask is "does compiler X now have the features
> from F2003 that I want to use in my application?"

> if it does, then the fact that it doesn't support every


> piece of F2003 is perhaps not as important.

I mostly agree. Except for two things: There are features, which I
regarded as not so useful, until I realised that - after they became
available - I really do use them. In that sense some features need to
exist to create the demand.

Regarding "does compiler X have the features ... I want to use": That is
enough for my small auxiliary programs. For the big programs I am
involved in the question is rather: Do (almost) all compilers have this
feature such that we can dare to use it? For one project the answer is:
Fortran 90 is OK, most but not all Fortran 95 is OK; allocatable
components - not yet. Fortran 2003's command line argument reading and
TYPE(C_PTR) are acceptable, but need (via conditional compiling) a fall
back. Thus, it makes a difference if only, e.g., NAG has a feature or
also, e.g., ifort and gfortran.

Tobias


* Regarding the performance: Both looking at individual tests and at the
geometric average of the Polyhedron test suite, it is not too difficult
to find commercial compilers which are similarly fast or even slower
than gfortran (cf. http://www.polyhedron.com/compare0html) - though it
is on average never the fastest. And increasing the performance is also
one goal. Having - especially on more exotic hardware - not only one
compiler installed gfortran can also be useful: If one compiler has a
bug, another one can be used. (Happened to a colleague of mine on a HPC
system, where the vendor compiler had a bug and gfortran was used [with
the vendor LAPACK/BLAS libary]; eventually the vendor compiler was
fixed, but it took several months.)

Jared Ahern

unread,
Jul 8, 2009, 6:27:14 PM7/8/09
to
On Jul 8, 2:32 pm, Damian <dam...@rouson.net> wrote:

> From what I can tell, Intel 11.1 has almost everything I want.  The
> biggest missing piece for my work is type-bound operators.

Yes I agree, Intel 11.1 does seem to have a majority of the F03
features I'm in need of the most. Beware though, I have experienced
several ICEs (filed), mainly related to polymorphic CLASS(...)
variables and allocations. Hopefully a bugfix rev is forthcoming.

For me, Intel implementing F03 is very useful, as the only compilers
really on my radar are Intel, g95, gfortran, and NAG; and I only had
NAG available on one machine. I keep writing F03 snibbits for NAG and
coarray bits for g95 that would be terribly useful if only I could use
them on more than one compiler! Oh well, soon.

Jared

Dan Nagle

unread,
Jul 10, 2009, 11:16:00 AM7/10/09
to
Hello,

On 2009-07-08 11:58:33 -0400, Bil Kleb <Bil....@nasa.gov> said:
> The standards committee could remove this inconsistency by
> specifying a ranked priority for new feature additions or
> update the standards more frequently, i.e., smaller iterations?

That's not a bad thought, but ...

It is likely better policy to let the vendors
mind their own shops than to try to enforce
a global development plan. Different vendors
have different goals and budgets, and consensus
would be difficult to get, and likely unenforceable
anyway.

Working to a five year development schedule
for the revision of standards is very hard.
I doubt we could go faster, even if the revision
were smaller. There's just a lot of hoops
to jump through.

I believe there will be a pause in the schedule
of revision now, with only f08 and the TRs in the pipe
being published in the foreseeable future. WG5
has resolved to consider no new features until
after 2012, to allow time for implementation
of what we have.

J3 will be busy with Interpretations, and corrections
and improvements to wording.

--
Cheers!

Dan Nagle

Dan Nagle

unread,
Jul 10, 2009, 12:05:03 PM7/10/09
to
Hello,

On 2009-07-08 13:41:13 -0400, Steve Lionel <steve....@intel.invalid> said:

> The reason vendors ask about priorities is that we want to implement
> first what our customers want most. All of us have finite development
> resources and implementing all of F2003 is a LOT of work. In addition,
> it would appear that some F2008 features (submodules and co-arrays to
> name just two) are of more interest to the majority of our customers
> than some of the remaining F2003 features (user-defined derived type
> I/O to name one.) Would you prefer to wait for submodules while we
> finish UDDTIO? Most of the customers we ask say "no".

To me, this is the crux of it.

Some features of f03 simply have a lower benefit/cost ratio
than others. Coarrays are necessary to program any
modern commodity processor beyond those used mostly
in cell phones. Submodules address the compilation cascade
issue, among other uses.

> We will get all of F2003, eventually. I'd say that, today, we (Intel)
> have nearly all of the important bits. I think the question to ask is
> "does compiler X now have the features from F2003 that I want to use in
> my application?" If it does, then the fact that it doesn't support
> every piece of F2003 is perhaps not as important.

Yes. To me, the idea that a vendor must have
every last piece of f03 when the customers want
something from f08 is excessive bureaucratic nitpicking.

YMMV

--
Cheers!

Dan Nagle

Gordon Sande

unread,
Jul 10, 2009, 1:54:19 PM7/10/09
to
On 2009-07-07 10:11:24 -0300, Beliavsky <beli...@aol.com> said:

> http://www.springer.com/computer/programming/book/978-1-84882-542-0
> Guide to Fortran 2003 Programming
> Brainerd, Walter S.
> 2009, X, 357 p. 34 illus., Hardcover
> ISBN: 978-1-84882-542-0
> $79.95


Any indication when the softcover version might become available?

On some other titles the premium for hardcover is rather steep.
This book would be much more attractive in softcover. I would rather
see royalties for Walt Brainerd than wages for bookbinders.


fj

unread,
Jul 11, 2009, 5:53:08 AM7/11/09
to
On 9 juil, 00:27, Jared Ahern <jared.ah...@gmail.com> wrote:
> On Jul 8, 2:32 pm, Damian <dam...@rouson.net> wrote:
>
> > From what I can tell, Intel 11.1 has almost everything I want.  The
> > biggest missing piece for my work is type-bound operators.
>
> Yes I agree, Intel 11.1 does seem to have a majority of the F03
> features I'm in need of the most.  Beware though, I have experienced
> several ICEs (filed), mainly related to polymorphic CLASS(...)
> variables and allocations.  Hopefully a bugfix rev is forthcoming.
>
> For me, Intel implementing F03 is very useful, as the only compilers
> really on my radar are Intel, g95, gfortran, and NAG; and I only had

Same compilers for me plus, sometimes, Sun Fortran.

I used LF95 in the past. But I should give up two years ago because of
no F2003 extensions (except TR15xxx). Since 2000, Lahey does not
extend its compiler anymore (sticked to F95+).

Only F2003 features supported by all these five compilers are used in
my company. The main one is presently the iso C binding. Parts which
need procedure pointers are written in C. This is not as nice as the
corresponding F2003 feature, but it works well thanks to the iso c
binding.

Another useful extension is OpemMP. Only g95 does not support it but
this lack has no tragic consequence because OpenMP instructions are
just special F90 comments ...

I would like to use F2008 extensions too, like sub-modules and
coarrays. Object oriented features are interesting but seem a little
bit complicated to learn by scientists who are not expert in computer
science. A better language is JAVA to get the "feeling" which such
programming technique.

Richard Maine

unread,
Jul 11, 2009, 2:47:51 PM7/11/09
to
fj <franco...@irsn.fr> wrote:

> Object oriented features are interesting but seem a little
> bit complicated to learn by scientists who are not expert in computer
> science. A better language is JAVA to get the "feeling" which such
> programming technique.

Except that the f2003 object-oriented features are pretty carefully
integrated into Fortran in a way that fits "naturally", at least to this
Fortran programmer for 40 years. That was a deliberate and fairly
carefully worked on integration. I found it a lot easier to learn object
oriented concepts as natural enhancements of Fortran, and even
recognizable as things I had tried to do in Fortran before I knew that
there were language features that could help instead of fight it.

I'd expect other Fortran programers to simillarly find it easier to
learn the F2003 object oriented features than to learn the concepts in a
whole different language and then try to figure out how those concepts
relate to Fortran. That was sure the case for me and I can't believe I'm
completey alone in it.

No, object orientation isn't the first thing I'd try to learn in Fortran
(another design decision pretty much unanimously agreed on was that the
object oriented stuff would fit into Fortran rather than recasting
Fortran to fit inside of object orientation, so you don't have to start
with object orientation to learm Fortran - there was one proposal to the
contrary, but it got almost no support), but if you have learned how to
do other things in Fortran, I'd look at the F2003 object oriented stuff
when the tme came for those concepts.

Gary Scott

unread,
Jul 11, 2009, 9:28:06 PM7/11/09
to
Richard Maine wrote:

That's a very good thing, i just don't think in object oriented terms
naturally when programming.

--

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

mecej4

unread,
Jul 12, 2009, 12:35:30 AM7/12/09
to

"Gary Scott" <garyl...@sbcglobal.net> wrote in message
news:N_a6m.7370$cl4....@flpi150.ffdc.sbc.com...
> Richard Maine wrote:
>
<--CUT-->

> No, object orientation isn't the first thing I'd try to learn in Fortran
>> (another design decision pretty much unanimously agreed on was that the
>> object oriented stuff would fit into Fortran rather than recasting
>> Fortran to fit inside of object orientation, so you don't have to start
>> with object orientation to learm Fortran - there was one proposal to the
>> contrary, but it got almost no support), but if you have learned how to
>> do other things in Fortran, I'd look at the F2003 object oriented stuff
>> when the tme came for those concepts.
>>
> That's a very good thing, i just don't think in object oriented terms
> naturally when programming.
>

Given that, I suspect that you would, as do many of us, rather make/order
the saw to cut the tree branch rather than ask the tree to serve up its
self.branch.cut() method.

I have found it amusing that some languages don't allow declaring an array
of user-defined type, insisting on a loop in which the constructor method is
called once for each array element.

-- mecej4
>


Damian

unread,
Jul 22, 2009, 7:46:42 AM7/22/09
to

I just discovered one other feature missing from Intel Fortran 11.1
that is very important to my work: final subroutines. This is useful
on my two main projects for different reasons: (1) mixed-language
programming involving Fortran interfaces to C++ objects wherein one
needs to write Fortran final subroutines that invoke C++ destructors
[using the C interoperability features of Fortran 2003] and (2) the
aforementioned "abstract data type calculus" wherein one needs to free
any pointers allocated inside derived types that were created to hold
intermediate results as part of evaluating an expression based on
defined operators. In the latter case, I can almost always substitute
allocatable entities for the pointers and avoid the need for final
subroutines altogether. In the former case, however, no such option
exists and I have to resort to reference counting, which is clunky and
has some potential pitfalls.

Damian

Damian

unread,
Jul 22, 2009, 8:05:34 AM7/22/09
to
On Jul 22, 4:46 am, Damian <dam...@rouson.net> wrote:

And while I'm at it, one more missing feature (this one is minor): the
ability to declare generic procedures with the same name as a type
defined in the same module. (I believe this is described in section
17.1 in Metcalf, Reid & Cohen but I don't have my copy with me). An
example would be

module foobar
implicit none
type foo
integer :: bar
end type

interface foo
module procedure constructor
end interface

contains
type(foo) function constructor()
constructor%bar=1
end function
end module

The nice thing about such a feature is it enables the definition of
constructors that employ the same syntax as the intrinsic structure
constructors. This is especially useful with the intrinsic structure
constructors are unavailable because the components are private and
don't have default values (which is virtually always the case in my
codes). Obviously, the workaround is simple. I employ an idiom from
Akin's book on object-oriented Fortran: I add trailing underscores to
all of my constructor names, which is of course no big deal except
that it's less immediately intuitive to those who expect constructors
to have the same name as the type (which is likely true of those
coming from some other object-oriented languages).

Damian

0 new messages