 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Syntax question about string length.
| Author | Message | ||||
| Paul_L Guru  Joined: 03/03/2016 Location: United StatesPosts: 769 |
I am attempting to build a hash table where the individual characters in an input key string will be matched to a position in an array of strings, then a string will be copied out of the same position in a second array of longer strings where the individual characters in the second longer string will each control something. (Huh! What the #$&@^% did I just say?) I will be changing individual characters in the input string frequently. I am wondering which method of defining the input string will result in the least thrashing of memory locations. After OPTION EXPLICIT will thisDIM IN$ LENGTH 4 : IN$="ABCD" or thisDIM IN$="ABCD" LENGTH 4 or thisDIM IN$ = "ABCD" all result in the same memory contents?If the next line is IN$="EFGH" will this result in the memory location being moved in any the three cases?If the next line is IN$="IJK" will this shorter string result in the memory location being moved in any of the three cases?If I goof and make the string longer IN$="LMNOP" I assume the first and second cases will crash. Is that correct?Or should I just pretend I'm writing C code and say OPTION EXPLICIT DIM A$(4) LENGTH 1, IN$ LENGTH 4, i% INPUT IN$ ' assume IN$="ABCD" FOR i%=1 to 4 A$(i)=mid$(IN$,i%,1) NEXT i% Paul in NY |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3308 |
Hi Paul, In your first three examples they will result in exactly the same memory allocation and contents. The fourth example will not result in any change to the memory allocation while the fifth will throw an error "String too long". In MMBasic the memory allocated for a string variable is 256 bytes (255 characters plus 1 byte for the length) and this is regardless of the actual length of the string stored in the variable. This is obviously a problem with arrays (eg, an array with 100 elements will use 25,600 bytes). So the LENGTH parameter was introduced to specify a memory allocation of less than 256 bytes per array element. You can also use the LENGTH parameter for simple (non arrayed) variables but it will not affect the memory allocation which will always be 256 bytes - this is because memory is allocated by MMBasic in a minimum of 256 byte chunks. The only consequence of using the LENGTH parameter for a simple (non arrayed) variable is that it will throw an error if the string is too long. Note that once memory is allocated to a string variable it is not moved or deleted by MMBasic. You might wonder why the memory management is not more sophisticated and the simple answer is that a more complex scheme would consume more memory than it saved and would also incur a performance penalty. Given that a typical program has only a relatively small number of string variables the current scheme works well. Geoff Geoff Graham - http://geoffg.net |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9749 |
That is extremely interesting. So using LENGTH on a line such as DIM AS STRING A$,B$,C$,D$ LENGTH 25 will still consume 1K of memory? 256 bytes for each of the four strings, but if the length of the string is more then 25 bytes long, MMBASIC throws an error - correct? If so, I will stop using the LENGTH option on all my strings, as I thought I was saving memory by doing that!  Smoke makes things work. When the smoke gets out, it stops! |
||||
twofingers Guru Joined: 02/06/2014 Location: GermanyPosts: 1671 |
Yes! A good idea!  In contrast to string ARRAYS there LENGTH makes sense! (I'm sure you know that.  )Regards Michael causality ≠ correlation ≠ coincidence |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1116 |
@Grogster If you want to use a lot of reasonably short strings and space is an issue, the following method may be an option? option explicit memory dim bunchofstrings$(100) length 4 ' now name the individual strings const string0 = 0 const string1 = 1 const string2 = 2 const string3 = 3 ' etc etc up to max number in the string array ' ... so now bunchofstrings$(string0) = "ABCD" bunchofstrings$(string1) = "DEFG" ' .. and so on and so forth ' you would use a suitably short name for the string array, say bsa$() ' and meaningfull names for your array elements memory ' note that the above uses just 1K instead of the normal 25K odd that ' would be used for 100 non array strings cheers, panky ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Thanks Geoff. That explains a lot. So the first byte in a string block specifies how many of the following 255 bytes contain useful data and a simple string variable always uses one 256 byte block. Which means that manipulating characters in and out of the four character UserInput$ repeatedly will not result in multiple old blocks of memory for the trash collection routines to gather up. It might be a good idea then to increase the size of both the USER$(nn) and HASH$(nn) arrays by one, use USER$(1) as the key value formed by the user input selections, search for an identical string in a higher element, [USER$(1)=USER$(xx)], then copy the contents of HASH$(xx) to HASH$(1) and use HASH$(1) to control program decisions. This monster has developed into an exercise in data driven programming. The hash table will eliminate several hundred lines of a giant SELECT CASE statement. Paul in NY |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2171 |
LOL I just removed all the LENGTH properties in a current project  |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9749 |
.......and all this time.....  EDIT: @ panky - Yes, that is a really clever way to use an array to hold all the short strings. Something to keep in mind for the next project I think. Not that I was running out of memory, I just thought I was being efficient using the LENGTH thing, when in fact I was not!  Smoke makes things work. When the smoke gets out, it stops! |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
