RE: Using STATIC -- RPG400-L

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.

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.

The biggest reason not to do this is because memory is not guaranteed to
exist beyond the life of the function.  If you do something like (in pseudo
code since I don't want to figure out the intricacies of pointers in an
example):

   D Contents                       10A
   D MyPointer                       *   Based(Contents)

   C             Eval    MyPointer = MyFunction()
   C             If      Contents = 'X'

MyPointer could now be pointing to memory that has been destroyed, so the if
statement may work sometimes, may not work sometimes, but is a very bad
idea.

Now, even declaring the memory that MyFunction returns as static is not such
a good idea.  Especially in PC programs where memory gets paged in/out of
disk.  One time it may be pointing at the variable, another time it may be
pointing into lala land.  I believe this is unspecified.

We may, or may not, have that problem in RPG, but the whole thing is, we
shouldn't have to guess how the compiler designers are doing it today,
because they may do it differently tomorrow.  Who's to say that in V5R2 your
program won't start bombing because the Compiler is doing something
different that shouldn't make any difference to how it is used.

The proper way to do the above would simply be to pass the pointer into the
function and have the function load the memory.
   C             Eval    MyFunction(MyPointer)

Regards,

Jim Langston

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

> From: James Rich
>
> I am saying that returning a pointer to private storage is bad design and
> using static to fix that problem continues the bad design.  static has
> good uses.  Using it to keep your storage around so you can return a
> pointer to it is not one of them.

What do you consider "private storage"?  If you are talking about internal
state-holding variables, then certainly it's a bad idea to expose them.  On
the other hand, there are a number of times when a subprocedure might need
to return a pointer to internal storage.  These are typically called
"factory" methods, and a typical example is a connection pool.  While
certainly not as common in RPG as in OO languages, the idea of a factory
class is still perfectly valid.  Let's take Nathan Andelin's template-based
HTML generation, for example.  It would make a ton of sense to have a
factory method that loads and caches these templates, returning pointers to
them on request.

The argument might be that a pool of objects returned from a factory are not
"private storage".  While true from a "common sense" standpoint, there is no
particular attribute that automatically indicates that a given object is
"private storage" or "public storage".  It's pretty much a matter of
definition.

There are other reasons to return a pointer to private storage.  Again, I'm
talking in general terms rather than specifically in RPG terms, but it is
much easier (and faster) to compare two pointers to structures rather than
to compare the entire contents of the structure.  Let's say a method is
designed to return one of several structures.  It can either create a new
clone of the structure each time, or a pointer to an internally defined
structure.  If this method always returns a pointer to a specific internally
defined structure, a programmer may use a much more efficient pointer
comparison to determine equality.

Anyway, my point is that determining whether a given technique is "right" or
"wrong" really depends upon the implementation and the reason.

Joe