×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Adam Glauser wrote:
As Scott pointed out, when you use %alloc and %realloc "RPG isn't going
to manage it's storage for you!! You have to manage it yourself." As I
understand it, the memory is allocated from a "heap" which is scoped to
the job.
Yes, it's allocated from the heap.
But, it's scoped to the activation group, not the job.
So, there's no danger of the memory being deallocated automatically.
It's not in automatic storage. If you don't manually deallocate it,
it'll stay around until the activation group ends.
Since most folks never end their activation groups (except when the job
ends) that places quite a bit of pressure on you to make sure you
deallocate everything you allocate, even if errors occur, or unexpected
things happen. Otherwise, you've created a "memory leak".
That, plus the complexity, is the reason I'd avoid this sort of
technique, and as Adam said, it's also the reason I'd advise letting the
caller handle the storage, unless you can encapsulate the whole thing
into the procedure(s).
The caller doesn't need to know the exact number of elements ahead of
time... it just needs to know the maximum number of elements that it is
willing to handle. The procedure can figure out the number of elements
and pass that information back (in my example, it used the return value
to do that)
But, again, the way you're doing it is safe (other than the fact that
you don't tell the caller how many elements you've provided). It's
cumbersome, and complicated, but there's no risk (that I can see) of the
OS freeing up your memory for you.
midrange.com
