Re: allocatable non-dummy local variables and pointers to them

On Sep 27, 5:27 pm, nos...@xxxxxxxxxxxxx (Richard Maine) wrote:
e p chandler <e...@xxxxxxxx> wrote:

1. If I comment out the "deallocate(c)" do I get a memory leak?

Yes.

Is this memory recovered when the process terminates
(I'm on Windows - 9x/XP/Vista)?

Presumably. Much as I dislike Windows, I assume it can't be quite so bad
as to not do that.

That's basically an OS question, completely independent of languages. In
order to be even half viable in a general-purpose environment, an OS
must release the memory used by a process when the process terminates.
The OS can't depend on the process shutting itself down nicely. Any OS
that didn't handle that well would run out of memory so rapidly as to be
pretty much unuseable. Every time a program ended other than normally,
you'd have to reboot the OS. Of course, for systems without memory
protection, that's pretty much the normal rule anyway because memory
content might have gotten trashed.

No matter what the rules of the language are, there will be programs
that violate them. And there will be compilers that make errors too. It
is one of the most basic tenets of OS design that the OS has
resposibility for that kind of memory management. It can't just ask all
the programs running under it to "please be nice and make sure to clean
up after yourself." That just doesn't work - not in a general-purpose
environment.

I do remember that Fortran Powerstation 4.0 did have a memory leak
problem, but I can not remember if that leak surviced process
termination. My somewhat fualty memory says that the leak persisted.


2. I recently purchased a copy of DVF 5.0. Is it going to behave like
Fortran 90 or Like Fortran 95 with respect to having to deallocate an
allocatable?

I might have a copy somewhere to check, but I'd have to go dig it
out.... Ah. I misrecalled what version that was. That's a version 6.0.
Hmm, it says it is an upgrade and I've even got a note of my 5.0 serial
number, but I don't see the 5.0 docs. Perhaps I tossed them in favor of
the 6.0 ones.

Didn't yours come with any documentation at all? You needn't dig into
the details, but I'd hope it would be pretty explicit and not need
digging to find whether it claims to be an f90 or f95 compiler.

My legitimately purchased copy came on CD w/o printed docs. The on-
disk docs are in an internal format read from the IDE. Said IDE does
not like Vista or XP. I'm too tired to bring up a Win 9x machine for
this...

Anyway, I did find a pdf of the programmer's guide floating around in
the ether ... It makes no categorical statement about the compiler
being Fortran 95, but it says "This section briefly describes the
Fortran 95 language features that have been implemented by Visual
Fortran". Lower down it says "Arrays declared using the ALLOCATABLE
attribute can now be automatically deallocated in
cases where Fortran 90 would have assigned them undefined allocation
status."

If it's an f95 compiler, then it will follow the f95 rules.

If it's an f90 one, then all bets are off. As with the large majority of
language developments, the rules are such that code conforming to the
older rules also conforms to the newer ones. The f90 rules on this lay
all the burden on the programmer. There are no rules for how the
compiler has to behave for allocatables that get undefined allocation
status. It is just up to the user to never again "touch" such an
allocatable. If the user does so, then the usual WWIII rule applies (the
compiler can do anything, including start WWIII).

So this particular point is covered.

- e



.

Relevant Pages

  • Re: Mex Overflow Error Using Free Borland Compiler
    ... > I need help eliminating the source of the following Mex runtime error. ... > Borland compiler handles overflow errors. ... > The first thing I tried is dynamic memory allocation. ...
    (comp.soft-sys.matlab)
  • Re: Benchmark: STLs list vs. hand-coded one
    ... bound - in fact it is hard to find anything in a compiler that isn't ... allocation bound (perhaps the scanner as it spends a rather large ... How many people have a Gbyte of memory? ... seems to have a gig of RAM. ...
    (comp.arch.embedded)
  • Re: Integer Coersion
    ... and as this is Fortran not Delphi, ... vaguely standard conforming. ... Your compiler supports SIZEOF as do several others including my ... to be other than 8bits when cheap memory came on the scene and BURIED ...
    (comp.lang.fortran)
  • Re: Heap? what does it mean?
    ... What does a heap mean?I mena when it says, the memory ... > in an area reserved by your compiler to serve static allocations(sometimes ... > a) this allocation isn't destroyed at the end of the scope its in. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: 64-bit memory consumption
    ... because of GC memory compaction, ... *improved* over manual allocation. ... Well, this doesn't really have to be expected, 'old' compiler technology ... server, your cache is shared by multiple applications, and you can't ...
    (borland.public.delphi.non-technical)