Re: Variable length MODS

Hans,

Does it really matter how many elements are in an array that is being
used as a pointer anyway?

This is pseudo code

D SomeStructure  DS             DIM() BASED(SomePointer)
D SomeString         10A
D SomeInt            10U
D SomeZoned           9S 0
D SomePointer     S    *

D SomeCounter         9P 0
D SomeMax             9P 0

C            Eval    SomePointer = SomeAddressToSomeArray
C            Eval    SomeMax = MaxRangeOfTheArrayPointingTo

C            Eval    SomeCounter = 1
C            DoW     SomeCounter <= SomeMax

C            DISPL   SomeString(SomeCounter)
 or alternately
C            DISPL   SomeStructure(SomeCounter).SomeString
 or even
C            DISPL   SomeStructure(SomeCounter)->SomeString
 or any way you want to do it.  Interesting, how do you do elemets with 
dimentioned data structures?
Time to hit the manual

The whole point being, RPG or the AS/400 shouldn't care what the upper limit is.
It does not have to allocate any memory, since we are using a pointer anyway, 
and
just looking at memory that's already there.  The program math is fairly simple 
behind
the covers, the array element X starts at SizeOfStructure * (X - 1) + 1

Regards,

Jim Langston


boldt@ca.ibm.com wrote:
> 
> Jon wrote:
> >There is nothing wrong with your thinking as far as it goes.  It just
> >doesn't extend into taking RPG history into account.
> >
> >Remember that pointers etc. were retrofitted to RPG relatively late in its
> >life.  RPG applies upper bound checking to arrays and MODS based on the
> >size specified.  When BASED structures were introduced (for better or
> >worse) no change was made to the code generation in this area.  At some
> >point in the future one hopes that the compiler folks (are you listening
> >Hans and Barbara?) will allow us to specify the size of a based array etc.
> >via a variable.  If they make the storage reallocate itself magically
> >whenever I change that variable then that would be nice too - but I could
> >live wit just being able to specify the current size.
> >
> >Until such time as they change the compiler - think of it this way - the
> >value for DIM is a sanity check when used with based storage - I set it to
> >a value that says "when it gets this big I must be looping".  Then
> >implement your own upper bound check the way you have to (or should do) in
> >many other languages.
> 
> Well, I, for one, am following this discussion.  As you know, dynamic
> arrays and MODS's came in at 10th place in the 2001 enhancement
> survey.  The 1st 9 items already cost $98.  In other words, it was
> voted just past the $100 cutoff.
> 
> The big problem is designing exactly how this type of function should
> work.  For example, if you pass a dynamic array as a procedure parm,
> how should the limit value be handled?  Should it be part of the data
> being passed?  Or must the limit be handled separately in every
> procedure that uses the array?  Each choice has its advantages and
> costs which need balancing out.  Or perhaps there are easier
> alternatives, such as the "number of elements" parameter on the new
> %LOOKUPxx built-ins.  If we extend the SORTA opcode and the %XFOOT BIF
> the same way, would that satisfy 80% (more or less) of the coding
> needs for dynamic arrays?  Those could be designed and implemented for
> fairly low cost in comparison to other alternatives.
> 
> (To be honest, though, the $100 cutoff is really just a rough
> guideline.  We're considering implementing a few items from below that
> line where they fit nicely with other chosen items.  One item, in
> particular, was voted fairly low, but really goes hand-in-hand with
> another item in the top nine.  Both items together cost much less than
> the sum of both priced separately and together satisfy a long-standing
> requirement (in addition to their own merits).  I'm very tempted to post
> some sample RPG code I actually have running here in the lab, but it's
> still way too early to talk about the post-V5R1 future.  (Maybe I
> shouldn't even post such "teasers", but I feel mischievous this
> morning!))
> 
> Cheers!  Hans
> 
> Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com
> 
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---