RE: Using STATIC

[Jim Langston <jlangston@xxxxxxxxxxx>]

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

>> From: Jim Langston
>>
>> 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.
>
>That's entirely opposite of what I said.  If the calling method is
>performing the allocation, it needs to know the size, and thus is not OO.

My bad, I meant to say, "... and have the called function change the memory
size."

>> Given this, when would you see a good time to return a pointer to memory
>> "owned" by a called function?
>
>If I were returning pointers to statically defined objects in the called
>method, or to memory allocated by the called method (such as a cache).  I
>think I was pretty clear about this.

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.

And second, when would it be good to return a pointer to a statically
defined object rather than malloc the memory?

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

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.

Regards,

Jim Langston