For universe, I believe that used to be true - I seem to recall running into this maybe 15+(?) years ago. I also seem to recall that the resolution to this issue was, as was mentioned, prepending all strings with a length.
Try it: x="abc":char(255):"xyz" crt "[":x:"]" crt len(x) crt index(x,"x",1) end [abc xyz] 7 5 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Wjhonson Sent: Friday, July 13, 2012 12:27 PM To: [email protected] Subject: Re: [U2] trimming a list (a test of your ability) Yes/No A string is stored in a fixed length *spot*, and is ended by an FF. This is *why* if you actually try to create a string in BASIC (or read one) with an embedded FF in it, the runtime will "truncate" the string It doesn' actually truncate the variable spot, what it does is fool the run-time into thinking you've hit the "end" of the string so it ignores anything else after it thinking it's leftover garbage from trimming or something. So initially let's say you get a "spot" of 8 bytes which is the default size of any variable, if you're string is only 8, it will then allocate you 50 bytes, and *move* the string into that new spot and the old spot will just be a direct pointer to the new spot. If you exceed 50 bytes, it then *allocates* you a new *spot* of 250 bytes elsewhere, and the original 8 byte spot now points at the new spot And so on. However, as it scans the string looking for the *end*, if it encounters an FF, that's the end. The run-time will also garbage-collect the old spots by the way, for use as other things. I'd be surprised if it actually wastes effort to store the length constantly at the fore, but I'm willing to be edumacated on that abstruse point. (Or pointer) Will -----Original Message----- From: Wols Lists <[email protected]> To: u2-users <[email protected]> Sent: Fri, Jul 13, 2012 3:53 am Subject: Re: [U2] trimming a list (a test of your ability) On 12/07/12 16:15, Dave Laansma wrote: I'm puzzled by '... doesn't care ...' terminology. Of course it 'cares' about pointers, it still has to get to the end of the 'string' one way or another. Except that a string, as far as I am aware, uses the "pascal method" I hink it's called - namely a string is stored as its length followed by he string (or a Hollerith string as I used to do in FORTRAN). So, the question then is, does concatenation := establish and append to a 'string' faster than <-1>? Very much so And if so, why doesn't the database use the same logic for <-1> as it does for := since technically they're accomplishing the same thing? ecause it's doing it in a completely different way. The <-1> logic just happens to work" whereas the append logic was designed to work hat way. If you use a field number, the code searches for that field - I think it akes the field as a counter, and searches the string decrementing the ounter every time it hits a field mark. When the counter hits zero it's ound what it's looking for. Of course, if you start at -1, it never hits zero and ends up at the end f the string. But this is by accident not design. To do what you uggest would require special case code which doesn't - logically - elong there. > Sincerely, David Laansma IT Manager Hubbard Supply Co. Direct: 810-342-7143 Office: 810-234-8681 Fax: 810-234-6142 www.hubbardsupply.com "Delivering Products, Services and Innovative Solutions" heers, ol ______________________________________________ 2-Users mailing list [email protected] ttp://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
