RE: Using STATIC

[Jim Langston <jlangston@xxxxxxxxxxx>]

Actually, even with your given scenario, it is possible to still pass a
pointer and have the calling function change the memory size.  Using C it
could malloc/demalloc/remalloc.  But the pointer would be "owned" by the
calling function, not the called function.

Given this, when would you see a good time to return a pointer to memory
"owned" by a called function?

Regards,

Jim Langston

-----Original Message-----
From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]

<SNIP>

> The way around this is to have the calling module set up memory
> before hand
> and pass a pointer to it into the function.  Returning a pointer
> to a system
> object or class is not considered private storage, it is available outside
> of that function.

This is not necessarily the best solution.  This solution implies that the
calling method knows how much memory to allocate, and thus binds the caller
to the callee.  If it is instead the job of the called method to allocate
the memory, then only that method needs to know how much memory to allocate.
Of course, this is only valid in the situation where the entire contents of
the generated object are unknown to the caller, but that's pretty much the
entire concept behind object oriented programming.

I ought to do a primer someday on using RPG procedures to mimic OO behavior.
It's actually quite fascinating, and relatively easy to accomplish.  Each
"class" is actually a module with one procedure for each "method".  There is
also a "constructor" which allocates a chunk of memory (or multiple chunks,
depending on the object) and returns a pointer to it - this pointer becomes
the object "handle".  Every other method in the module takes as its first
argument a handle, which is used within the module to access the memory.