RE: Using STATIC

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


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


> I think the biggest issue is, it is generally not a good idea to return a
> pointer to something that may wind up on the stack instead of the
> heap.

Agreed.


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

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.


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

Joe