× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



> From: Jim Langston
>
> >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.

Evidently we have completely different concepts of how things work.  In my
understanding of things, when you do a %ALLOC() in RPG, you have no control
over the address of the returned memory.  None.  This is the same for every
allocation method I've ever used, including C and C++.  You specify the size
and the allocation routine returns a pointer.  You never pass a pointer TO
the allocation routine.  With realloc(), you do pass a pointer to the
existing memory, but the data may be moved, and the original chunk may be
freed.

And just to be sure we're on the same page, realloc() is the stdlib.h
method, along with free(), as opposed to remalloc and demalloc.


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

This is exactly what I said to do.  Allocate the memory in the called
procedure and return the pointer.  But that's not necessary for static
variables.


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

Again, I'm pretty confused here.  Static variables reside neither on the
heap (the pool of dynamically allocated memory shared by all processes) nor
on the stack (the process-specific chunk of memory that stores temporary
variables and return addresses).  Static variables are located in the code
segment of the program (known as the CSEG back in assembler days), and are
loaded when the module is loaded.


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

It depends.  A resource bundle can be implemented by loading a number of
values from a file into the heap, but you could just as easily implement a
resource bundle as a set of static definitions.  This would even have some
performance benefits, although it would be more useful for situations where
the number of constants required rarely changes.


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

Unfortunately, we don't agree on the basic operation of a computer program,
from how a static is defined to how functions such as malloc() work, so I
doubt we'll come to a reasonable agreement here.

Joe



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.