comp.lang.fortran Google Group

Re: Should anyone be using 'modern' Fortran any more?

n...@non.net (dpb) — Wed, 22 May 2013 20:49:28 UT

...

I've been away so just happened on the thread, but...

I think that those are absolutely the wrong measuring sticks by which
Fortran (or any programming language, for that matter) will be taught in
university. It is far more likely to be taught for pedagogical reasons
that are related to advancing concepts of data abstraction, algorithm

Re: Who says I need a result variable?

w...@swcp.com (Walt Brainerd) — Wed, 22 May 2013 18:45:24 UT

What you are talking about is alternate return for subroutines.
The objection was a possible conflict/confusion with alternate returns
for functions, which, as far as I know, have never been standard,
let alone obsolescent.

Sorry, but some compilers (maybe not IBM--don't know) did allow
alternate return for functions as an extension to the standard.

Re: mktemp is dangerous, ifort

francois.j...@irsn.fr (fj) — Wed, 22 May 2013 18:39:23 UT

Yes, this is why I preferred to stick to mktemp...

Re: Should anyone be using 'modern' Fortran any more?

g...@ugcs.caltech.edu (glen herrmannsfeldt) — Wed, 22 May 2013 17:19:32 UT

In the Fortran I days, only one program ran at a time, so the
available memory was pretty well defined. That was not so far off
in the Fortran 66 days, but by Fortran 77 virtual memory multi-user
systems were common, where the available memory is much less well
defined.

Often you want to know the available real memory, to avoid page

Re: Should anyone be using 'modern' Fortran any more?

l...@winsim.com (Lynn McGuire) — Wed, 22 May 2013 16:57:41 UT

Good for you! Just not interested here
in continuing the Fortran battles.

Lynn

Re: Should anyone be using 'modern' Fortran any more?

f...@bar.invalid (JB) — Wed, 22 May 2013 16:30:53 UT

There are a number of things one can do here, with varying degrees of
unportableness. E.g.:

- getrusage() (POSIX, though on Linux the maxrss field is filled only
with kernel 2.6.32+)
- mallinfo() (GLIBC, assuming your Fortran compiler implements
(de)allocate via malloc()/free()))
- Read /proc/self/status (Linux-specific)

Re: Should anyone be using 'modern' Fortran any more?

aerospace...@gmail.com — Wed, 22 May 2013 16:32:23 UT

And you've been doing it for at least 5 years. That would be a ton of time to teach and hone new Fortran programmer's skills Fortran is indeed coming back. It is extremely interoperable. I'm doing several large projects (>100,000 lines) that tie Fortran and C++ together...

Re: Should anyone be using 'modern' Fortran any more?

l...@winsim.com (Lynn McGuire) — Wed, 22 May 2013 15:49:55 UT

No. It is time to move to C / C++. On older F77
programs that do not use many extensions, you can
use such translation programs as FOR_C:
[link]

Unfortunately, our software uses the old zero
initialization of all local and global variables
so moving 800K lines of F77 code to C++ has been a

Re: static compilation

ja...@idontlikespam.dkrz.de (Thomas Jahns) — Wed, 22 May 2013 15:20:13 UT

Not really, linking with a static libc is no longer supported on Linux because
of the way nsswitch works, i.e. the resulting binary might work but is no more
portable to other systems (depends on the systems nsswitch configuration) than a
dynamically linked binary.

Since this problem does not apply to libgfortran, libm and libquadmath you might

Re: mktemp is dangerous, ifort

bur...@net-b.de (Tobias Burnus) — Wed, 22 May 2013 15:17:58 UT

How about:
OPEN(..., status='scratch')

That's more portable and simpler than calling mktemp manually.

In case of gfortran, it calls internally mkstemp (if available) or
mktemp. (For the latter it checks whether the file already exists and
takes care of the 26-files limit per thread (and template pattern),

Re: SHA-1 in FORTRAN

zbeek...@gmail.com (Zaak) — Wed, 22 May 2013 15:13:22 UT

So, from a standards/Fortran perspective, it seems that the biggest sticking point is that there is no unsigned integer arithmetic guaranteeing that addition is modulo 2^w where w is the number of bits in your integer representation. I believe all the other operations specified in SHA1 and SHA2 are natively supported by the standard.

Re: mktemp is dangerous, ifort

arjen.markus...@gmail.com (Arjen Markus) — Wed, 22 May 2013 14:57:49 UT

Op woensdag 22 mei 2013 14:37:47 UTC+2 schreef fj het volgende:

Calling it should be easy enough, but the result is a file descriptor,
which is meaningless in Fortran. You would need a way to translate the
C-style file descriptor to a Fortran-style LU-number.

Regards,

Arjen

Re: Should anyone be using 'modern' Fortran any more?

f...@bar.invalid (JB) — Wed, 22 May 2013 13:47:00 UT

There are a number of things one can do here, with varying degrees of
unportableness. E.g.:

- getrusage() (POSIX, though on Linux the maxrss field is filled only
with kernel 2.6.32+)
- mallinfo() (GLIBC)

In practice it seems what is done is that the input file contains
various parameters specifying the system size, and then users do

Re: Should anyone be using 'modern' Fortran any more?

f...@bar.invalid (JB) — Wed, 22 May 2013 13:34:02 UT

My argument was about the usefulness of Fortran for writing new code,
be it for writing major applications or for education
purposes. Whether one should use newer language features, and if so to
which extent, when adding functionality to an existing program is of
course another interesting question.

Re: mktemp is dangerous, ifort

francois.j...@irsn.fr (fj) — Wed, 22 May 2013 12:37:47 UT

No !

the call to mktemp is performed in libpthread.a which is a "system" library.

Notice that this is simply a warning. I get the same one in my programs for years without trouble... But in my case, I am responsible of that because my programs actually call mktemp.

Using mkstemp is certainly safer but I was unable to call it from a FORTRAN program (mktemp, on the contrary is easy to call).