Re: Fortran and .NET (C#)

Richard E Maine wrote: 
In article <Vvh_e.24109$nq.10607@lakeread05>,
 "apm" <Contributor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:


"Richard E Maine" <nospam@xxxxxxxxxxxxx> wrote in message news:nospam-0B071C.12183427092005@xxxxxxxxxxxxxxxxxxxxx 


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
.

Relevant Pages

  • mem leaks in dcmqrscp
    ... memory leak reporting tools, such as Purify, to ... Distribution of leaked blocks ... Allocation location ...
    (comp.protocols.dicom)
  • Re: Interpreting Visual C++ Object Dump.
    ... I have a MFC program created in Visual Studio 6.0. ... > I have little in interpretting object dump in this environment. ... In MFC projects everything is already set up to enable memory leak detection. ... This is the "allocation request number", the serial number of the allocation ...
    (microsoft.public.vc.debugger)
  • Re: ZFS committed to the FreeBSD base.
    ... I don't see any evidence of a memory leak during the several days of testing leading up to the panic. ... How many days it took to happen would vary with the size of the kernel map, but no evidence of a leak prior to the crash. ... Also, the same server code, works fine for months on FreeBSD4 and OpenBSD3.9. ... mallocis actually implemented using two different back-ends: UMA-managed fixed size memory buckets for small allocations, and direct page allocation for large allocations. ...
    (freebsd-current)
  • Re: [PATCH 1/2] slub: fix leakage
    ... Fix the memory leak that may occur when we attempt to reuse a cpu_slab ... situation we may overwrite the per cpu freelist pointer loosing objects. ... This only occurs if we find that the concurrently allocated slab fits ... our allocation needs. ...
    (Linux-Kernel)
  • Re: Fortran and .NET (C#)
    ... >> pointers (both in C and in Fortran) ... >> are subject to memory leak problems. ... > Both Fortran pointers and allocatable arrays allow dynamic allocation. ...
    (comp.lang.fortran)