Re: access / freeing memory

["David Thompson" <david.thompson1@worldnet.att.net>]

A slight clarification:

Darren New <dnew@san.rr.com> wrote :
(other good stuff about memory allocation/management snipped)
...
> > > You can
> > > usually do stack, rather than heap, allocation which buys automatic,
> > > safe, deallocation, and of course speed.
...
> He means usually you can allocate a local variable with a
> declare...begin...end (which allocates information on the CPU's stack)
> rather than using "new" to allocate something and then specifically have to
> free it up. He's basically comparing how you do variable-sized objects in
> Ada to how you do variable-sized objects in C (which has no variable-sized
> objects, so you have to use "new" (aka malloc) to allocate them) or Java
> (which has all objects allocated from the heap, so can't put them on the
> stack for efficiency).
>
In C you have malloc (and calloc and realloc) which only allocates
raw memory (and for calloc initializes it to all zero bits, which is
often but not required to be a useful value such as a zero integer,
null pointer, etc.), and free which deallocates it.  Some implementations
also have alloca(), which allocates variable-sized space on the stack
in the current function's (subprogram's) frame, but this is nonstandard.

In C++ you can still use the C forms, but also have 'new' which
allocates memory _and runs a (possibly trivial) constructor for the
new object's type_ and 'delete' which _runs the destructor and_
frees the underlying memory.  (Actually you also have placement
new which _only_ runs the constructor, using memory you have
allocated by other means, but that's just confusing the issue.)
The memory allocation and deallocation part of 'new' and 'delete'
typically is actually done by malloc and free, but this is not required.

And in C99 (and perhaps in some future C++), AFAIK not yet
implemented outside gcc (where it was already an extension),
you can have local (stack) _arrays_ with runtime/nonstatic sizes,
called logically enough Variable Length Arrays.  But not similarly
for the other things Ada discriminated and/or private types can do.

In the Java spec it is certainly true that all objects (of nonprimitive
types) are on the heap.  However, for an object that is actually
used only locally within one function, it is my understanding that
a decent "real" (native) compiler can actually put it on the stack,
which the resulting efficiency gains.  I'm not sure if it's practical
for a JIT to do the same, but it's presumably at least permitted.

--
- David.Thompson 1 now at worldnet.att.net