> Lastly, if you use the REMOVE function within your code, > instead of resetting the pointer, just use a temporary > variable so that the position of the pointer in the passed > in argument is both irrelevant and unchanged. That way > you don't inadvertantly affect a piece of code that's > working with the array.
So instead of: FUNCTION ATRANS( F,K,P,X ) SAVED.RP = GETREM(K) ;* preserve however calling pgms had it. SETREM 0 ON K ;* reset to beginning of array. REMOVE DUM FROM K SETTING MORE ;* check for any delimiter SETREM SAVED.RP ON K ;* reset rmv ptr in case calling pgm cares. T = TRANS(F,K,P,X) RETURN (IF MORE THEN T ELSE RAISE(T) ) do: FUNCTION ATRANS( F,K,P,X ) KTEMP=K REMOVE DUM FROM KTEMP SETTING MORE ;* check for any delimiter T = TRANS(F,K,P,X) RETURN (IF MORE THEN T ELSE RAISE(T) ) That is something I sometimes do, too, but in this particular case (the TRANS() workaround) it would be inappropriate for 2 reasons: 1. K could sometimes be very large, so copying the array to a temporary variable could be expensive. Example: The ap I work on has outgrown its pre-native-indexing ...XREF files. Some XREF records contain mv-lists of hundreds, yea, verily I say unto thee, thousands of keys to their corresponding primary data files. Suppose an I-descriptor in the XREF's dict that TRANS()'s back to the primary file. Execution of KTEMP = K becomes oppressive, whereas manipulating K's remove pointer is trivial. 2. This is a utility subroutine that will be called by RetrieVe how many times per day? Beyond normal use, suppose a few selects each day on a few million-record files with a few TRANS's per record. Generally, I liker to err on the side of Maintainability (including Readability) over Efficiency, but my exception is code that gets executed repeatedly. Then Efficiency wins. Just comment the thing to the hilt for the poor schmuck who reads it a few years hence. If this were a less used routine and I knew K was generally small, I might go for copying the contents of K to KTEMP and forgetting about the remove pointers. ( A tangential comment for newbies: UV-Basic (UD, too?) passes arguments by address, not value. That is, the calling routine tells the subroutine where the data resides in memory, rather than passing the data itself to/from the subroutine. So the subroutine references and manipulates the very same data in memory as the calling routine does. In the case of large dynamic arrays that is quite efficient, compared with the alternative of first making a separate memory copy of the string for the subroutine, then, upon return, copying that data back to the calling routine's variable. ) For whatever it is worth, Chuck Stevenson ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
