Re: Passing a pointer-based array as a parameter

On 1/31/06, Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx> wrote:
>
> > The RPG ref on an *ENTRY PARM says "Fields or data structures defined
> with
> > the keywords BASED, IMPORT, or EXPORT" are not allowed.
>
> Passing a BASED parameter wouldn't make any sense.  Parameters are passed
> by reference (i.e. by passing the pointer to that parameter).  If you
> allowed it to be BASED and defined a pointer that it was based on, then
> it'd have two different pointers that it's based on, which doesn't make
> any sense.


Yeah, pointer newbie mistake.

Instead, you need to pass the pointer (rather than the array itself) to
> the subprocedure. The subproc can then allocate memory to it.  The pointer
> does have to be passed by reference, since %ALLOC() will need to set the
> address in that pointer.


O.k., will need to get my arms around that one.  But...

I strongly recommend that you avoid the dynamic memory allocation approach
> to this if you can possibly avoid it. It's not worth it for a measley 40k
> of data.


The range of possibly 10 to 20,000 elements is real, but the structure that
I will end up using is  30 bytes in length.  Since I plan to incorporate
this into every interactive RPG program, if I accommodate  the maximum
expected 20,000 elements, that means that every interactive program will
allocate 600,000 bytes, muliplied by 50 users, and factor in the variable of
nested calls to other interactive programs.

The problem is that I can hardcode the 20000 element array, and test it with
a few people, but I won't know the impact on performance until all 50
production users have a go at it.

Would that affect your recommendation?  If it doesn't, I'd still like to
know why you advise using dynamic memory allocation.  Is it *that* messy?

Thanks,
Dan