RE: Using STATIC

> From: Jim Langston
>
> There are a few generally accepted methods to do this, and I
> didn't see the
> original e-mail so don't know the specifics in this case.
>
> But James Rich is right, returning a pointer to private storage is bad
> design, private storage being memory available to a subroutine or function
> only.

As I said, I agreed with the concept of internal variables being kept
private.  This by definition would mean any temporary variables.  And if
we're just referring to temporary variables, then I agree completely.
However, James went a little too far, in my estimation, when he made a
blanket condemnation of returning pointers to static variables.  There are
times when returning a pointer to a static variable or dynamically allocated
memory is a valid technique.

In my example, that of a pool or cache, it's perfectly acceptable to have a
method return pointers either to statically defined or dynamically allocated
memory.  Indeed, in a truly OO design it's required, beacuse the calling
method should have no idea how much memory to allocate, since it should not
know the internal layout of the structure (this is the age old issue of
"handles" vs. "pointers").


> 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.


> The biggest reason not to do this is because memory is not guaranteed to
> exist beyond the life of the function.

Again, two different issues.  Returning pointers to temporary values is by
definition bad, for just the reason you (and James) mentioned.  Using a
STATIC just to get around that concern is probably bad, but returning
pointers to non-temporary data, either static or dynamically allocated, is
not IN AND OF ITSELF a bad thing.  I just wanted to make the distinction.

Pointer to temporary variable = BAD
Pointer to static, dynamic = MAYBE

Joe