Can I use ISTRING in a dynamic array, or linked list? Like. instead of:
DEF bigtext[256,16000] as ISTRING
For strings, I would use:
DEF pStr as POINTER
pStr = NEW(STRING,10)
Can I do that with ISTRINGs? Or do I use ALLOCHEAP for juggling large arrays of variable-sized ISTRINGs?
I see how it works for one string at a time:
'--------------- replstr ----------------------------------------
SUB replstr(dest as string, hit as string, src as string, rept as int), HEAP
'find hit in dest, replace with src, do it rept times,
'do all possible if rept = 0 or is is not passed
' works on copy of passed string, passes copy back
' through RETURN when completed.
DEF retn,front,back:POINTER
back = AllocHeap(64000)
front = AllocHeap(64000)
retn = AllocHeap(64000)
DEF hitpos,nextpos,rpx:INT
#<STRING>retn = dest
rpx = 0
hitpos = INSTR(#<STRING>retn,hit)
DO
IF hitpos > 0
rpx = rpx + 1
#<STRING>front = LEFT$(#<STRING>retn,hitpos -1 )
#<STRING>back = MID$(#<STRING>retn,hitpos + LEN(hit))
#<STRING>retn = #<STRING>front + src + #<STRING>back
nextpos = hitpos + LEN(src)
hitpos = INSTR(#<STRING>retn,hit,nextpos)
IF rpx = rept: hitpos = 0: ENDIF
ENDIF
UNTIL hitpos = 0
RETURN #<STRING>retn
ENDSUB
So I can feed a dynamically sized string or istring to a SUB, and handle it there. But how about storing an array of dynamically-sized strings on the other end? Is there a smarter way to go than:
DEF bigtext[256,16000] as ISTRING
???
USe NEW and DELETE and an array of pointers.
That sub has has a 128K memory leak ;) The 'back' and 'front' strings are never deleted.
Paul.
Thanks, Paul. I'll ramp up the learning rocket, and get pumping with dynamic variables and linked lists and objects and....
Note to self: Every NEW deserves a DELETE.
Urgent Memo to Self: Squash all those globals and get modular!
Why do I not have to DELETE the retn string? Be hard to do, after a RETURN, I know....
Just answered my own question, didn't I? The ENDSUB cleans up after itself?
Quote from: Jerry Muelver on March 04, 2008, 07:11:13 AM
Why do I not have to DELETE the retn string? Be hard to do, after a RETURN, I know....
I
believe the system takes care of the return automatically for you.
Larry
Sure looks that way to me, too, Larry.
How about large strings in an associative array?
mydict = CictCreate(100)
gives me a hash with 100 elements initially. I think it expands beyond 100 if needed. But, how big can the value string be for an individual element? Can I have a DICT with dynamic strings for values? Or, maybe that would be a hash with strings for element keys, and pointers for values....
Okay, okay, I know -- just go and try it, and see what happens. ::)
Quote from: Jerry Muelver on March 04, 2008, 07:11:13 AM
Why do I not have to DELETE the retn string? Be hard to do, after a RETURN, I know....
Just answered my own question, didn't I? The ENDSUB cleans up after itself?
The compiler takes care of heaped strings on return automatically once they are used. You need to FreeHeap on the back and front strings yourself.
There isn't a good reason to use the heap for the front and back strings, NEW and DELETE would have been a better choice. And use the heap for the returned string itself.
Paul.
Didn't have NEW-DELETE back when I wrote that. In fact, didn't have ALLOCHEAP, either -- that came along alter. If you wouldn't keep improving your languages, I wouldn't have to work so hard to improve my coding techniques, you know. ::)
Just found this in the Help file, on pointer multiple indirection: "There is no limit on the amount of indirection, although it would be unusual to see more that two levels of indirection. Text editors routinely use two levels of indirection to store lines of text. The first level is an array of pointers, and the second levels are pointers to strings containing each line of text. In this manner the text on each line can be adjusted individually without affecting any other line."
I've got some serious experimenting to do, along those lines. "Toto, this ain't Kansas any more!"
Jerry,
Don't do what I usually do and "jump in the deep end". Sometimes the lifeguard isn't looking. ;)
(I'm currently working on a custom graph control. I'm off in the deep end and have a resizeable control by dragging it AND a right-click popup menu INSIDE the control to put it back at original size and/or print the graph.)
Scary, ain't it.
And it's all Paul's fault.
Larry
Turns out I can use ISTRING in a hash. Can't use NEW/DELETE to create a value for a hash key, though, because (apparently) DICTADD wants a string, not a pointer, in its second parameter. Getting closer, though. I don't have to reserve 2 Meg of memory to accommodate a Worst Case scenario when I only need 60k or so to do the job for a typical case.
You can use NEW/DELETE. Just derefenence
DictAdd dict, "key", #<STRING>pData
I'll try that out! I must have had a syntax glitch in my experiments with hashing dereferenced strings, and went with DEF istrings. I've got my hash-based multi-page hyperlinked full-formatted RTF textbase authoring app up and running, and ready for tweaking. Next, I have to ramp up on image-embedding and display in RTF. Using the hash let me declutter the code quite a bit, and toss out a bunch of parallel-index array juggling subs. This is pretty much like Fletchie's old DynaString stuff, but without the hand-waving and smoke and mirrors we needed back in the Old Days.