Home AMX User Forum NetLinx Studio
Options

Array Issue

Hi All,
This one could have a simple answer, I just can't see the wood for the trees.

Is there a neater way of clearing an array? I am working with a Long array

LONG l[50]

I have a process which repeatedly fills the array with various lengths which leaves the garbage from the existing run at the end of the array.

How does one clear the array in one hit? Chars are fine, "" some quotes do the job. However I can't seem to find a way of 'nulling' the variable without running a loop.

Surely there must be an easier way?

Comments

  • Options
    samossamos Posts: 106
    set_length_array

    set_length_array

    look up this key word. set length to zero
  • Options
    That appears not to play ball with my LONG array. If I remove my 'cleanup' loop from the beginning of the function and instead set the array length to zero then when I come to use the array it is back as a full size array (as the size was declared at in Define_Variable) and I now have garbage up in the higher reaches.
  • Options
    sonnysonny Posts: 208
    For clarification, what are you trying to accomplish? Sounds like your function doesn't have info on how much data is in the array and you're wanting to loop until foo[x] == null?
  • Options
    Netlinx doesn't have a null value. Set_Length_Array will define the length of the array. But to fill the array with null values (actually non-important values), you will have to define what a null value would be. Is it 0 or possibly a negative value, etc. What I do to clear an array is set the array equal to another array that I create at start up that has nothing but the null values. For example, if 0 means null in this example, I do the following:

    DEFINE_START

    ArrayNull = "0,0,0,0,0,0,0,0,0,0"

    Then in my code, I set my array to ArrayNull:

    WorkingArray = ArrayNull

    And I clear out any old values in each individual slot. I can then also set the length to zero, but I know that there are no left over values.

    If your actual values are valid from -MinValue to MaxValue, that's a bit tougher, but I suspect that there is a specific range of values that you consider valid. Set your null value to anything outside that range.
  • Options
    Many thanks for the info. The issue for clarification is I will have an array of data which I do not know exactly how long it will be but I know what the maximum value will be. Then based on user input this list can be iterated through and reduced based on a set of rules.

    I have two arrays one declared in define variable and a stack_var which is used as a temporary store whilst shuffling data around. This is then copied back and the iterating starts over until the result can get no smaller.

    It appears there are two issues, one is to clear out the arrays on each run of the function to make sure I don't end up with any garbage. The other is it appears when creating a stack_var long it picks up whatever garbage is left in the memory it has been assigned. I may be wrong with this but it appears that integer stack_vars don't have this issue, they always seem to declare empty.

    Programatically I guess there's not much in it between svTECH's null file idea and quickly running a nulling loop (as I already have a counter declared for the next operation). Being lazy though, the for loop means I don't have to create a large variable full of zeros at the beginning!

    Thanks all for your help!
  • Options
    ericmedleyericmedley Posts: 4,177
    Perhaps you could do a hybrid of both suggestions.

    Make the null value array something like 10 chars long and then use a for loop to go through the larger buffer 10 chars at a time. That might cut things down a bit. But maybe not.
  • Options
    jjamesjjames Posts: 2,908
    stack_vars are created once and then "thrown away" - they don't hold their value once the block they're declared in is finished. local_vars however do keep their value.

    Have you thought about just "nulling" (making zero) the index just after your final? For example:
    1,2,3,4,6,4,3,0,21,5,2

    This way you know where it "ends". If you know where the end is supposed to be, why does it matter if there's more after it?
  • Options
    jjames, I am aware to how the STACK/LOCALs behave, where I have been bad is that I had not emptied the STACK_VAR before using it.

    0 values are valid so a zero would not necessarily mean the end of a string.

    A counter and a null of the array before use has got me ticking over nicely!

    eric - good thought on the nulling!
  • Options
    jjamesjjames Posts: 2,908
    Sorry - when you said "I may be wrong with this but it appears that integer stack_vars don't have this issue, they always seem to declare empty", to me it meant that you were surprised that they were empty.
  • Options
    Lol, no wonder I was suprised! I was wrong.

    I tried a quick test where I created a STACK_VAR array of LONG and a STACK_VAR array of INTEGER then printed these out to debug in ascii using FORMAT.

    All manner of numbers surfaced from both of them!

    Shows the importance of making sure I clear my variables first. I guess I've never noticed it before as usually I copy something into that variable before doing anything with it thus wiping all the garbage.
  • Options
    sonnysonny Posts: 208
    Not sure why you would ever read a variable that hadn't been initialized. If I remember, Visual C++ gives you a compiler warning if you do this.
  • Options
    AuserAuser Posts: 506
    I tried a quick test where I created a STACK_VAR array of LONG and a STACK_VAR array of INTEGER then printed these out to debug in ascii using FORMAT.

    All manner of numbers surfaced from both of them!

    This directly contradicts the NetLinx Keywords Help File from Studio:
    STACK_VAR defines a non-static local variable. STACK_VAR defines local variables the same way as LOCAL_VAR, and like LOCAL_VAR, STACK_VAR can appear in any statement block. The difference is that the value stored in the variable is initialized to zero whenever the statement block is called, and the value is destroyed when the statement block is finished.
    
    Shows the importance of making sure I clear my variables first. I guess I've never noticed it before as usually I copy something into that variable before doing anything with it thus wiping all the garbage.

    Hmm, will have to run some tests and see if I can replicate.
  • Options
    viningvining Posts: 4,368
    That's how I was always told stack vars worked. So when I want to zero an array or structure I usually create a matching stack var and make my var = the stack var which i created just to zero my var.
  • Options
    PhreaKPhreaK Posts: 966
    From my understanding when stack_var's are declared they are allocated memory from a pool. If enough space is not available in that pool the firmware will allocate additional memory to it, but will not decrease this space. From my simpleton view this may mean if that you declare a variable that gets given some memory space that was already in the pool it is likely to come pre-filled with whatever crap was in there. However, if vxWorks happens to hand it some fresh memory space it may get initialized as part of this process - which would explain the inconsistent behavior. Lesson: always init your variables before attempting to read from them.
  • Options
    viningvining Posts: 4,368
    I have to believe that stack vars are initialized to zero every time their code runs as the keywords help file that Auser pointed out describes. If not every code i've ever written is broke since I never initialize stack vars except when they're first used in for loops, otherwise I expect them to be zero and if it actually turns out to be a roll of the dice whether they're initiazed as something other than zero I'm royally screwed but I'm sure I would have noticed this by now as I expect others would have too.

    I would run tests but I have my laborer's hat on this month not my programer's hat so i'm avoiding the office.
  • Options
    DHawthorneDHawthorne Posts: 4,584
    I've used stack variables just about forever for a cheap way of reinitializing the value. The key is you have to make sure it passes out of scope so the memory gets released. Inside of functions and event handlers, they work great this way. You can even declare them inside a code block just by bracketing it, and when the operation passes out of the brackets, it will reset. You just have to be careful.
Sign In or Register to comment.