Re: Fortran and .NET (C#)


"Richard E Maine" <nospam@xxxxxxxxxxxxx> wrote in message
news:nospam-0B071C.12183427092005@xxxxxxxxxxxxxxxxxxxxx
> In article <bdg_e.24065$nq.9634@lakeread05>,
> "apm" <Contributor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
>> 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.
>
>> 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.

>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.

> 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.
>
>> 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.
>
>> 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


.

Relevant Pages

  • Re: Cracking DES with C++ is faster than Java?
    ... > C doesn't have multidimensional arrays, ... you must use pointers to pointers instead, ... properties from Fortran (efficient code, separate compilation, ... However C didn't borrow object orientation ...
    (comp.lang.java)
  • Re: Cracking DES with C++ is faster than Java?
    ... > C doesn't have multidimensional arrays, ... you must use pointers to pointers instead, ... properties from Fortran (efficient code, separate compilation, ... However C didn't borrow object orientation ...
    (comp.lang.cpp)
  • Re: Cracking DES with C++ is faster than Java?
    ... > C doesn't have multidimensional arrays, ... you must use pointers to pointers instead, ... properties from Fortran (efficient code, separate compilation, ... However C didn't borrow object orientation ...
    (sci.crypt)
  • Re: INTERFACE problem
    ... I have an integer at Fortran side, pass it by reference to C function, treat here as pointer, allocate memory and this C-pointer at Fortran side now is an integer which has represents address allocated at C side. ... I did something like this many years ago to allow dynamic allocation ... Then it was converted into a subroutine with the arrays and ... it called the sub by way of Pascal with those "pointers". ...
    (comp.lang.fortran)
  • Re: INTERFACE problem
    ... I have an integer at Fortran side, ... >it by reference to C function, treat here as pointer, allocate memory ... C pointers and arrays ... WHen the Main got the now initialized "pointers" ...
    (comp.lang.fortran)