RE: Using STATIC

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

>> From: Jim Langston
>>
>> Okay, I guess I need to be a little more specific, when would it be a
good
>> time to have memory allocated by the called method and return a pointer
to
>> it, instead of passing a pointer to the called method and having
>> the called method allocate the memory based on that pointer.
>
>Jim, I guess I don't understand this.  Are you suggesting that the calling
>method passes an address to the called method, and then the called method
>somehow allocates a block of memory starting at that address?  This isn't
>really possible.

Why wouldn't this be possible?  I could do it in C very easily.  Take the
pointer and remalloc it.  I understand that RPG may not have all the
malloc/remalloc/demalloc that C does, but there are other ways.

Even allocing the memory inside the called procedure and returning a pointer
to it would be fine.

>> And second, when would it be good to return a pointer to a statically
>> defined object rather than malloc the memory?
>
>You would do this when there is and always will be only one copy of the
>object, such as a constant string.

A constant string I could see.  That is a little different animal than a
static variable, although it is static, it does not reside on the stack but
on the heap.

>> Or
>> to artificially move an object off the stack onto the heap to return a
>> pointer to it (as I believe the static keyword does) rather than just to
>> create the object on the heap in the first place (malloc).
>
>No, the static keyword doesn't "artificially" do anything.  Static
variables
>are different than temporary variables.  If you use static properly (to
>define variables that don't change, or variables that need to be shared
>among multiple invocations of a method), then the usage is fine.  The only
>"artificial" use is, as you noted, changing a temporary value to static
just
>to return it.

Here is where we disagree.

>My point is there are valid times to use static and to return a pointer to
>an internally defined static variable.  A cache of constants (such as a
>resource bundle) is a perfect example of this.  By using pointers to
objects
>contained in the resource bundle, the calling program can be language
>independent by simply attaching a different resource bundle.

A resource bundle I could understand, but a resource bundle is not actually
a static variable/structure is it?  I think it depends on your definition of
a resource bundle.

>> Understand, I'm not saying that it won't work, returning a pointer to a
>> static variable, I'm saying I do not consider it good programming at all.
>> Even if I have to jump through hoops to avoid it, I will.
>
>I'm not trying to be argumentative here, but this sort of decision making
>process can sometimes lead to bad programming.  If you take the time to
>really analyze the situation, you will see that there are times to return
>pointers and times not to.  By knowing the difference, you will be able to
>better use all the capabilities of the language.  "Jumping through hoops"
to
>avoid something without have a fundamental reason to avoid it is not really
>a good way to make design decisions.

I understand there are times to return pointers and not, and in my C
programs I design functions and objects that return pointers all the time.
But I have never designed a function to return a pointer to a static
variable.  I have designed functions/objects to return pointers to an offset
of a passed in pointer, to other objects inside of my classes, to video
memory, etc...  There are lots of times it is very good to return pointers.

Since I program in so many languages, I see a lot of the bad that people do.
Such as the fact that I never use the goto, although I will agree that
sometimes it would be better to use a goto, it is too easily abused and so I
won't do it.  Same with this issue I think, there are too many ways to abuse
it if you don't see what's going on, and too many ways to break it in
maintenance if you don't know what's going on.  Easier just to take the few
extra steps to allocate the memory and return that, which can't get broken
easily.

Regards,

Jim Langston