Fortran and .NET (C#)

[apm]

All:

Has anyone noticed the similarities between C# and Fortran 90, particularly
in aspects where Fortran 90 and C++ differ? I seem to remember Fortran 90
allowing arrays to be returned by functions. Was there "garbage collection"
in Fortran 90 or was there reference counting? Rather than C/C++ like
pointers, are pointers in Fortran 90 more similar to references and
reference types in C#?

[Richard Maine]

Post by apm
I seem to remember Fortran 90
allowing arrays to be returned by functions. Was there "garbage collection"
in Fortran 90 or was there reference counting?

No. And no. Neither one. Compilers *may* do such things, but that is
completely optional (and most compilers don't, though a few do).

For functions returning arrays that are either explicit-sized or
allocatable (the allocatable case isn't allowed until f2003 or f95+TR),
the language is designed such that you don't need either of those. The
language makes it well-defined exactly when any such allocated storage
gets released. No reference counts or garbage collection is needed.

For functions returning pointers.... well.... I strongly recommend
against doing that (and have so in several previous posts here). Even if
you are an expert, the odds are high of screwing it up and leaking
memory or having other bugs. And if one is a novice, well, one pretty
much abandons all hope of a bug-free program if one uses functions that
return pointers. I recommend using subroutines for all cases where a
pointer needs tobe returned (return it via an argument).

Recall that, unlike C, Fortran doesn't force you into using pointers
just because you have arrays. So don't equate functions returning
pointers with functions returning arrays in Fortran. (Though
allocatables are hobbled enough prior to the f95 TR that you end up
using pointers as a workaround a lot more often than desirable;
hopefully, such workarounds will gradually fade away in the future).

Post by apm
Rather than C/C++ like
pointers, are pointers in Fortran 90 more similar to references and
reference types in C#?

I don't know boo about C#, but I've been told that F90 pointers are
somewhat like Java reference types, so if C# ones are anything similar,
that might also be a reasonable comparison.

[apm]

Post by Richard Maine

I seem to remember Fortran 90 allowing arrays to be returned by
functions. Was there "garbage collection" in Fortran 90 or was there
reference counting?

No. And no. Neither one. Compilers *may* do such things, but that is
completely optional (and most compilers don't, though a few do).
For functions returning arrays that are either explicit-sized or
allocatable (the allocatable case isn't allowed until f2003 or f95+TR),
the language is designed such that you don't need either of those. The
language makes it well-defined exactly when any such allocated storage
gets released. No reference counts or garbage collection is needed.
For functions returning pointers.... well.... I strongly recommend against
doing that (and have so in several previous posts here).

Is it true that memory that a Fortran pointer "points" to may not be
reclaimed when the pointer goes out of scope? This would be like C/C++ or
worse.

Post by Richard Maine
Recall that, unlike C, Fortran doesn't force you into using pointers just
because you have arrays. So don't equate functions returning pointers with
functions returning arrays in Fortran.

It has been my experience - which includes much mixed-language programming -
that Fortran and C arrays are very similar. Both C and Fortran actually
return the address of the first element when returning an array. (One very
annoying problem, however, is that while in Fortran A(3) when returned
returns an address and in C/C++ A[2] when returned returns a copy of the
element. A is an array.)

Post by Richard Maine
(Though allocatables are hobbled enough prior to the f95 TR that you end
up using pointers as a workaround a lot more often than desirable;
hopefully, such workarounds will gradually fade away in the future).

Rather than C/C++ like pointers, are pointers in Fortran 90 more similar
to references and reference types in C#?

I don't know boo about C#, but I've been told that F90 pointers are
somewhat like Java reference types, so if C# ones are anything similar,
that might also be a reasonable comparison.

C# and Java garbage collect. Visual Basic reference counts. C/C++ does
neither. Anything allocated has to be deallocated. I hate to admit it but I
am not sure what Fortran does. If this is not specified in the standard than
something is wrong.

Post by Richard Maine
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

[Richard E Maine]

Post by apm
Is it true that memory that a Fortran pointer "points" to may not be
reclaimed when the pointer goes out of scope?

That's correct.... and, if anything an understatement. It *will* not be
reclaimed in most implementations. And for that matter, the standard
requires that it *shall* not if there are still other pointers to it. So
saying "may" not is an understatement. Closer would be that the space
might happen to get reclaimed if you are lucky to be in just the right
kind of case and are using one of a small handful of compilers - but it
probably won't. Compilers are allowed to reclaim the space (in some
cases), but most don't even when they are allowed to.

Yes, you can get in trouble this way, and many others, using pointers.
As mentioned before, there are many ways to get in trouble using
pointers; this is only one of them. F90 pointers have several aspects
that improve safety relative to C pointers, but avoidance of memory
leaks isn't one of them.

Post by apm
It has been my experience - which includes much mixed-language programming -
that Fortran and C arrays are very similar.

Well my experience is that they are worlds different. Indeed, one
significant difference is one you just called attention to above. As you
notice and comment negatively on, pointers (both in C and in Fortran)
are subject to memory leak problems. In contrast, you can't generate a
memory leak with a Fortran array that isn't a pointer, no matter how
hard you try. Do you think memory leaks are a significant issue or not?
From the rest of your post, it sounds like you do. But if you think that
Fortran arrays are like C pointers, you are ignoring that as though it
were unimportant. Seems contradictory.

Oh. And others have commented here and elsewhere *extensively* about the
optimization-related differences between C and Fortran and arrays. There
is even significant work aimed at fixing this problem in C, though I
forget the details of the status of that work.

Post by apm
Both C and Fortran actually
return the address of the first element when returning an array.

This makes it apparent that you must be talking about Fortran 77, or at
least the Fortran 77-compatible subset of f90. Other f90 arrays (such as
pointers, allocatables, assumed shape, and slices) cannot plausibly be
implemented that way.

The differences between f77 and f90 arrays are huge - too much to
describe here.

Post by apm
If this [garbage collection or the like] is not specified in the
standard than something is wrong.

I'll not persist in arguing the point (though I disagree). Seems like a
pointless debate about past history. (And I don't think there are enough
odds of this changing in the forseeable future to make it worth debating
from that standpoint either).

I suspect it partly indicates that you would use pointers in more places
than I consider it advisable in Fortran code (at least now that
allocatables are half decent). If you don't see much difference between
Fortran arrays and C arrays/pointers, and therefore figure that you
might as well use Fortran pointers as freely as arrays, well... I think
you are digging your own hole if you then notice that the result shares
some of the problems of C pointers. Yes, if you do that, it will hurt.
My recommended solution is to not do that.

Oh, and I will note that a bit over 15 years ago when I first asked some
of our real-time simulation folk here about any comments they might want
submitted on the final draft of the f90 standard, there was only one
question they asked me. Having noticed that there were pointers and
dynamic allocation, they said "It isn't going to require garbage
collection, is it? That would be completely unacceptable in our
real-time applications."

[apm]

Post by Richard E Maine

Post by apm
Is it true that memory that a Fortran pointer "points" to may not be
reclaimed when the pointer goes out of scope?

That's correct.... and, if anything an understatement. It *will* not be
reclaimed in most implementations. And for that matter, the standard
requires that it *shall* not if there are still other pointers to it.
So
saying "may" not is an understatement. Closer would be that the space
might happen to get reclaimed if you are lucky to be in just the right
kind of case and are using one of a small handful of compilers - but it
probably won't. Compilers are allowed to reclaim the space (in some
cases), but most don't even when they are allowed to.
Yes, you can get in trouble this way, and many others, using pointers.
As mentioned before, there are many ways to get in trouble using
pointers; this is only one of them. F90 pointers have several aspects
that improve safety relative to C pointers, but avoidance of memory
leaks isn't one of them.

Post by apm
It has been my experience - which includes much mixed-language programming -
that Fortran and C arrays are very similar.

Well my experience is that they are worlds different. Indeed, one
significant difference is one you just called attention to above. As you
notice and comment negatively on, pointers (both in C and in Fortran)
are subject to memory leak problems. In contrast, you can't generate a
memory leak with a Fortran array that isn't a pointer, no matter how
hard you try.

Both Fortran pointers and allocatable arrays allow dynamic allocation. It is
the dynamic allocation that can lead to memory leaks. It is the same way
with C++. Using new without proper use of delete causes the leaks. There are
different problems with the C pointer, fewer problems with the C++ pointer,
still fewer with Fortran.

Post by Richard E Maine
Do you think memory leaks are a significant issue or not?

I've really never had problems with memory leaks myself. I've had problems
with "dangling pointers" though -- mostly with other peoples code. Strangly
enough, I've had more trouble with Fortran (that is utill I realized that
pointers had to be initialized to null) than C++. I also found that with
the Fortran I was using deallocating pointers did not always appear to
actually free memory. I suspect that deallocating just gave a garbage
collector permision to free the memory. The Fortran 90 therefore seemed to
behave like C# (and Java) does today -- returning to my original concern.

Post by Richard E Maine
From the rest of your post, it sounds like you do. But if you think that
Fortran arrays are like C pointers, you are ignoring that as though it
were unimportant. Seems contradictory.
Oh. And others have commented here and elsewhere *extensively* about the
optimization-related differences between C and Fortran and arrays. There
is even significant work aimed at fixing this problem in C, though I
forget the details of the status of that work.

Post by apm
Both C and Fortran actually
return the address of the first element when returning an array.

This makes it apparent that you must be talking about Fortran 77, or at
least the Fortran 77-compatible subset of f90. Other f90 arrays (such as
pointers, allocatables, assumed shape, and slices) cannot plausibly be
implemented that way.
The differences between f77 and f90 arrays are huge - too much to
describe here.

Post by apm
If this [garbage collection or the like] is not specified in the
standard than something is wrong.

I'll not persist in arguing the point (though I disagree). Seems like a
pointless debate about past history. (And I don't think there are enough
odds of this changing in the forseeable future to make it worth debating
from that standpoint either).
I suspect it partly indicates that you would use pointers in more places
than I consider it advisable in Fortran code (at least now that
allocatables are half decent). If you don't see much difference between
Fortran arrays and C arrays/pointers, and therefore figure that you
might as well use Fortran pointers as freely as arrays, well... I think
you are digging your own hole if you then notice that the result shares
some of the problems of C pointers. Yes, if you do that, it will hurt.
My recommended solution is to not do that.
Oh, and I will note that a bit over 15 years ago when I first asked some
of our real-time simulation folk here about any comments they might want
submitted on the final draft of the f90 standard, there was only one
question they asked me. Having noticed that there were pointers and
dynamic allocation, they said "It isn't going to require garbage
collection, is it? That would be completely unacceptable in our
real-time applications."
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

[Richard E Maine]

Post by apm

Post by Richard E Maine
pointers (both in C and in Fortran)
are subject to memory leak problems. In contrast, you can't generate a
memory leak with a Fortran array that isn't a pointer, no matter how
hard you try.

Both Fortran pointers and allocatable arrays allow dynamic allocation. It is
the dynamic allocation that can lead to memory leaks.

That is an overly broad generalization which is false. You are
attempting to generalize your previous experience with a particular
style of dynamic memory allocation. The generalization doesn't hold.

Let me repeat for the second time (at least) in this thread, and not
counting many times in previous thready. You *CANNOT* leak memory
because of a user error with Fortran allocatable arrays. That is an
intentional part of the design of Fortran allocatables. It is so much a
part of the design, that if you managed to find a way to do it, I am
confident that it would be regarded as a bug in the standard and a fix
would be published. In the many times I have explained this, not once
has anyone come up with a code sample to contradict it.

Nor, I might add, can you leak memory because of a user error with
Fortran's dynamically allocated automatic arrays.

Memory leaks are not fundamental to dynamic allocation. They are a
"feature" of using pointers (or other similar things) for dynamic
allocation.

[Brooks Moses]

Post by Richard E Maine
Let me repeat for the second time (at least) in this thread, and not
counting many times in previous thready. You *CANNOT* leak memory
because of a user error with Fortran allocatable arrays. That is an
intentional part of the design of Fortran allocatables. It is so much a
part of the design, that if you managed to find a way to do it, I am
confident that it would be regarded as a bug in the standard and a fix
would be published. In the many times I have explained this, not once
has anyone come up with a code sample to contradict it.

It occurs to me that one could perhaps argue that Fortran allocatable
arrays use a simplistic form of reference-counting garbage collection
that can be implemented with zero cost at compile time. Namely, the
language does not permit more than one "pointer" (by which I mean
allocatable array variable, not a real pointer) to refer to a given
piece of memory allocated as an allocatable array, and therefore, when a
"pointer" is dereferenced (by going out of scope, or whatever), the
compiler can assume the reference count has gone to zero and thus
deallocate the memory.

I doubt that this is a helpful way of looking at things, however.

- Brooks

[Richard E Maine]

Post by Brooks Moses
It occurs to me that one could perhaps argue that Fortran allocatable
arrays use a simplistic form of reference-counting garbage collection
that can be implemented with zero cost at compile time. Namely, the
language does not permit more than one "pointer" (by which I mean
allocatable array variable, not a real pointer) to refer to a given
piece of memory allocated as an allocatable array, and therefore, when a
"pointer" is dereferenced (by going out of scope, or whatever), the
compiler can assume the reference count has gone to zero and thus
deallocate the memory.
I doubt that this is a helpful way of looking at things, however.

I think that a possibly useful insight. Not sure where the use will pop
up, but I can imagine that it might. Connections like that are good to
see. Thanks.

[apm]

This is getting to be a poignant and pointed discussion. I stand corrected
on the issue of allocatable arrays.



David

Post by Richard E Maine

Post by Brooks Moses
It occurs to me that one could perhaps argue that Fortran allocatable
arrays use a simplistic form of reference-counting garbage collection
that can be implemented with zero cost at compile time. Namely, the
language does not permit more than one "pointer" (by which I mean
allocatable array variable, not a real pointer) to refer to a given
piece of memory allocated as an allocatable array, and therefore, when a
"pointer" is dereferenced (by going out of scope, or whatever), the
compiler can assume the reference count has gone to zero and thus
deallocate the memory.
I doubt that this is a helpful way of looking at things, however.

I think that a possibly useful insight. Not sure where the use will pop
up, but I can imagine that it might. Connections like that are good to
see. Thanks.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

[Rich Townsend]

Post by Richard E Maine

Post by apm

Post by Richard E Maine
pointers (both in C and in Fortran)
are subject to memory leak problems. In contrast, you can't generate a
memory leak with a Fortran array that isn't a pointer, no matter how
hard you try.

Both Fortran pointers and allocatable arrays allow dynamic allocation. It is
the dynamic allocation that can lead to memory leaks.

That is an overly broad generalization which is false. You are
attempting to generalize your previous experience with a particular
style of dynamic memory allocation. The generalization doesn't hold.
Let me repeat for the second time (at least) in this thread, and not
counting many times in previous thready. You *CANNOT* leak memory
because of a user error with Fortran allocatable arrays. That is an
intentional part of the design of Fortran allocatables. It is so much a
part of the design, that if you managed to find a way to do it, I am
confident that it would be regarded as a bug in the standard and a fix
would be published. In the many times I have explained this, not once
has anyone come up with a code sample to contradict it.

Further to Richard's remarks above, I should point out that my
ISO_VARYING_STRING implementation (Google is your friend) contains a number of
ALLOCATE() statements, but not a single DEALLOCATE(). Yet, the strength of the
implementation is that it will NEVER leak even a single bit of memory (unless of
course there is a bug in the compiler, but then all bets are off). The leak free
guarantee is nothing to do with my coding skills, and eveything to do with the
way in which ALLOCATABLE variables work.

cheers,

Rich

[Brooks Moses]

Post by apm
Both Fortran pointers and allocatable arrays allow dynamic allocation. It is
the dynamic allocation that can lead to memory leaks.

But it's not. Fortran allocatable arrays, unlike Fortran pointers,
cannot have memory leaks.

In general, dynamic allocation does not lead to memory leaks. What
leads to memory leaks (or to the need for garbage collection mechanisms)
is the ability to dereference a pointer without necessarily deallocating
the associated memory.

This is a crucial difference between Fortran and many other languages:
Fortran offers options for dynamic memory allocation that do not involve
dereferencable pointers, and thus do not have memory leaks.

- Brooks

[James Van Buskirk]

Post by apm
It has been my experience - which includes much mixed-language

programming -

Post by apm
that Fortran and C arrays are very similar. Both C and Fortran actually
return the address of the first element when returning an array. (One very
annoying problem, however, is that while in Fortran A(3) when returned
returns an address and in C/C++ A[2] when returned returns a copy of the
element. A is an array.)

What planet are you living on? C doesn't even have arrays, at least
until C99, which seems to be about as widely implemented as f03. For
example, if you want to write a matrix multiplication function (or any
matrix manipulation function) in C, you have to either allocate an array
of pointers to its rows, point to the first element of each row, and
pass a pointer to the first element in the array of row pointers or
compute array offsets by hand, A[n*i+j] instead of A[i][j] within
the matrix manipulation function.

As far as returning an array, if you are referring to f77, the
return had to be through an argument, so that the address of the
first element would not get returned. If f90/f95, the array
could be returned through the result variable, but the shape of
the array has to be precomputable via specification expressions.
Much more than just the address of the first element must be
returned, although everything but the element values are effectively
returned in a function prologue. This technique is also leakproof
so that it can be used within expressions, unlike what would be
the case with a C function returning a pointer.

In f03 a function can return an allocatable result, which is
more general than what is possible in f95. For example, one
could return an array or character variable that contains a
line or record of input. So I'm not sure what you mean by
returning an array in C or Fortran, but I don't see that
much similarity.

[Mr Hrundi V Bakshi]

Post by apm

Post by apm
It has been my experience - which includes much mixed-language

programming -

Post by apm
that Fortran and C arrays are very similar. Both C and Fortran actually
return the address of the first element when returning an array. (One very
annoying problem, however, is that while in Fortran A(3) when returned
returns an address and in C/C++ A[2] when returned returns a copy of the
element. A is an array.)

What planet are you living on? C doesn't even have arrays, at least
until C99, which seems to be about as widely implemented as f03. For
example, if you want to write a matrix multiplication function (or any
matrix manipulation function) in C, you have to either allocate an array
of pointers to its rows, point to the first element of each row, and
pass a pointer to the first element in the array of row pointers or
compute array offsets by hand, A[n*i+j] instead of A[i][j] within
the matrix manipulation function.
As far as returning an array, if you are referring to f77, the
return had to be through an argument, so that the address of the
first element would not get returned. If f90/f95, the array
could be returned through the result variable, but the shape of
the array has to be precomputable via specification expressions.
Much more than just the address of the first element must be
returned, although everything but the element values are effectively
returned in a function prologue. This technique is also leakproof
so that it can be used within expressions, unlike what would be
the case with a C function returning a pointer.
In f03 a function can return an allocatable result, which is
more general than what is possible in f95. For example, one
could return an array or character variable that contains a
line or record of input. So I'm not sure what you mean by
returning an array in C or Fortran, but I don't see that
much similarity.

Hear hear!

A valuable contribution to clf discourse in contrast to the more usual clf
s(p)ewing club prattle.
With f03, will dynamic arrays extend to C or is that beyond the scope of C
interop?

[Dick Hendrickson]

Post by apm

Post by apm

Post by apm
It has been my experience - which includes much mixed-language

programming -

Post by apm
that Fortran and C arrays are very similar. Both C and Fortran

actually

Post by apm

Post by apm
return the address of the first element when returning an array. (One

very

Post by apm

Post by apm
annoying problem, however, is that while in Fortran A(3) when returned
returns an address and in C/C++ A[2] when returned returns a copy of

the

Post by apm

Post by apm
element. A is an array.)

What planet are you living on? C doesn't even have arrays, at least
until C99, which seems to be about as widely implemented as f03. For
example, if you want to write a matrix multiplication function (or any
matrix manipulation function) in C, you have to either allocate an array
of pointers to its rows, point to the first element of each row, and
pass a pointer to the first element in the array of row pointers or
compute array offsets by hand, A[n*i+j] instead of A[i][j] within
the matrix manipulation function.
As far as returning an array, if you are referring to f77, the
return had to be through an argument, so that the address of the
first element would not get returned. If f90/f95, the array
could be returned through the result variable, but the shape of
the array has to be precomputable via specification expressions.
Much more than just the address of the first element must be
returned, although everything but the element values are effectively
returned in a function prologue. This technique is also leakproof
so that it can be used within expressions, unlike what would be
the case with a C function returning a pointer.
In f03 a function can return an allocatable result, which is
more general than what is possible in f95. For example, one
could return an array or character variable that contains a
line or record of input. So I'm not sure what you mean by
returning an array in C or Fortran, but I don't see that
much similarity.

Hear hear!
A valuable contribution to clf discourse in contrast to the more usual clf
s(p)ewing club prattle.
With f03, will dynamic arrays extend to C or is that beyond the scope of C
interop?

Partly. Automatic arrays can interoperate with C, but
allocatable or pointer arrays can't. That's probably
because A) Fortran pointer arrays effectively have to have
a dope vector to describe them (they don't need to be
contiguous) and C arrays are "just an address", and B)
neither side wanted to force their memory management
schemes on the other, and C) Fortran and C do array
subscripting backwards with respect to each other and
that could make dope vectors a bugger to define.

There are a few function, C_ASSOCIATED, C_F_POINTER,
and C_LOC, along with the Fortran data type C_PTR,
that let a thoughtful programmer do some
intermixing of C dynamic memory with Fortran
arrays.

Dick Hendrickson

[Dave Thompson]

On Tue, 27 Sep 2005 14:30:27 -0400, "apm"
<***@AdsorptionProcessModeling.com> wrote:
<snip>

Post by apm
Is it true that memory that a Fortran pointer "points" to may not be
reclaimed when the pointer goes out of scope? This would be like C/C++ or
worse.

First, we should distinguish between going out of scope and ceasing to
exist; Fortran SAVEd and C/C++ static local variables continue to
exist, and if pointers point to whatever, even when you return from
the subprogram declaring them. Assuming you mean a variable which is
in fact destroyed -- what C/C++ calls 'automatic' and is usually
implemented 'on the stack' -- that's true for C and for the C-like
'subset' of C++. (Strictly speaking, as comp.lang.c likes to insist,
C++ is not a superset of C. But it is a superset of most of C,
arguably and in BS' judgement 'all the good parts' of C89.)

But C++ also provides a standard-library template auto_ptr<> which
automatically deallocates the target when the necessarily unique
pointer is destroyed, just like Fortran ALLOCATABLE. Or you can write
other similar (or not!) 'smart pointer' classes if you want. Core C++
does provide the _mechanism_ of running destructor methods that enable
this to work reliably, even with exceptions.

<snip>

Post by apm
It has been my experience - which includes much mixed-language programming -
that Fortran and C arrays are very similar. Both C and Fortran actually
return the address of the first element when returning an array. (One very
annoying problem, however, is that while in Fortran A(3) when returned
returns an address and in C/C++ A[2] when returned returns a copy of the
element. A is an array.)

If you actually mean an element, the element is returned by value in
both languages (and all 3GLs I know of). If you mean an array, that
happens to be sized 3 or 2, as already noted F9X returns the whole
array (although this may be optimized to store into a caller provided
area) and C returns a pointer (to space which had better not be local
'automatic' = stack and hence now lost). Passing as an argument is
different; C always a value for nonarray type and pointer for array;
C++ the same except (effectively) pointer for reference types; Fortran
usually an address though not required and there are cases especially
in F>=90 that can be optimized to value[-return]).

<snip>

Post by apm
C# and Java garbage collect. Visual Basic reference counts. C/C++ does
neither. Anything allocated has to be deallocated. I hate to admit it but I
am not sure what Fortran does. If this is not specified in the standard than
something is wrong.

Again in C++ you can write classes that do/provide refcounting. The
standard-library string<> (and wstring<> and basic_string<>) can be
and sometimes are implemented as refcounted. It's not core though.

- David.Thompson1 at worldnet.att.net